From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A28BB7F3F for ; Tue, 15 Apr 2014 15:08:29 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 43F98AC001 for ; Tue, 15 Apr 2014 13:08:26 -0700 (PDT) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by cuda.sgi.com with ESMTP id AGZAGRx651JV3XYQ for ; Tue, 15 Apr 2014 13:08:24 -0700 (PDT) Message-ID: <534D90D0.9090805@tycho.nsa.gov> Date: Tue, 15 Apr 2014 16:04:32 -0400 From: Stephen Smalley MIME-Version: 1.0 Subject: Re: [PATCH v3 2/4] xfs: initialize inode security on tmpfile creation References: <1397578706-5385-1-git-send-email-bfoster@redhat.com> <1397578706-5385-3-git-send-email-bfoster@redhat.com> <20140415175033.GB26404@infradead.org> In-Reply-To: <20140415175033.GB26404@infradead.org> 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 Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Christoph Hellwig , Brian Foster Cc: linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, xfs@oss.sgi.com On 04/15/2014 01:50 PM, Christoph Hellwig wrote: > On Tue, Apr 15, 2014 at 12:18:24PM -0400, Brian Foster wrote: >> + error = xfs_init_security(inode, dir, &dentry->d_name); >> + if (unlikely(error)) { >> + iput(inode); >> + return -error; >> + } >> + >> d_tmpfile(dentry, inode); >> > > I'd really love to hear from the LSM people who they plan to deal with > O_TMPFILE inodes. But given that this seems to fix a real life bug > let's go with it for now. Is there a reason that xfs_init_security() isn't called from the inode allocation function (e.g. xfs_ialloc), as in ext4 (__ext4_new_inode calls ext4_init_security and also calls ext4_init_acl)? That would have ensured that tmpfile inodes would have been labeled without requiring a separate change and more generally ensures complete coverage for all inodes. For SELinux, we need the tmpfile inodes to be labeled at creation time, not just if linked into the namespace, since they may be shared via local socket IPC or inherited across a label-changing exec and since we revalidate access on transfer or use. Labeling based on the provided directory could be a bit random, although it will work out with current policy if the provided directory corresponds to existing tmpfile locations (e.g. /tmp, /var/tmp) and therefore already has a label associated with temporary files. Otherwise we might want some indication that it is a tmpfile passed into security_inode_init_security() so that we can always select a stable label irrespective of the directory. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs