[cap-talk] Linux Caps for 'non priviledged' operations?

Rob J Meijer rmeijer at xs4all.nl
Sun Nov 5 03:42:48 CST 2006

>> 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 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.
> Implied ambient authority? Man, I must be getting
> rusty. I have no idea what you're talking about,
> and I've been doing this stuff for a loong time.

This realy is basic POLA stuff. I know explaining this will
lead to confusion, as the POLA comunity uses quite a different
meaning for 'capability'. Here a capability 'bundles' authority
with designation. Thus any system call that from a POLA point of view
bundles authorization with designation (as for example a read does
where the filehandle 'is' the capability) would not imply the use of
ambient authority. Is this making any kind of sense to you?
A call like 'open' however will provide a path to a file that in no
way conveys any authority to this file by itself. The authority is so
to speak just floating around. The system call does thus imply the use
of 'ambient' authority. Is this rining any bells or is this completely
foreign to you? If it is, I would like to refer you to the exelent
talk by Mark Miller : http://www.erights.org/talks/index.html#google-abac

>> Wouldn't it be a good idea to ad such (maybe
>> multiple would be desired for
>> other purposes) Linux Cap for non-priviledged
>> operations?
> No. They are non-privileged, therefore they
> don't need capabilities. Capabilities control
> access to privileged operations.

>From a POSIX point of view they arn't, but from a POLA point of view they
modt definitly are.It would seem that just as a root process does not need
to run with all root priviledges, in the same way a user process would not
need to run with all a users priviledges. Linux Caps would seem like a
completely natural fit in that way, or am I missing something.


More information about the cap-talk mailing list