[cap-talk] Linux Caps for 'non priviledged' operations?
Rob J Meijer
rmeijer at xs4all.nl
Sat Nov 4 01:23:03 CST 2006
Having looked at a few available but rather inconvenient ways to do
POLA on Linux, to me it seems that introducing Caps for 'non priviledged'
operations could be a major step forward for POLA usability of Linux,
especialy when combined with the directory file handles that are now
truegh the 'at' family of system calls.
It would seem very natural if you could:
* create a socket pair.
* close one of the sockets
* child: unset CAP_NONPRIV_AMBIENT as inheritable
* child: exec executable
* parent: open directories, sockets, files etc
* parent: hand over file and directory handles to child through socket
* child: receive directory and file handles.
* child: operate with given handles deprived of any ambient authority
As pointed out on the (LSM) list, current hooks for LSM do not (yet) provide
a mechanism to rigidly distinguish between system calls that imply ambient
authority (for example as I understand from previous replies: open, or
openat if '..' or absolute paths are provided) and those that cary their
authority explicitly (like openat with a '..' less relative path). There
may be other hooks missing as well to distinguish between implied and
ambient authority carying system call invocations.
Wouldn't it be a good idea to ad such (maybe multiple would be desired for
other purposes) Linux Cap for non-priviledged operations? Maybe at first
with a seperate one for ambiguis operations that 'might' and a seperate one
for those operations that clearly 'do' imply ambient authority.
Such a (temporary) division might make it somewhat usable without the need
for aditional hooks. If the usage would get picked up by the POLA comunity,
it might be some leveridge to get acceptance for adding new hooks for LSM
that would be needed for the now aparently ambiguousity of 'at' family
system call usage from the LSM hooks.
Rob J Meijer
More information about the cap-talk