Re: why are capabilities disabled?

[Chris Wright <chrisw@osdl.org>]

* 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