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

[Andreas Grünbacher]

Stephen,

2015-08-24 19:42 GMT+02:00 Stephen Smalley <sds at tycho.nsa.gov>:
>> 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?

Unfortunately not. In fact, NFS also cannot work fully correctly with
this infrastructure alone because it cannot invalidate cached security
labels once they expire.

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

That is unfortunately not how non-local file systems work. Clients
don't normally get notified of changes performed by other nodes.
Instead, they do one of the following:

 * On NFS, inode attributes are cached opportunistically for a
   duration determined by the client. When they are needed
   and it turns out that the cached values have expired, they
   are re-fetched from the server. (See cache_validity and
   revalidate_inode in fs/nfs/; RFC 7530, Section 1.5: Client
   Caching and Delegation and Section 10: Client-Side
   Caching.)

   This is not true for security labels though; security labels currently
   won't be expired.

 * GFS2 and some other file systems grab locks on inodes before
   caching data or metadata. When the locks on an inode are
   released, the cached data and metadata become invalid
   and must no longer be used.

File system clients can't actively poll their servers about metadata
changes; that would be way too costly. We really need a way to
invalidate security labels, and selinux needs to reload invalid
security labels when they are needed.

Thanks,
Andreas