Re: [RFC][PATCH] Generic fallback for security xattrs

From: Stephen Smalley (sds@private)
Date: Mon Jul 18 2005 - 09:06:22 PDT


On Mon, 2005-07-18 at 08:53 -0700, Casey Schaufler wrote:
> That's correct. You still need to add to the
> file system code to support the system call
> interface. But really, the only hard problem
> is what to do in the case of a file system with
> an inflexible on disk format, and I've provided
> what I can (due to corporate IP policies) on
> addressing that issue.

Patching every pseudo filesystem to add an xattr security handler, only
to have that security xattr handler call into the security module to get
and set the incore inode security label, as we've already done for
devpts and tmpfs, will yield a lot of code duplication that can be
avoided via a generic fallback in the VFS.  In that case, there is no
storage of xattrs at all, so there is nothing to do besides calling the
security module.

For legacy filesystems (e.g. think vfat), implementing native xattr
support is a pointless exercise, even aside from compatibility issues.
You just want to map them to a single security label, which we can do,
but you also want to export that to userspace via the standard
interface, which means you need to either implement a handler in each
such filesystem that again just calls into the security module, or you
provide a fallback in the VFS.


> Do you store that label anywhere? If you're
> referencing from the inode, no matter how
> indirectly, you ought to be able to expose it
> as an xattr. Now, if you have two you may have
> a naming issue to address, but I'm sure you
> can deal with that easily enough.

The label is mapped to a SID and stored in the incore inode's security
structure.  So the security module can easily get/set it, but the
filesystem code cannot do so directly - it has to go through an LSM hook
(as we've done in devpts and tmpfs).  Moving that up into the VFS avoids
duplicating that handler code in each such pseudo filesystem (and legacy
filesystem).

-- 
Stephen Smalley
National Security Agency



This archive was generated by hypermail 2.1.3 : Mon Jul 18 2005 - 09:08:24 PDT