On Wed, 13 Jan 1999, Ian Dall wrote:

# Why do you need a kernel solution? Can't you make a SUID 0 process which

	It should be a kernel solution because it's the kernel that's
telling it that it can't bind in the first place.  It doesn't make sense
to work around something that the kernel's doing that differs from your
policy when you have the source to the kernel.  I believe that security
should be more granular than root or no root.

# checks uid is dustin, opens the socket, does setuid(getuid())  etc and
# execs dustins process either with the open socket on a well known file
# descriptor or passing the number of the file descriptor as an argument? 

	This is worse.  Now you're not only relying on root to do the work
again (though this can be done *fairly* cleanly, it still has to do a lot
as root to figure out who you are, what you're trying to bind to, and
whether you're allowed), but you have to do major application rewrites to
get it to work, and in most cases, this isn't even applicable.  For
instance, my original server, which starts itself up, figures out how it's
configured, and then binds to the port would no longer work, nor would
Apache, or any third-party application you didn't get the source to, but
have to run due to a business deal with them, etc...

	What I am suggesting requires no changes to applications in any
way, they will not know the difference (unless they look).  I've just
changed the part of the kernel that says, ``Is it less than 1024 and are
they root,'' to say, ``Is it less than 1024 and are they root or have they
been assigned permission.''

--
SA, beyond.com           My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE 
L_______________________ I hope the answer won't upset her. ____________