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
This archive was generated by hypermail 2b30 : Fri Jul 05 2002 - 15:27:02 PDT