Date: Thu, 24 May 2007 11:58:41 -0700 (PDT)
From: Casey Schaufler <casey@schaufler-ca.com>
Reply-To: casey@schaufler-ca.com
Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
To: Andreas Gruenbacher <agruen@suse.de>, James Morris <jmorris@namei.org>
Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org,
       linux-fsdevel@vger.kernel.org
In-Reply-To: <200705242010.00961.agruen@suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <309300.41401.qm@web36615.mail.mud.yahoo.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1546
Lines: 33


--- Andreas Gruenbacher <agruen@suse.de> wrote:

> > 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.

On Fedora zcat, gzip and gunzip are all links to the same file.
I can imagine (although it is a bit of a stretch) allowing a set
of users access to gunzip but not gzip (or the other way around).
There are probably more sophisticated programs that have different
behavior based on the name they're invoked by that would provide
a more compelling arguement, assuming of course that you buy into
the behavior-based-on-name scheme. What I think I'm suggesting is
that AppArmor might be useful in addressing the fact that a file
with multiple hard links is necessarily constrained to have the
same access control on each of those names. That assumes one
believes that such behavior is flawwed, and I'm not going to try
to argue that. The question was about an example, and there is one.


Casey Schaufler
casey@schaufler-ca.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/