[apparmor] Denying a sub-tree to unconfined processes?
Rob Meijer
pibara at gmail.com
Fri Dec 2 23:35:49 UTC 2011
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.
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? And if so, would you consider this as a feature
request for future versions of AppArmor, or does such a feature
actually already exist?
More information about the AppArmor
mailing list