[Apparmor-dev] MinorFs 0.3 & AppArmor

[Rob Meijer]

On Tue, July 8, 2008 11:10, John Johansen wrote:
> Rob Meijer wrote:
>> I just finished up the 0.3 version of Minorfs, and its available on
>> http://polacanthus.net/minorfs.html
>>
>> The goal of MinorFs is to provide a set of userspace filesystems that
>> allow
>> applications (to be more exact, pseudo persistent processes) to have
>> their
>> own private storage in a decomposable and (ocap like) delegatable way.
>>
>> MinorFs and AppArmor are complementary as the capability paradigm
>> warants
>> that      active objects start of with an absolute minimum of privileges
>> (AppArmor) that are than extended by delegations (MinorFs).
>>
>> I think it might be a good idea to see if integrating MinorFs into the
>> userspace tools of AppArmor would be possible, and if some tasks (like
>> identifying pseudo persistent processes) should better move to
>> kernelspace.
>>
>> Please let me know if you guys agree this would be a good idea.
>>
> Hrmm, it is something that needs some more investigation, but I am
> certainly not opposed to the idea.  I am however curious as to
> specifically what you mean by integration into the user space tools.
>
> Do you see the profiling tools being used to identify pseudo persistent
> processes?  Being used to track the fd flow between processes/profiles?
> How do you see it fitting into profiling, or do you mean a more general
> extension of the user space tools?

MinorFs uses strong paths as passwordcaps, not fd's as caps.
I did mean a more general extension of userspace tools, but with respect
to profiling there might however also be some possibilities with respect
to profiling. MinorViewFs provides a 'private' home and temp symlink into
MinorCapFs. It might be possible to extend the profiling tools to
determine if a program would be suitable for having its home and temp dirs
forced to these private directories. (A private home or private temp is
readable to
the owning pseudo persistent process only unless that process chooses to
delegate (part of) that directory).

With AppArmor, giving a (new) application access to anything under
/mnt/minorfs and hardly anything else, would give instances of that
program access only to its own private home and temp storage.
The private storage can than be decomposed and delegated by those
processes.
Giving it access to /mnt/minorfs/cap but not /mnt/minorfs/view would
give the process access only to 'delegated' storage but no private
storage.

MinorViewFs currently goes to a lot of trouble parsing /proc files in
order to uniquely identify pseudo persistent processes, I feel there may
be major performance improvements possible if uniquely identifying pseudo
persistent processes could be done by the kernel space part of AppArmor.

Let me give a short description of how MinorFs works. MinorFs currently
consists of two user space file systems (MinorCapFs and MinorViewFs)  and
a user level administration tool (2rulethemall).
MinorCapFs is mounted at /mnt/minorfs/cap and listing /mnt/minorfs/cap
would give back an empty directory. MinorCapFs proxies a real directory
tree under
/var/minorfs/data, and each node (fiel or dir) under /var/minorfs/data is
made available thruegh a unique 'strong path' like for example:
  /mnt/minorfs/cap/dbc99e406bbac6412a0a6cbad0cdd1a629576a15
The dbc99e406bbac6412a0a6cbad0cdd1a629576a15 part is like a rw password
capability to the file or dir designated. If this node happens to be a
dir, than sub directories and files are accessible normally like:
  /mnt/minorfs/cap/dbc99e406bbac6412a0a6cbad0cdd1a629576a15/foo/bar.txt
But using the 'cap' extended attribute of a node, each file or directory
under a node is also accessible using its own strong path. This way any
MinorFs aware program (or user) can decompose access to a directory using
the extended attribute interface.

MinorViewFs has access to a high level rw cap into MinorCapFs that it uses
to create, delete and delegate sub directories to what it determines to be
uniqely identified pseudo persistent processes. A pseudo persistent
process is an incarnation of an invocation of a program that has the same
binary files loaded into its /proc/$PID/maps, and has a chain of parent
processes up to init that all have the same binary files loaded into their
/proc/$PID/maps, and runs under the same AppArmor profile as its
predecesor. and next to that optionally (depending on config files) has
the same command line arguments and/or specific values of config specified
environment variables. A pseudo persistent process also 'claims' a slot,
so that multiple instances with the same calling chain are seen as
distinct pseudo persistent processes if they run at the same time.

MinorViewFs parses the /proc/$PID/ files for the invoking process and its
parent processes, creates an XML representation of relevant data, and uses
the SHA1 digest of this XML data as a unique identifier for the process
and its call path, that it than together with the 'slot' uses to create
and delegate the 'private' home.
The /mnt/minorfs/priv will thus contain two symbolic links, the first one
'home' pointing to the private home directory that MinorViewFs created
inside of MinorCapFs for the pseudo persistent process.

MinorViewFs also creates (and deletes) a private 'temp' directory in
MinorCapFs for regular process id's. Ones the process dies, the temp
directory is removed.

In the near future I will be extending MinorFs with more pseudo
filesystems in order to allow for attenuated access to files and
directories.

I hope this short description of MinorFs and how it (currently) works with
and depends on AppArmor clarifies my views.

Rob J Meijer