Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

James Morris
2007-05-24T13:19:49Z

On Thu, 24 May 2007, Andreas Gruenbacher wrote:

> > Would you mind providing some concrete examples of how such a model would
> > be useful?
>
> The model is explained, with examples, in the technical documentation at http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/.

I'm asking specifically about a model where you'd want to provide
differing access to the same objects based on the pathname used for
access to the objects, per:

"If files are mounted at multiple locations, then the policy may allow
access to some locations but not to others. That's not a hole."

I don't see specific examples of this kind of policy in that document,
and the document seems to be saying quite the opposite -- that the AA
policy is only valid in conjunction with further constraints on how the
objects may be accessed:

Section 3.2:

"Pathnames are meaningful only within a namespace. Each namespace has a
root where all the files, directories, and mount points are hanging off
from.

The privilege of creating new namespaces is bound to the CAP_ SYS_ ADMIN
capability, which grants a multitude of other things that would allow a
process to break out of AppArmor confinement, so confined processes are
not supposed to have this privilege, and processes with this capability
need to be considered trusted. "

I can restate my question and ask why you'd want a security policy like:

Subject 'sysadmin' has:
read access to /etc/shadow
read/write access to /views/sysadmin/etc/shadow

where the objects referenced by the paths are identical and visible to the
subject along both paths, in keeping with your description of "policy may
allow access to some locations but not to others" ?

- James
--
James Morris
<jmorris@namei.org>