From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Date: Thu, 09 Dec 2010 13:05:21 -0500 Message-ID: <1291917921.12683.4.camel@localhost.localdomain> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> <1291909941.3072.70.camel@localhost.localdomain> <19713.5738.653711.301814@quad.stoffel.home> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, shemminger@vyatta.com, jeffm@suse.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA. To: John Stoffel Return-path: In-Reply-To: <19713.5738.653711.301814@quad.stoffel.home> List-ID: On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote: > >>>>> "Eric" == Eric Paris writes: > > Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: > >> >>>>> "Eric" == Eric Paris 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com ([209.132.183.28]) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1PQktn-0001Cl-6V for linux-mtd@lists.infradead.org; Thu, 09 Dec 2010 18:07:24 +0000 Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation From: Eric Paris To: John Stoffel In-Reply-To: <19713.5738.653711.301814@quad.stoffel.home> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> <1291909941.3072.70.camel@localhost.localdomain> <19713.5738.653711.301814@quad.stoffel.home> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 13:05:21 -0500 Message-ID: <1291917921.12683.4.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: jfs-discussion@lists.sourceforge.net, jack@suse.cz, penguin-kernel@I-love.SAKURA.ne.jp, jeffm@suse.com, jmorris@namei.org, dhowells@redhat.com, linux-mm@kvack.org, linux-mtd@lists.infradead.org, shaggy@linux.vnet.ibm.com, shemminger@vyatta.com, hch@lst.de, hughd@google.com, joel.becker@oracle.com, cluster-devel@redhat.com, aelder@sgi.com, kees.cook@canonical.com, linux-ext4@vger.kernel.org, sds@tycho.nsa.gov, paul.moore@hp.com, mfasheh@suse.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, dchinner@redhat.com, eparis@parisplace.org, swhiteho@redhat.com, chris.mason@oracle.com, tytso@mit.edu, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-btrfs@vger.kernel.org, casey@schaufler-ca.com, adilger.kernel@dilger.ca, akpm@linux-foundation.org, dwmw2@infradead.org, ocfs2-devel@oss.oracle.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote: > >>>>> "Eric" == Eric Paris writes: > > Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: > >> >>>>> "Eric" == Eric Paris 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9I5sgW050863 for ; Thu, 9 Dec 2010 12:05:54 -0600 Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation From: Eric Paris In-Reply-To: <19713.5738.653711.301814@quad.stoffel.home> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> <1291909941.3072.70.camel@localhost.localdomain> <19713.5738.653711.301814@quad.stoffel.home> Date: Thu, 09 Dec 2010 13:05:21 -0500 Message-ID: <1291917921.12683.4.camel@localhost.localdomain> Mime-Version: 1.0 List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: John Stoffel Cc: jfs-discussion@lists.sourceforge.net, jack@suse.cz, jeffm@suse.com, jmorris@namei.org, dhowells@redhat.com, linux-mm@kvack.org, linux-mtd@lists.infradead.org, shaggy@linux.vnet.ibm.com, shemminger@vyatta.com, hch@lst.de, penguin-kernel@I-love.SAKURA.ne.jp, hughd@google.com, joel.becker@oracle.com, cluster-devel@redhat.com, aelder@sgi.com, kees.cook@canonical.com, linux-ext4@vger.kernel.org, sds@tycho.nsa.gov, paul.moore@hp.com, mfasheh@suse.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, xfs-masters@oss.sgi.com, viro@zeniv.linux.org.uk, dchinner@redhat.com, eparis@parisplace.org, swhiteho@redhat.com, chris.mason@oracle.com, tytso@mit.edu, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-btrfs@vger.kernel.org, casey@schaufler-ca.com, adilger.kernel@dilger.ca, akpm@linux-foundation.org, dwmw2@infradead.org, ocfs2-devel@oss.oracle.com On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote: > >>>>> "Eric" == Eric Paris writes: > > Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: > >> >>>>> "Eric" == Eric Paris 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. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Date: Thu, 09 Dec 2010 13:05:21 -0500 Subject: [Ocfs2-devel] [PATCH] fs/vfs/security: pass last path component to LSM on inode creation In-Reply-To: <19713.5738.653711.301814@quad.stoffel.home> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> <1291909941.3072.70.camel@localhost.localdomain> <19713.5738.653711.301814@quad.stoffel.home> Message-ID: <1291917921.12683.4.camel@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: John Stoffel Cc: xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, shemminger@vyatta.com, jeffm@suse.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA. On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote: > >>>>> "Eric" == Eric Paris writes: > > Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: > >> >>>>> "Eric" == Eric Paris 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756664Ab0LISH4 (ORCPT ); Thu, 9 Dec 2010 13:07:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38486 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755375Ab0LISHy (ORCPT ); Thu, 9 Dec 2010 13:07:54 -0500 Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation From: Eric Paris To: John Stoffel Cc: xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, shemminger@vyatta.com, jeffm@suse.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey@schaufler-ca.com, kees.cook@canonical.com, dhowells@redhat.com In-Reply-To: <19713.5738.653711.301814@quad.stoffel.home> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> <1291909941.3072.70.camel@localhost.localdomain> <19713.5738.653711.301814@quad.stoffel.home> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 13:05:21 -0500 Message-ID: <1291917921.12683.4.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote: > >>>>> "Eric" == Eric Paris writes: > > Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: > >> >>>>> "Eric" == Eric Paris 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with SMTP id A5CD86B0087 for ; Thu, 9 Dec 2010 13:06:41 -0500 (EST) Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation From: Eric Paris In-Reply-To: <19713.5738.653711.301814@quad.stoffel.home> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> <1291909941.3072.70.camel@localhost.localdomain> <19713.5738.653711.301814@quad.stoffel.home> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 13:05:21 -0500 Message-ID: <1291917921.12683.4.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: John Stoffel Cc: xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, shemminger@vyatta.com, jeffm@suse.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey@schaufler-ca.com, kees.cook@canonical.com, dhowells@redhat.com List-ID: On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote: > >>>>> "Eric" == Eric Paris writes: > > Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: > >> >>>>> "Eric" == Eric Paris 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: email@kvack.org