[cap-talk] MinorFs: delegation now works

[Rob Meijer]

First let me start of by asking if there is anyone here besides me who
thinks me posting my progress on MinorFs is relevant? I didn't get any
replies on my previous progress post, so possibly I'm working on an area
that is of very low interest to people on this list.
If this is the case I'll stop posting them.

I've just bundled a new alpha version of MinorFs.

http://polacanthus.net/minorfs-0.0.2.tar.gz

MinorFs is a set of simple fuse userspace filesystems for Linux aimed
to be learning tools for practical POLA/POPL usage in a Linux environment.
The main result of this learning tool focus is that performance has not
been a design or implementation focus.

Where the previous version only implemented private storage for pseudo
persistent processes, the new version now allows these processes to take
a file or directory from its private directory tree, request a password
capability path from this file or directory (by requesting the
'delegatable' extended attribute). This capability path than can be
communicated with any
other process using paths of communication (these paths of communication
are not provided by the file system, but are in my view over sufficiently
available in the Linux environment).

I'll past the README of the project below

Rob
----------------------------------------------------------------------
MinorFs is a set of simple user space filesystems that work together to
provide the folowing functionality:

* Nth claim persistent processes (minorviewfs)
* Persisten private storage      (minorviewfs)
* Delegation                     (minorcapfs)

Future versions shall also include:
* Revocation                     (minorcaretakerfs)
* Attenuation                    (minorcaretakerfs)


This readme gives a short explanation of how the seperate filesystems
work and how they work together.

MinorViewFs creates a private directory for processes. Given that processes
and their base identification (pids) are non persistent, and storage is
persistent, the MinorViewFs filesystem allows processes the possibility to
'claim' an unused slot that was previously used by a process that was an
instance of the same executable running under the same user id as the current
process.
This claiming of a slot turns the process into an incarnation of some
'persistent' process, allowing it to make use of the 'private' directory
to store its state.

MinorFs allows most operations that a normal filesystem allows, but there
are some differences. Links and symlinks are not supported, and chmod
operations
don't have any effect given that they are useless with respect to the
security model that minorviewfs provides.

Please note that minorviewfs does not work well together with scripts, as
the data will become private to the interpreter rather than to the script.
Further note that currently persistent storage is limited to 32 concurent
versions of the same program running with the same uid.

An important operation that MinorViewfs provides that makes it work together
well with MinorCapFs is the use of a special extended attribute.
The extended attribute 'delegatable' that is made available for each file
and directory, returns a path to the same underlaying directory but than
through MinorCapFs. In contrast to the MinorViewFs paths, the paths into
MinorCapFs can be delegated to other processes, even to other users.
The MinorCapFs paths contain a token that is in fact a very basic
implemetation of a so called 'password capability'.


Attenuation and revocations are not yet addressed in this version
of minorfs.
The upcomming version of minorfs will aim to also provide additional minor
filesystems for these purposes.

New versions will be available shortly on: http://polacanthus.net/

If you run into any bugs or problems, I will be very gratefull if you could
report them to : minorfs at polacanthus.net