From mboxrd@z Thu Jan 1 00:00:00 1970 From: Serge Hallyn Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Date: Thu, 9 Dec 2010 10:05:49 -0600 Message-ID: <20101209160549.GA2315@peq> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eric Paris , 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, tao.ma@oracle.com, shemminger@vyatta.com, jeffm@suse.com, serue@us.ibm.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey To: John Stoffel Return-path: In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home> List-ID: Quoting John Stoffel (john@stoffel.org): > >>>>> "Eric" == Eric Paris writes: > > Eric> SELinux would like to implement a new labeling behavior of newly > Eric> created inodes. We currently label new inodes based on the > Eric> parent and the creating process. This new behavior would also > Eric> take into account the name of the new object when deciding the > Eric> new label. This is not the (supposed) full path, just the last > Eric> component of the path. > > Eric> This is very useful because creating /etc/shadow is different > Eric> than creating /etc/passwd but the kernel hooks are unable to > Eric> differentiate these operations. We currently require that > Eric> userspace realize it is doing some difficult operation like that > Eric> and than userspace jumps through SELinux hoops to get things set > Eric> up correctly. This patch does not implement new behavior, that > Eric> is obviously contained in a seperate SELinux patch, but it does > Eric> pass the needed name down to the correct LSM hook. If no such > Eric> name exists it is fine to pass NULL. > > I've looked this patch over, and maybe I'm missing something, but how > does knowing the name of the file really tell you anything, esp when > you only get the filename, not the path? What threat are you > addressing with this change? Like you, I keep thinking back to this patch and going back and forth. But to answer your question: in some cases, the name of the file (plus the context of the directory in which it is created) can tell you what assumptions userspace will make about it. And userspace most definately is a part of the TCB, i.e. /bin/passwd and /bin/login. -serge From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from adelie.canonical.com ([91.189.90.139]) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1PQj0i-0008E5-LM for linux-mtd@lists.infradead.org; Thu, 09 Dec 2010 16:06:28 +0000 Date: Thu, 9 Dec 2010 10:05:49 -0600 From: Serge Hallyn To: John Stoffel Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Message-ID: <20101209160549.GA2315@peq> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home> 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, serue@us.ibm.com, shaggy@linux.vnet.ibm.com, shemminger@vyatta.com, hch@lst.de, hughd@google.com, joel.becker@oracle.com, cluster-devel@redhat.com, tao.ma@oracle.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, Eric Paris , 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: , Quoting John Stoffel (john@stoffel.org): > >>>>> "Eric" == Eric Paris writes: > > Eric> SELinux would like to implement a new labeling behavior of newly > Eric> created inodes. We currently label new inodes based on the > Eric> parent and the creating process. This new behavior would also > Eric> take into account the name of the new object when deciding the > Eric> new label. This is not the (supposed) full path, just the last > Eric> component of the path. > > Eric> This is very useful because creating /etc/shadow is different > Eric> than creating /etc/passwd but the kernel hooks are unable to > Eric> differentiate these operations. We currently require that > Eric> userspace realize it is doing some difficult operation like that > Eric> and than userspace jumps through SELinux hoops to get things set > Eric> up correctly. This patch does not implement new behavior, that > Eric> is obviously contained in a seperate SELinux patch, but it does > Eric> pass the needed name down to the correct LSM hook. If no such > Eric> name exists it is fine to pass NULL. > > I've looked this patch over, and maybe I'm missing something, but how > does knowing the name of the file really tell you anything, esp when > you only get the filename, not the path? What threat are you > addressing with this change? Like you, I keep thinking back to this patch and going back and forth. But to answer your question: in some cases, the name of the file (plus the context of the directory in which it is created) can tell you what assumptions userspace will make about it. And userspace most definately is a part of the TCB, i.e. /bin/passwd and /bin/login. -serge From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9G4Wap032174 for ; Thu, 9 Dec 2010 10:04:32 -0600 Date: Thu, 9 Dec 2010 10:05:49 -0600 From: Serge Hallyn Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Message-ID: <20101209160549.GA2315@peq> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home> 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, serue@us.ibm.com, 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, tao.ma@oracle.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, Eric Paris , 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 Quoting John Stoffel (john@stoffel.org): > >>>>> "Eric" == Eric Paris writes: > > Eric> SELinux would like to implement a new labeling behavior of newly > Eric> created inodes. We currently label new inodes based on the > Eric> parent and the creating process. This new behavior would also > Eric> take into account the name of the new object when deciding the > Eric> new label. This is not the (supposed) full path, just the last > Eric> component of the path. > > Eric> This is very useful because creating /etc/shadow is different > Eric> than creating /etc/passwd but the kernel hooks are unable to > Eric> differentiate these operations. We currently require that > Eric> userspace realize it is doing some difficult operation like that > Eric> and than userspace jumps through SELinux hoops to get things set > Eric> up correctly. This patch does not implement new behavior, that > Eric> is obviously contained in a seperate SELinux patch, but it does > Eric> pass the needed name down to the correct LSM hook. If no such > Eric> name exists it is fine to pass NULL. > > I've looked this patch over, and maybe I'm missing something, but how > does knowing the name of the file really tell you anything, esp when > you only get the filename, not the path? What threat are you > addressing with this change? Like you, I keep thinking back to this patch and going back and forth. But to answer your question: in some cases, the name of the file (plus the context of the directory in which it is created) can tell you what assumptions userspace will make about it. And userspace most definately is a part of the TCB, i.e. /bin/passwd and /bin/login. -serge _______________________________________________ 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: Serge Hallyn Date: Thu, 9 Dec 2010 10:05:49 -0600 Subject: [Ocfs2-devel] [PATCH] fs/vfs/security: pass last path component to LSM on inode creation In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> Message-ID: <20101209160549.GA2315@peq> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: John Stoffel Cc: Eric Paris , 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, tao.ma@oracle.com, shemminger@vyatta.com, jeffm@suse.com, serue@us.ibm.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey Quoting John Stoffel (john at stoffel.org): > >>>>> "Eric" == Eric Paris writes: > > Eric> SELinux would like to implement a new labeling behavior of newly > Eric> created inodes. We currently label new inodes based on the > Eric> parent and the creating process. This new behavior would also > Eric> take into account the name of the new object when deciding the > Eric> new label. This is not the (supposed) full path, just the last > Eric> component of the path. > > Eric> This is very useful because creating /etc/shadow is different > Eric> than creating /etc/passwd but the kernel hooks are unable to > Eric> differentiate these operations. We currently require that > Eric> userspace realize it is doing some difficult operation like that > Eric> and than userspace jumps through SELinux hoops to get things set > Eric> up correctly. This patch does not implement new behavior, that > Eric> is obviously contained in a seperate SELinux patch, but it does > Eric> pass the needed name down to the correct LSM hook. If no such > Eric> name exists it is fine to pass NULL. > > I've looked this patch over, and maybe I'm missing something, but how > does knowing the name of the file really tell you anything, esp when > you only get the filename, not the path? What threat are you > addressing with this change? Like you, I keep thinking back to this patch and going back and forth. But to answer your question: in some cases, the name of the file (plus the context of the directory in which it is created) can tell you what assumptions userspace will make about it. And userspace most definately is a part of the TCB, i.e. /bin/passwd and /bin/login. -serge From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753478Ab0LIQGY (ORCPT ); Thu, 9 Dec 2010 11:06:24 -0500 Received: from adelie.canonical.com ([91.189.90.139]:39475 "EHLO adelie.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750859Ab0LIQGW (ORCPT ); Thu, 9 Dec 2010 11:06:22 -0500 Date: Thu, 9 Dec 2010 10:05:49 -0600 From: Serge Hallyn To: John Stoffel Cc: Eric Paris , 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, tao.ma@oracle.com, shemminger@vyatta.com, jeffm@suse.com, serue@us.ibm.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey@schaufler-ca.com, kees.cook@canonical.com, dhowells@redhat.com Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Message-ID: <20101209160549.GA2315@peq> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting John Stoffel (john@stoffel.org): > >>>>> "Eric" == Eric Paris writes: > > Eric> SELinux would like to implement a new labeling behavior of newly > Eric> created inodes. We currently label new inodes based on the > Eric> parent and the creating process. This new behavior would also > Eric> take into account the name of the new object when deciding the > Eric> new label. This is not the (supposed) full path, just the last > Eric> component of the path. > > Eric> This is very useful because creating /etc/shadow is different > Eric> than creating /etc/passwd but the kernel hooks are unable to > Eric> differentiate these operations. We currently require that > Eric> userspace realize it is doing some difficult operation like that > Eric> and than userspace jumps through SELinux hoops to get things set > Eric> up correctly. This patch does not implement new behavior, that > Eric> is obviously contained in a seperate SELinux patch, but it does > Eric> pass the needed name down to the correct LSM hook. If no such > Eric> name exists it is fine to pass NULL. > > I've looked this patch over, and maybe I'm missing something, but how > does knowing the name of the file really tell you anything, esp when > you only get the filename, not the path? What threat are you > addressing with this change? Like you, I keep thinking back to this patch and going back and forth. But to answer your question: in some cases, the name of the file (plus the context of the directory in which it is created) can tell you what assumptions userspace will make about it. And userspace most definately is a part of the TCB, i.e. /bin/passwd and /bin/login. -serge From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19]) by kanga.kvack.org (Postfix) with SMTP id 9640A6B008C for ; Thu, 9 Dec 2010 11:06:37 -0500 (EST) Date: Thu, 9 Dec 2010 10:05:49 -0600 From: Serge Hallyn Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Message-ID: <20101209160549.GA2315@peq> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home> Sender: owner-linux-mm@kvack.org To: John Stoffel Cc: Eric Paris , 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, tao.ma@oracle.com, shemminger@vyatta.com, jeffm@suse.com, serue@us.ibm.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: Quoting John Stoffel (john@stoffel.org): > >>>>> "Eric" == Eric Paris writes: > > Eric> SELinux would like to implement a new labeling behavior of newly > Eric> created inodes. We currently label new inodes based on the > Eric> parent and the creating process. This new behavior would also > Eric> take into account the name of the new object when deciding the > Eric> new label. This is not the (supposed) full path, just the last > Eric> component of the path. > > Eric> This is very useful because creating /etc/shadow is different > Eric> than creating /etc/passwd but the kernel hooks are unable to > Eric> differentiate these operations. We currently require that > Eric> userspace realize it is doing some difficult operation like that > Eric> and than userspace jumps through SELinux hoops to get things set > Eric> up correctly. This patch does not implement new behavior, that > Eric> is obviously contained in a seperate SELinux patch, but it does > Eric> pass the needed name down to the correct LSM hook. If no such > Eric> name exists it is fine to pass NULL. > > I've looked this patch over, and maybe I'm missing something, but how > does knowing the name of the file really tell you anything, esp when > you only get the filename, not the path? What threat are you > addressing with this change? Like you, I keep thinking back to this patch and going back and forth. But to answer your question: in some cases, the name of the file (plus the context of the directory in which it is created) can tell you what assumptions userspace will make about it. And userspace most definately is a part of the TCB, i.e. /bin/passwd and /bin/login. -serge -- 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