On Thursday 24 May 2007 15:19, James Morris wrote:
> 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,
I guess I see what you are getting at. If a user has read/write access
to /views/sysadmin/etc/shadow and if that is an alias for /etc/shadow, then
of course it doesn't help to give the user only read access to /etc/shadow to
protect that file. So you can shoot yourself in the foot with mounts, and
also with hardlinks. That's why confined processes are not allowed to mount
stuff, and why hardlinks requires the appropriate profile permissions.
AppArmor depends on the namespace so it cares about namespace manipulations,
just like SELinux depends on labels so labels matter there.
> 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:
Read it like this: we don't have a good idea how to support multiple
namespaces so far. Currently, we interpret all pathnames relative to the
namespace a process is in. Confined processes don't have the privilege to
create or manipulate namespaces, which makes this safe. We may find a better
future solution.
> 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" ?
I'm not aware of situations where giving different permissions to different
paths to the same file would actually be useful. The security model doesn't
prevent it though, and it's not a security hole.
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
