lkml.org 
[lkml]   [2004]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: why are capabilities disabled?
* 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.731 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site