xfs
[Top] [All Lists]

Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode cr

To: John Stoffel <john@xxxxxxxxxxx>
Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation
From: Eric Paris <eparis@xxxxxxxxxx>
Date: Thu, 09 Dec 2010 13:05:21 -0500
Cc: xfs-masters@xxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, linux-mtd@xxxxxxxxxxxxxxxxxxx, jfs-discussion@xxxxxxxxxxxxxxxxxxxxx, ocfs2-devel@xxxxxxxxxxxxxx, reiserfs-devel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, linux-mm@xxxxxxxxx, linux-security-module@xxxxxxxxxxxxxxx, chris.mason@xxxxxxxxxx, jack@xxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, adilger.kernel@xxxxxxxxx, tytso@xxxxxxx, swhiteho@xxxxxxxxxx, dwmw2@xxxxxxxxxxxxx, shaggy@xxxxxxxxxxxxxxxxxx, mfasheh@xxxxxxxx, joel.becker@xxxxxxxxxx, aelder@xxxxxxx, hughd@xxxxxxxxxx, jmorris@xxxxxxxxx, sds@xxxxxxxxxxxxx, eparis@xxxxxxxxxxxxxx, hch@xxxxxx, dchinner@xxxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx, shemminger@xxxxxxxxxx, jeffm@xxxxxxxx, paul.moore@xxxxxx, penguin-kernel@xxxxxxxxxxxxxxxxxxx, casey@xxxxxxxxxxxxxxxx, kees.cook@xxxxxxxxxxxxx, dhowells@xxxxxxxxxx
In-reply-to: <19713.5738.653711.301814@xxxxxxxxxxxxxxxxx>
References: <20101208194527.13537.77202.stgit@xxxxxxxxxxxxxxxxxxxx> <19712.61515.201226.938553@xxxxxxxxxxxxxxxxx> <1291909941.3072.70.camel@xxxxxxxxxxxxxxxxxxxxx> <19713.5738.653711.301814@xxxxxxxxxxxxxxxxx>
On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote:
> >>>>> "Eric" == Eric Paris <eparis@xxxxxxxxxx> writes:
> 
> Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote:
> >> >>>>> "Eric" == Eric Paris <eparis@xxxxxxxxxx> writes:
> 
> Eric> This patch adds a 4th piece of information, the name of the
> Eric> object being created.  An obvious situation where this will be
> Eric> useful is devtmpfs (although you'll find other examples in the
> Eric> above thread).  devtmpfs when it creates char/block devices is
> Eric> unable to distinguish between kmem and console and so they are
> Eric> created with a generic label.  hotplug/udev is then called which
> Eric> does some pathname like matching and relabels them to something
> Eric> more specific.  We've found that many people are able to race
> Eric> against this particular updating and get spurious denials in
> Eric> /dev.  With this patch devtmpfs will be able to get the labels
> Eric> correct to begin with.
> 
> So your Label based access controls are *also* based on pathnames?
> Right?

Access decisions are still based solely on the label.  This patch can
influence how new objects get their label, which makes the access
decisions indirectly path based.  You'll find a reasonable summary and
commentary on lwn in this weeks security section.

<Prev in Thread] Current Thread [Next in Thread>