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

[Crispin Cowan]

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.
I agree with Mark's concern; AppArmor is primarily about protecting
existing code, and secondarily (if at all) about facilitating better new
programming models.

>   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.
>   
So perhaps what is needed here is minimal support in the kernel module
for Rob's directory-FD idea, and do most of the work in userland
libraries for programs that want to do that kind of thing?

If not, then some other form of stacking may be called for. It would be
bad for AppArmor to absorb a lot of complexity to accommodate new
programming paradigms that are not currently in use. But it would be
good for AppArmor to help provide a basis for a more complex system that
does enable a practical advance in application programming security by
enabling more use of Object Capabilities.

Crispin

> 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 implemented by the kernel.
>
> For example, Plash provides several directory proxy objects that
> implement Plash's FsObj interface
> (http://plash.beasts.org/wiki/FsObj), including:
>  * FsObjReadOnly: a proxy object that allows only read access to the
>    object being wrapped
>  * FsObjCopyOnWrite: layered/copy-on-write directories
>  * FsObjUnion: union directories
>  * FsObjFab: in-memory-only directories and symlinks
>  * FsObjMountTable: proxy object for implementing namespaces
>
> Of these, only FsObjReadOnly could be implemented using the kind of
> permission bits on directories that you are proposing.
> FsObjMountTable is quite important for implementing a file powerbox
> interface for legacy programs, i.e. for binding files/directories into
> a file namespace dynamically.
>
> The only point on your list that can't straightforwardly be
> implemented in user space is the fifth one -- "Process A defines that
> its next child should run starved from any access permissions."  BTW,
> it would be cleaner if a process could drop permissions after fork()
> and before execve() than if it requested that permissions be dropped
> on the next fork().
>
> I really think to get the benefit of the object-capability model you
> need to have proxyable objects, otherwise there is no extensibility.
> You need proxyability in order to make it easy to build abstractions
> for access control.
>
> Regards,
> Mark
> _______________________________________________
> Apparmor-dev mailing list
> Apparmor-dev at forge.novell.com
> http://forge.novell.com/mailman/listinfo/apparmor-dev
>
>   

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work