[cap-talk] Linux Caps for 'non priviledged' operations?
Rob J Meijer
rmeijer at xs4all.nl
Thu Nov 9 09:48:39 CST 2006
> To reinterate: In the context of the Linux
> kernel capabilities are the mechanism by
> which a process is allowed to violate
> system policy. Some of the system policy,
> including certain ioctl() calls and
> some resource controls, is not security
> We're talking at length about a hypithetical
> (I know I spelled that wrong. sorry)
> implementation of a policy that hasn't been
> defined. I challenge y'all to propose an
> authority policy. Who knows, maybe it will
> make scence in the context of capabilities.
I will try to lay down a set of system calls and how I believe these
could be put into 'user' ambient linux capabilities that when explicitly
made non inherited before exec could produce a usefull result for POLA
system design on top of it. Althouh hopelessly incomplete, it should
give you some context as to what such capabilities would bring.
I believe people on the cap-talk list will be able to point out a few issues
with the inventarisation below, but as a way to show the general direction
to you and the LSM people it should be reasonably OK.
What I would propose for 'user' Linux capabilities would be something
along the lines of the below description. It's just a quick
inventarisation, so don't take it to be complete, it most likely is not.
I'll try to focus purely on communication and file handle related system
calls as those are the most relevant.
First there are a set of system calls that by their nature imply ambient
authority, and thus could be govened
by user level Linux Caps rather streight forward:
The new 'at' family holds a few calls that in most usage imply ambient
authority, however if and only if the path supplied with these cals is
'relative' and 'down' from the given file descriptor than the directory
file descriptor can be seen as delegatable tokens of authority in the same
way that regular file handles can.
CAP_USER_AMBIENT_FS || PATH_IS_RELATIVE_DOWN(fdX,pathX)
With delegation of directories, DAC could be used to effectively simulate
faccets for entries in delegated directories, however this would be mostly
limited to first delegation. DAC should with POLA only be used with all r,
all w and all x bits synchonized. Further setting of unset bits hould be
allowed,that is the new mode should be a subset of the old value, and DAC
based delegation controlls should not be allowed. (If you are wondering
what about regular DAC security issues, you should only delegate
that have an unguessable name and are contained in a 0700 DAC set directory
CAP_USER_AMBIENT_FS || MODE_IS_SUBSET_NONRESTRICT_DELEGATION(mode,oldmode)
For practical purposes, the loading of libraries can probably not be
restricted for most processes. That is, restriction can mostly only be
done by disallowing untrusted library paths. This one I am realy
uncomfortable with, its definetly not POLA, but we practically might not
be able to do it
CAP_USER_AMBIENT_FS || (CAP_USER_AMBIENT_USELIB && TRUSTED_LIB_PATH(path))
More information about the cap-talk