Re: inode security state and cluster file systems

[Eric Paris <eparis@redhat.com>]

On Tue, 2011-02-22 at 09:25 -0600, Yuri L Volobuev wrote:
> > >>> If we made the invalidation point an explicit refresh of the
> label at
> > >>> least the filesystems would be able to control both of those
> > >>> problems.....
> > >
> > > So far the only case that has been discussed is one in which there
> > > is one security attribute on the file. While we don't have it yet
> there
> > > are a couple of efforts underway to support multiple concurrent
> LSMs.
> > > It is also plausible for an LSM to use more than one security
> attribute
> > > on a given file. An approach based on a secid interface may not
> work
> > > in either scenario. If you want a comparative example, look at
> directory
> > > default ACLs, which are important security information, but are
> nor used
> > > to make access decisions on the object to which they are attached.
> > 
> > I'm still leaning towards a solution in which the filesystem needs
> to
> > tell the LSM that it's labels are invalid (I suggest that be done on
> > any change in the security.* namespace) and that same call needs to
> > cause the LSM to refresh its labels.  I seem to think that such a
> call
> > would work just fine with any LSM stacker or even
> > multi-attribute/multi-label LSM (which uses the security.*
> namespace).
> 
> In the "pull" model that GFS2, OCFS2, and GPFS apparently follow, on a
> given node the file system code doesn't know that an xattr in a
> security.* namespace got modified on another node.  All that is known
> is that the lock protecting inode xattrs has been lost, so now
> everything protected by this lock is invalid.  The next time this
> information is needed, it has to be re-initialized (e.g. by reading
> data from disk).  The security attribute label may or may not have
> changed, that is not known at that point, but the inode security state
> has to be re-initialized in case it did.  So it sounds like all
> distributed file systems would benefit from an LSM API call that
> invalidates inode security state.
> 
> I think the tricky part here is how/when to drive inode security state
> refresh, once it has been invalidated.  File system code could do this
> easily at dentry revalidation time, possibly even using existing API,
> like security_d_instantiate (provided it does a full re-init, using
> getxattr, if it sees that the inode state has been invalidated).  A
> dentry is conveniently available at this juncture.  
> Permission checking prior to a write on an already open file is a
> somewhat different problem.  In the current code, the permission check
> is made before file system code gets involved, so the call to re-init
> inode security state has to be made in VFS or LSM code, before the
> permission check.  It would probably be easier/more logical to do this
> in security_file_permission.  Since the latter is passed struct file
> *file, a dentry could be easily obtained as file->f_path.dentry.

The two problems I see with doing the refresh 'when needed' is that FS
code is almost certainly not designed to have a ->getxattr call during a
read/write and not all permissions checks have a dentry.  Namely any
calls to fs/namei.c::inode_permission() are going to end up in the LSM
without a dentry and with an 'invalid' security struct.  I feel like the
invalidate and refresh need to be done at the same time....

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.