From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Paris <eparis@redhat.com>
Subject: Re: [RFC 00/11] Inode security label invalidation
Date: Mon, 24 Aug 2015 15:47:58 -0500
Message-ID: <1440449278.3361.23.camel@redhat.com>
References: <1440094798-1411-1-git-send-email-agruenba@redhat.com>
	 <55DB578A.3080108@tycho.nsa.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: linux-security-module@vger.kernel.org, cluster-devel@redhat.com
To: Stephen Smalley <sds@tycho.nsa.gov>,
	Andreas Gruenbacher <andreas.gruenbacher@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christoph Hellwig <hch@infradead.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	linux-fsdevel@vger.kernel.org,
	David Quigley <dpquigl@davequigley.com>,
	"J. Bruce Fields" <bfields@fieldses.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:49790 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751179AbbHXUsC (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 24 Aug 2015 16:48:02 -0400
In-Reply-To: <55DB578A.3080108@tycho.nsa.gov>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Mon, 2015-08-24 at 13:42 -0400, Stephen Smalley wrote:
> On 08/20/2015 02:19 PM, Andreas Gruenbacher wrote:

> > For that case, the file system has no way of updating the security
> > label before
> > selinux next uses it.  Things also don't fix themselves over time;
> > when selinux
> > rejects access, the file system never notices.
> 
> The current NFSv4 model is to call security_inode_notifysecctx() to
> notify the security module of the new label.  Does that not work for
> gfs2 or others?  It is up to the filesystem client side code to
> actually
> detect the change and fetch the new value, then push it to the
> security
> module via the security_inode_notifysecctx() hook.

I'm told that most of these filesystems have NO push to clients about
changes. Only clients 'pull'.

Image the inode has the label "no_access". I try to access it on node1.
We pull the inode into core and set the isec to no_access and then get
denied. Now on node2 I relabel to "yes_access". There is no push
mechanism for node1 to find out. Now on node1 if I call access() I
"should" have access, but the VFS/LSM will never call the filesystem
code, so fs never knows to call security_inode_notifysecctx().

Somehow we have to get into the FS function so the FS can tell us that
it is invalid...