[Cluster-devel] [RFC 00/11] Inode security label invalidation

[Eric Paris <eparis@redhat.com>]

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...