[apparmor] Retrofitting & access-control impedance mismatch for MinorFs
rmeijer at xs4all.nl
Mon Jun 24 07:16:47 UTC 2013
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
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
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
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
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?
Rob J Meijer
More information about the AppArmor