From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 27 Feb 2018 00:57:21 +0000 From: Al Viro Subject: Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata Message-ID: <20180227005721.GK30522@ZenIV.linux.org.uk> References: <20180227004121.3633-1-mic@digikod.net> <20180227004121.3633-2-mic@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180227004121.3633-2-mic@digikod.net> Sender: Al Viro To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnaldo Carvalho de Melo , Casey Schaufler , Daniel Borkmann , David Drysdale , "David S . Miller" , "Eric W . Biederman" , James Morris , Jann Horn , Jonathan Corbet , Michael Kerrisk , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Shuah Khan , Tejun Heo , Thomas Graf , Tycho Andersen , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, James Morris , John Johansen , Stephen Smalley , Tetsuo Handa , linux-fsdevel@vger.kernel.org List-ID: On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: > The function current_nameidata_security(struct inode *) can be used to > retrieve a blob's pointer address tied to the inode being walk through. > This enable to follow a path lookup and know where an inode access come > from. This is needed for the Landlock LSM to be able to restrict access > to file path. > > The LSM hook nameidata_free_security(struct inode *) is called before > freeing the associated nameidata. NAK. Not without well-defined semantics and "some Linux S&M uses that for something, don't ask what" does not count. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata Date: Tue, 27 Feb 2018 00:57:21 +0000 Message-ID: <20180227005721.GK30522@ZenIV.linux.org.uk> References: <20180227004121.3633-1-mic@digikod.net> <20180227004121.3633-2-mic@digikod.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <20180227004121.3633-2-mic@digikod.net> Sender: linux-kernel-owner@vger.kernel.org To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnaldo Carvalho de Melo , Casey Schaufler , Daniel Borkmann , David Drysdale , "David S . Miller" , "Eric W . Biederman" , James Morris , Jann Horn , Jonathan Corbet , Michael Kerrisk , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Shuah Khan , Tejun Heo , Thomas Graf , Tycho Andersen List-Id: linux-api@vger.kernel.org On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: > The function current_nameidata_security(struct inode *) can be used to > retrieve a blob's pointer address tied to the inode being walk through. > This enable to follow a path lookup and know where an inode access come > from. This is needed for the Landlock LSM to be able to restrict access > to file path. > > The LSM hook nameidata_free_security(struct inode *) is called before > freeing the associated nameidata. NAK. Not without well-defined semantics and "some Linux S&M uses that for something, don't ask what" does not count. From mboxrd@z Thu Jan 1 00:00:00 1970 From: viro@ZenIV.linux.org.uk (Al Viro) Date: Tue, 27 Feb 2018 00:57:21 +0000 Subject: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata In-Reply-To: <20180227004121.3633-2-mic@digikod.net> References: <20180227004121.3633-1-mic@digikod.net> <20180227004121.3633-2-mic@digikod.net> Message-ID: <20180227005721.GK30522@ZenIV.linux.org.uk> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, Feb 27, 2018 at 01:41:11AM +0100, Micka?l Sala?n wrote: > The function current_nameidata_security(struct inode *) can be used to > retrieve a blob's pointer address tied to the inode being walk through. > This enable to follow a path lookup and know where an inode access come > from. This is needed for the Landlock LSM to be able to restrict access > to file path. > > The LSM hook nameidata_free_security(struct inode *) is called before > freeing the associated nameidata. NAK. Not without well-defined semantics and "some Linux S&M uses that for something, don't ask what" does not count. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:34942 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751764AbeB0A5c (ORCPT ); Mon, 26 Feb 2018 19:57:32 -0500 Date: Tue, 27 Feb 2018 00:57:21 +0000 From: Al Viro To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnaldo Carvalho de Melo , Casey Schaufler , Daniel Borkmann , David Drysdale , "David S . Miller" , "Eric W . Biederman" , James Morris , Jann Horn , Jonathan Corbet , Michael Kerrisk , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Shuah Khan , Tejun Heo , Thomas Graf , Tycho Andersen , Will Drewry , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, James Morris , John Johansen , Stephen Smalley , Tetsuo Handa , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata Message-ID: <20180227005721.GK30522@ZenIV.linux.org.uk> References: <20180227004121.3633-1-mic@digikod.net> <20180227004121.3633-2-mic@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180227004121.3633-2-mic@digikod.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Feb 27, 2018 at 01:41:11AM +0100, Micka�l Sala�n wrote: > The function current_nameidata_security(struct inode *) can be used to > retrieve a blob's pointer address tied to the inode being walk through. > This enable to follow a path lookup and know where an inode access come > from. This is needed for the Landlock LSM to be able to restrict access > to file path. > > The LSM hook nameidata_free_security(struct inode *) is called before > freeing the associated nameidata. NAK. Not without well-defined semantics and "some Linux S&M uses that for something, don't ask what" does not count. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH bpf-next v8 01/11] fs,security: Add a security blob to nameidata Date: Tue, 27 Feb 2018 00:57:21 +0000 Message-ID: <20180227005721.GK30522@ZenIV.linux.org.uk> References: <20180227004121.3633-1-mic@digikod.net> <20180227004121.3633-2-mic@digikod.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: linux-kernel@vger.kernel.org, Alexei Starovoitov , Andy Lutomirski , Arnaldo Carvalho de Melo , Casey Schaufler , Daniel Borkmann , David Drysdale , "David S . Miller" , "Eric W . Biederman" , James Morris , Jann Horn , Jonathan Corbet , Michael Kerrisk , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Shuah Khan , Tejun Heo , Thomas Graf , Tycho Andersen , To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Return-path: Content-Disposition: inline In-Reply-To: <20180227004121.3633-2-mic@digikod.net> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, Feb 27, 2018 at 01:41:11AM +0100, Mickaël Salaün wrote: > The function current_nameidata_security(struct inode *) can be used to > retrieve a blob's pointer address tied to the inode being walk through. > This enable to follow a path lookup and know where an inode access come > from. This is needed for the Landlock LSM to be able to restrict access > to file path. > > The LSM hook nameidata_free_security(struct inode *) is called before > freeing the associated nameidata. NAK. Not without well-defined semantics and "some Linux S&M uses that for something, don't ask what" does not count.