Re: Ports and privileges

["James W. Abendschan" <jwa () jammed com>]

On Fri, 20 Feb 1998, Chris Pugrud wrote:
> I know that _one_ of the primary reasons for all of the workarounds in
> doing suid and chroot is because many of these programs need to run as
> root (yes, chroot has many other uses).  Why do they need to run as
> root?  The primary reasons seems to be so that they can open privileged
> ports.
>
> How hard would it be to modify the stack (say Linux) so that I can run
> an unprivileged program on a low port (say 80)?  Why would this be a bad
> thing?  I understand the original concept, to keep users from running
> programs on privileged ports, but firewalls don't have users.

Linux, you say?

It's pretty simple.  Pull up net/ipv4/af_inet.c and hunt around line 623
for this snippit:
        if (snum < PROT_SOCK) {
                if (!suser())
                return(-EACCES);
                if (snum == 0)
                        return(-EAGAIN);
        }

.. and comment or #ifdef it out.

I run named and httpd as non-root users this way.  In a box with no user
accounts, this works nicely.

> Is there another logical reason that this step is not taken.  Why can't
> I have a compile time option of "Disable privileged port restrictions?"

I've written a patch that does this, among other things (such as disabling
promiscuous mode and disabling mknod(), all configurable).  I've been using 
them for the past few months without problems, but I want to add "just 
one more" feature -- getting chroot() to fail if it's already chroot()ed --
before I make them available.

James

--
James W. Abendschan                              http://www.jammed.com
"'I think it looks like an anti-cyclone,' said Merlyn."  -- T.H. White