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. 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? T.I.A. Rob J Meijer -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
