linux-kernel - Re: [AppArmor 01/41] Pass struct vfsmount to the inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 May 2007 20:10:00 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	James Morris <jmorris@...ei.org>
Cc:	Al Viro <viro@....linux.org.uk>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	Tony Jones <tonyj@...e.de>
Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/