[apparmor] Denying a sub-tree to unconfined processes?

[John Johansen]

On 12/02/2011 03:35 PM, Rob Meijer wrote:
> Progress on MinorFs2 is proceding slowly, but there is progress,
> design is basically ready and I've started on re-implementing the
> first file-system in Python.
Well thats good to here, I know how hard it can be to get progress
on a project sometimes.

> MinorFs2 basically consists of 3 distinct file-systems. The low-lever
> cap_fs, and two higher level file-systems tmp_fs and home_fs.
> In the current design, cap_fs has no knowledge of whether a process is
> confined by AppArmor or not. Most processes will access cap_fs only
> trough home_fs and tmp_fs,
> but a MinorFs2 aware program may make use of cap_fs directly and thus
> profit from the fine-grained dynamic discretionary access-control it
> offers.
> There is however a problem with programs using cap_fs directly. An
> unconfined process running as the same user as a process that uses
> cap_fs directly
> will be able to steal and use sparse capabilities by accessing
> /proc/$PID/. If would be an interesting concept to counteract this by
> disallowing unconfined processes
> from accessing cap_fs altogether, so an unconfined process could steal
> but not use cap_fs caps.
> In the current design however, cap_fs has no knowledge of whether a
> process that accesses it is running unconfined. I would prefer it if
> this could stay as such as changing it will likely impact performance.
> 
> If AppArmor could be configured such that it could deny access to
> anything under the cap_fs mount-point to all unconfined processes.
> Does this make sense?

Yes it makes sense, at least from a I understand what you would like
pov.  This actually plays some what into my earlier email

https://lists.ubuntu.com/archives/apparmor/2011-November/001732.html

> And if so, would you consider this as a feature
> request for future versions of AppArmor,

possibly, the question is do we want to change the meaning of unconfined
so it can do some mediation, or do we just want to use other means to
do it like a default profile /**.

Part of the decision is based on what use cases there are, what is the
cleanest solution, etc.

> or does such a feature actually already exist?
> 
not within unconfined no, but you could define a default profile /**
which will attach to all executable that don't have a better matching
profile.  Again it comes down to semantics is /** any different than
unconfined (currently yes), and what do we want going forward.