[cap-talk] Linux Caps for 'non priviledged' operations?
iang at systemics.com
Sat Nov 4 09:19:55 CST 2006
Rob J Meijer wrote:
> It would seem very natural if you could:
> * create a socket pair.
> * fork
> * 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 authorit
Thanks for that .. that was the sort of process that
was lurking in my mind and I'm grateful for someone
else to expend the grey matter to put it down on text.
> You've basically just described Plash....
Excellent! Now I know what Plash does!
> 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.
It just occurred to me that in the dim dark distant
past, around the early 80s, the notion of the poor
security encapsulation of system calls was well
understood by the classical race condition. That
is, one created a temporary file by name, and then
one chmod'd it to an appropriate mode so others
could not write to it. (My recollection might be
faulty on the details...)
This race attack was exploited in 1980 that I know
of against the C compiler. When the root user
compiled a program, a student dived in and moved
in a different file, already opened in r/w mode.
The immediate solution when discovered was to
make /tmp unreadable :)
What is curious ... the point for this perhaps long
winded anecdote ... is that the attack mode and the
weakness was well known. And the real solution
of being able to create resources by handles that
were known to be uniquely held and controlled
was also well known. But there was already
enough momentum in place to stop a wholesale
re-factoring of the system call interface...
More information about the cap-talk