[cap-talk] Directory Fd's and designation

[David Hopwood]

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?

It does sound rather complicated.

Personally I think it's unlikely that many apps will be rewritten in an
object-capability style unless they are using a high-level message passing
API (or message passing language) that is designed to make that as easy
as possible.

An application that uses such an API or language should not be depending
on how (or whether) capabilities are supported using particular OS
primitives such as file descriptors, and so in that sense, the
implementation is a secondary issue (although it is important that
the implementation be simple enough to enable confidence in its
correctness/security).

[...]
> 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."  [...]

If I understand correctly,

 - Plash's current "chroot+setuid" jail implementation has significant
   limitations, including inability to control network access
   (http://plash.beasts.org/wiki/ChrootSetuidJail).

 - part of Rob's motivation in suggesting a design that relies on
   kernel support is to enable a more complete jail implementation.

Has it been considered to use VServer (linux-vserver.org), OpenVZ, or
some similar "virtual private server" implementation
<http://en.wikipedia.org/wiki/Operating_system-level_virtualization>,
together with the Plash objcap protocol?

That seems to be a better fit to the requirements than either AppArmor
(which is designed for more static security policies than are typical
of objcap systems), or a chroot+setuid jail.

I don't know how it compares to the proposed "ptrace jail"
(http://plash.beasts.org/wiki/PtraceJail). However, since Bitfrost
also uses VServer, this approach also potentially allows the Bitfrost
environment to be extended to support capability communication
between applications, without unnecessary duplication of mechanism.

(There would be some duplication between the Plash protocol and D-BUS,
but if that is considered a problem, perhaps enough of the D-BUS API
to support Sugar apps could be reimplemented on top of Plash.)

> 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.

I agree with this.

-- 
David Hopwood