[cap-talk] [Apparmor-dev] Re: Directory Fd's and designation

[Rob Meijer]

On Thu, November 22, 2007 20:37, Mark Seaborn wrote:
> "Rob Meijer" <capibara at xs4all.nl> wrote:
>
>> To make a bit clearer what the goal of all this would be, a litle
>> example
>> of its potential use:
>>
>> * Process A runs with all the permissions/authority of user a, or all
>>   permissions defined by the a program AppArmor profile.
>> * Process A creates /home/a/work/input, and writes some files into it.
>> * Process A creates /home/a/work/output
>> * Process A opens a Fd for both directories, sets apropriate mask bits
>> so
>>   the first designates read only access, and the second designates that
>>   new files can be created , but no new directories.
>> * Process A defines that its next child should run starved from any
>> access
>>   permissions.
>> * Process A starts up process B handing it the two directory Fd's.
>> * Process B can use the at* system calls with the directory Fd's,
>>   it can now read all files in the input dir, and write result files
>>   into the output dir, but does not have access to any other permission
>>   that process A or user/program a did.
>
> The question is, what programs will do this?  No existing programs use
> directory FDs this way, so I assume we are talking about new code.

About minor changes to existing code. A lot of programs take directory
paths as arguments. Changing the paths to dirFd's and the non *at calls to
*at calls would make it trivial for the abouve to be used.
The posibility to thus use the abouve is somathing that has major value in
for example computer forensic applications.

>If
> we are talking about new code, why does this need to be done in the
> kernel?  You could do most of this in user space using something like
> the Plash object-capability protocol for accessing directories
> (eg. opening files and receiving FDs as a result), layered on top of
> existing Unix domain sockets.
>
> The ways in which you might want to limit access directories are
> almost limitless and it would be more extensible to implement that by
> proxying in user space rather than trying to pick a set of permission
> bits for directory FDs to be implementeed by the kernel.

I agree that would have much added value, but in my view Fd passing would
be ideal as a basis for this.
I would imagine that communicating Fd's with a Fuse user space filesystem
in the described maner would yield the wanted results that you would want
for Plash, but with the aded bonus that using only the Fd based permission
transfer would be a simple way to 'fix' existing programs into working
under POLA constraints without the need for the userspace overhead.


Rob