[apparmor] Retrofitting & access-control impedance mismatch for MinorFs

[John Johansen]

On 06/24/2013 12:16 AM, Rob Meijer wrote:
> I'm working on a retrofit version of the MinorFs system and one particular
> 'fix' seems to lead to the large scale promotion of processes to
> confusable deputies.
> 
> MinorFs consists of multiple user-space file-systems. At the core of the
> system we have a filesystem called CapFs that uses sparse-caps that give
> access to node's in set of decomposable attenuatable directed tree graphs
> of directories and files.
> 
> I basically have two options for fitting the higher level file-systems on
> top of CapFs:
> 
> 1) As overlay file-systems.
> 2) As redirecting file-systems.
> 
> Where option one has the advantage of safely allowing even
> non-AppArmor-confined processes the use of their own multi-granular
> private storage, it does take away the ability to decompose,attenuate and
> delegate ones private storage sub-tree to other processes.
> 
> Option two has the advantages of better performance and full decomposition
> attenuation and delegation support, but these come at a price for
> mixed-mode systems. The problem is that on Linux systems that come with
> AppArmor (the static least privilege access control system for Linux that
> MinorFs aims to complement with dynamic least privilege options), most
> notably Ubuntu and Suse, the set of available AppArmor profiles is rather
> incomplete. That means that for now on these systems part of the processes
> will be running AppArmor confined while other processes won't.
> 
> An unconfined process has access to the special per process id directories
> under /proc (at least for processes running under the same user id) that
> contain some information on the internals of other processes, most notably
> information on open file handles that basically could contain the CapFs
> sparse-cap. An unconfined process thus would be able to see some of the
> authority tokens for files that other processes running under the same uid
> are accessing.
> 
> My first thought on this was that this wouldn't be a problem, given that I
> would simply fully deny raw CapFs access to any non-AppArmor-confined
> process.
> 
> On second thought however this 'solution' creates an other problem: A
> process that does run under an AppArmor confined profile could potentially
> become a confused deputy. That is, an unconfined program could steal an
> authority token from one confined program trough the /proc file-system,
> and while it can't use this token itself, it could delegate the stolen
> token to a second confined process that might than act as a confused
> deputy.
> 
This really sounds like you want some global policy in this case preventing
tasks from accessing what doesn't belong to them.

This is possible in apparmor 2.x but is really hard to do.  apparmor 3
which is currently in dev makes it much easier to add and replace a default
profile.

> 
> I would really like to hear the thoughts of others on this mailing-list on
> this. Should I give up on combining a retrofit version of MinorFs with the
> non-retrofit features of decomposition, attenuation and delegation? Should
> I add the confinement check for CapFs access or is this a futile addition
> that is to easily bypassed?  Or should I just provide a massively
> permissive profile that could be used for all currently unconfined
> processes and allows almost everything except for the specific places
> under /proc where sparse-caps could be stolen?
> 
So if I was to do the restrictions via apparmor I would make a default profile
and disallow access to the special files. Any process that needs access to
a token file is under a different profile. So tighter than what you propose
above, and you can have fairly loose special profiles that have access to
a subset of the special files.

I need to reread so of the minorfs details again before I could propose a
solution in greater detail.

As to whether 1 or 2. I really like "the ability to decompose,attenuate and
delegate ones private storage sub-tree to other processes.", the question
is whether its worth the cost.