The idea behind this is with confined -> unconfined the access is allowed because unconfined has no restrictions to begin with, so we allow passing the fd without a validation check. For unconfined -> confined we also allow it because we perform so-called ‘implicit delegation’. For confined -> confined (and the special case of confined -> unconfined -> confined) we’ll do a revalidation. It is implemented this way to try to maintain a level of security (confined -> confined) but also usability for profilers (unconfined -> confined, confined -> unconfined). While it is a fine intermediary step, on the AppArmor roadmap are various improvements to make things work better:
- policy delegation - where delegation is specified in policy
a. rule delegation (eg,px -> firefox + { /foo rw, /bar r, }(syntax TBD)
b. object delegation - where only an object (not rules) is delegated. Idea is, parent opens a file, passes the object to the child for the child to use. The child can use it but not open it on its own (rule delegation would also allow open) - Application directed delegation
a. rule delegation - where an application can direct apparmor to delegate some rules via an api
b. object delegation - where an application can direct apparmor to delegate a specific object only (eg, a particular fd to use, but not open)
With this delegation work, fds that have been delegated don’t undergo revalidation and so no extra policy bits are needed. This will work across namespace boundaries too, which will take care of a lot of our disconnected path issues (ie, can remove ‘attach_disconnected’). ‘1’ should allow us to let delegation happen for your use case, thus avoiding revalidation and the denial.
The above is just an overview of the roadmapped items. If you’re interested in more details, I suggest participating on the apparmor mailing list or discussing on irc in #apparmor on OFTC.