Re: Ports 0-1023?

[Brian Hatch <vuln-dev () ifokr org>]

Ok, to summarize this thread a bit more:

  * We all agree that simply making the default 'any user
    can bind any port' is a bad plan.

  * There are a variety of different existing kernel modifications
    (LIDS/SELinux/systrace/etc) that can be used to allow the
    kind of 'only user/process X can bind port Y' systems we're
    talking about.

  * These kernel patches/systems have much more functionality
    than simply restricting <1024 port binding
    
  * These kernel patches/systems do not approach the <1024 port
    binding problem in the same way (user vs process, how the
    configuration is managed, etc)


So, in order to have a way of ditching the historical <1024 port
binding requirement, we'd be replacing it with some system to
authorize users/process to bind specific ports.  We'd want it
as consistent and minimalistic as possible, because otherwise
there's no chance we'd end up with consensus and getting this
available for multiple OSs.

> The kernel already has code in place since 2.2.13, as I recall, to check 
> if a process has a certain capability.

POSIX capabilities do compartmentalize permissions to 'does this
process have capability X' instead of 'is this process running 
as uid/euid root'.  However in the Linux kernel, the capabilities
calls all look like this:


        if ( port < 1024 && !capable(CAP_BIND_NET_SERVICE) ) {
                /* complain */
        }
                

But the capable call is defined as:


        int capable(int capability) {
                if ( euid==0 || uid==0 ) return 1 
        }

        
        
(That's all pseudo code, not the actual code.)

So although capabilites are built into the kernel, the base check
is still just using {e}uid==0.


--
Brian Hatch                  Never raise your hands
   Systems and                to your kids. It leaves
   Security Engineer          your groin unprotected.
http://www.ifokr.org/bri/

Every message PGP signed

Attachment: _bin
Description: