why are capabilities disabled?

why are capabilities disabled?

[Sven Köhler]

Hi,

"getpcaps 1" shows, that the init-process is started without 
cap_setpcap, and i know that i can change that somehow.
So why are capabilities disabled? and how do i enable them?

If capabilities aren't still too unmature, wouldn't it be fine to have 
an option in "make menuconfig" to enable them?

My intention is to a allow a process to bind a port <1024.
The process can't be started as root.

Thx
   Sven

Re: why are capabilities disabled?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

On Fri, 13 Feb 2004 16:29:28 +0100, =?ISO-8859-15?Q?Sven_K=F6hler?= <skoehler@upb.de>  said:
> Hi,
> 
> "getpcaps 1" shows, that the init-process is started without 
> cap_setpcap, and i know that i can change that somehow.
> So why are capabilities disabled? and how do i enable them?
> 
> If capabilities aren't still too unmature, wouldn't it be fine to have 
> an option in "make menuconfig" to enable them?

There was a long thread back in October 2003 labeled:

Subject: Re: posix capabilities inheritance

http://marc.theaimsgroup.com/?l=linux-kernel&m=106673587410831&w=2

that discusses the biggest issues.  Basically, we can get it right, or
we can follow Posix.  Andy Lutomirski at Stanford seemed to know what needed
doing, but I don't know if any actual changes were applied to the baseline
source tree.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: why are capabilities disabled?

[Sven Köhler]

>>"getpcaps 1" shows, that the init-process is started without 
>>cap_setpcap, and i know that i can change that somehow.
>>So why are capabilities disabled? and how do i enable them?

i found the hint again: i have to change the value CAP_INIT_EFF_SET in 
capability.h, so that init-process is not started with disabled 
cap_setpcap, but is this still a security risk?

> There was a long thread back in October 2003 labeled:
> Subject: Re: posix capabilities inheritance
> http://marc.theaimsgroup.com/?l=linux-kernel&m=106673587410831&w=2

everybody's talking about filesystem-capabilities etc.
i still dream of starting a process with a certain capability.

Re: why are capabilities disabled?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

On Fri, 13 Feb 2004 18:54:53 +0100, =?ISO-8859-1?Q?Sven_K=F6hler?= said:
> everybody's talking about filesystem-capabilities etc.
> i still dream of starting a process with a certain capability.

As long as you're staying in the same domain of capabilities, there's no
really big issue.  The problem starts when you use fork(), exec(), and friends
to launch something that may have a different set of capabilities (either more
or less). Also note that exploited code can cause an exec() in a program that
doesn't even have a call to exec() in it....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: why are capabilities disabled?

[Maciej Zenczykowski]

> As long as you're staying in the same domain of capabilities, there's no
> really big issue.  The problem starts when you use fork(), exec(), and friends
> to launch something that may have a different set of capabilities (either more
> or less). Also note that exploited code can cause an exec() in a program that
> doesn't even have a call to exec() in it....

Obviously a program without exec in it should not have the 
right/priviledge/capability to call exec period.

We should provide some sort of way for each process directly after 
start-up (or later on, after it's done ssetting up whatever) to declare 
which syscalls (subfunctions for networking) it will 
never use so that they can be quickly and efficiently disabled to ENOSYS 
or EDISABLED or whatever.  Such 'capabilities' should be per pid per 
syscall/subfunction and should be inherited over fork/exec and should only 
be allowed to be set (no enabling by self - only by a process with that 
syscall only enabled for another process with it disabled).

I have a half-hack patch working here at home and my dns server starts up 
with full uid/gid 0 0 on root filesystem and proceeds to initialize 
everything it needs, dropping priveledges when no longer needed.
It ends up as a nobody/nobody chroot'ed daemon with 1 open udp domain 
port, no open file descripters (besides the socket) and no rights to 
perform any syscall except recvfrom and sendto and poll or select (can't 
remember something like 6 or 7 syscalls out of the 280 in the kernel).
Even if a buffer overflow exists in the code at worst the code is capable 
of spewing data out of udp port 53 - no mem allocations, no file opens, no 
syncs, no setuid/setgids, no chroot, no cds, no readdir, no write, no 
read, no bind/listen, etc...  [It's also djbdns so it's pretty secure even 
without that :)]

We should really standardize and mainline include some sort of solution 
like this - a sort of finer grained capability list - we'd need approx 
around 300 bits/switches per process at least.

Cheers,
MaZe.

Re: why are capabilities disabled?

[Chris Wright]

* Maciej Zenczykowski (maze@cela.pl) wrote:
> > or less). Also note that exploited code can cause an exec() in a program
> > that doesn't even have a call to exec() in it....
> 
> Obviously a program without exec in it should not have the 
> right/priviledge/capability to call exec period.

Add shared libraries and this distinction gets much less clear, at least
from a static analysis point of view.

> We should provide some sort of way for each process directly after 
> start-up (or later on, after it's done ssetting up whatever) to declare 
> which syscalls (subfunctions for networking) it will 
> never use so that they can be quickly and efficiently disabled to ENOSYS 
> or EDISABLED or whatever.  Such 'capabilities' should be per pid per 
> syscall/subfunction and should be inherited over fork/exec and should only 
> be allowed to be set (no enabling by self - only by a process with that 
> syscall only enabled for another process with it disabled).

While this is interesting, it quickly hits limitations.  Many programs
will need to open/read/write, for example.  So mediating at the syscall
level is only moderatly useful.  LSM gives finer grained mediation points,
and something like SELinux using LSM allows you to do what you've done,
and is much more flexible.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: why are capabilities disabled?

[Chris Wright]

* Sven Köhler (skoehler@upb.de) wrote:
> >>"getpcaps 1" shows, that the init-process is started without 
> >>cap_setpcap, and i know that i can change that somehow.
> >>So why are capabilities disabled? and how do i enable them?

Oh, I see.  Not having cap_setpcap does not mean capabilities are
disabled.  It's the standard set.

> i found the hint again: i have to change the value CAP_INIT_EFF_SET in 
> capability.h, so that init-process is not started with disabled 
> cap_setpcap, but is this still a security risk?

Yes.  Don't do that.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: why are capabilities disabled?

[Sven Köhler]

> If capabilities aren't still too unmature, wouldn't it be fine to have 
> an option in "make menuconfig" to enable them?

Is
   Security Options -> Enable security models -> Default Capabilities
what i'm searching for?

Re: why are capabilities disabled?

[Chris Wright]

* Sven Köhler (skoehler@upb.de) wrote:
> > If capabilities aren't still too unmature, wouldn't it be fine to have 
> > an option in "make menuconfig" to enable them?

they've been in the kernel since 2.2 days.

> Is
>    Security Options -> Enable security models -> Default Capabilities
> what i'm searching for?

That will do it.  If you don't enable security models you'll get
capabilities as the default (to be most compatible with 2.4 kernels).

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net