> On Wed, 1 Apr 1998, Rob Hagopian wrote:
>
> > Most programs (apache comes to mind) drop root as soon as they've got the
> > port and don't do anything else as root, so it's shouldn't be a problem.
> > Frankly, I really don't want users trying to start daemons for services
> > I've intentionally disabled.
> >
> > There was, at one point, something circulating about security patches to
> > give more fine grained allocation of things like the lower ports which
> > solves both problems, but I haven't heard anything recently...
> >
> -Rob H.
> I'll clarify, I saw some work a few months ago to control access to those
> ports. Not everyone needs/should get access to them, but root IMHO is
> overkill.
When you actually look at using such restrictions, you often run
into enough problems to give up.
For example, say you allowd a "httpd" user to bind to port 80, then
you ran Apache as httpd. So far so good; it can bind to the port,
it can serve requests, no longer needs to be started by root.
Only problem is that it can't switch uids while starting. That means
that if you let people run CGIs without some sort of wrapper, they
can gain httpd and steal connections. They can also mess with the log
files, etc. To avoid this, you must have it switch UIDs between starting
and serving requests. If you have any services that rely on host-based
access control and connections coming from a low port (eg. rsh), you
need to switch UIDs. Just because that sort of authentication is broken
anyway doesn't mean people don't use it. The main danger here is
CGIs, but there is also the danger of security holes in your webserver
that allow you to compromise the user it is running as.
So to switch UIDs, it has to be started by root. Now you are right back
where you started. Well, the other option is to go and start making
complicated rules that user x can setuid to user y, etc.
In some situations it can be useful to have the control to allow
specific users to bind to low ports, however it isn't a general solution
and isn't as trivial to usefully use as it often appears at first.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu