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

[Stephen Smalley]

On 08/20/2015 02:19 PM, Andreas Gruenbacher wrote:
> Hello,
> 
> this patch queue adds an LSM hook for file systems to invalidate inode security
> labels.  To allow selinux to revalidate invalid labels, the generic xattr
> handlers are cleaned up a bit and a new igetxattr inode operation is
> introduced: the getxattr inode operation requires a dentry which selinux
> doesn't have in inode_has_perm(); igetxattr instead takes an inode.  Finally,
> gfs2 is patched to make use of this new mechanism.
> 
> The new igetxattr inode operation currently is *only* used for revalidating
> security labels in selinux; it may make sense to use it instead of getxattr
> when defined.
> 
> Is this approach useful?  An alternative would be to modify selinux so that it
> always has a dentry when checking inode security labels; I would guess that
> this won't work in all cases, though.
> 
> 
> BACKGROUND
> 
> Selinux currently assumes that, after initialization, inode->i_security always
> represents the current security label of the inode.  This assumption works for
> local file systems; any change of the label must go through setxattr (or
> removexattr) which updates inode->i_security.
> 
> On an nfs mount, other nodes can change the security label; there is no
> immediate notification mechanism.  Other nodes will eventually notice a label
> change because the label is transmitted as part of the reply of operations like
> open. (A timeout for cached labels would help too; I'm not sure if the code
> implements that.)
> 
> Other file systems have different consistency models. For example, gfs2 inodes
> go "invalid" when a node drops the inode's glocks. When such an invalid inode
> is accessed again, all the metadata must be read from disk again, including the
> security label.
> 
> 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.

> 
> To fix that, this patch queue adds a mechanism for file systems to invalidate
> inode security labels, and for selinux to revalidate them; this is similar to
> how the inode acl cache works.