[Labeled-nfs] Current development prototype patches.

[Chris Vance]

On Aug 7, 2007, at 6:23 PM, Matthew N. Dodd wrote:

> Casey Schaufler wrote:
>> --- James Morris <jmorris at namei.org> wrote:
>>> On Fri, 3 Aug 2007, Matthew N. Dodd wrote:
>>>> I would like to ask opinions on a less EA centric mechanism for
>>>> setting labels from userland.  As we're pursuing a labeling
>>>> solution that does not rely on EAs for persistent storage (from
>>>> the client's point of view) it becomes difficult to shoehorn
>>>> things so that userland tools work as expected.
>>
>> Why would you do that? The xattr infrastructure works very well for
>> labeling. Labeling was in fact the only use to which it was put
>> during it's initial Unix development at SGI.
>
> Because we're looking at passing NFSv4 labels via getattr/setattr.
>
> (It occurs to me that this may not have been stated to everyone in a
> clear manner.)

First off, the get/setxattr calls are certainly convenient, already
exist, and do work.  I'm not advocating change.  I did, however, think
it would be useful to provide some additional detail on this train of
thought.

For other systems I've worked on (FreeBSD & Darwin) MAC labels are
closer to being first-class OS objects, not ancillary data.  We've
experienced some problems with treating xattrs and labels as
equivalent.  Likewise, there were issues pushing too much of the
label-specific code down into the file systems, we found it better to
manage labels at the VFS layer and allow file systems to handle
metadata however it best can (or optionally just say that persistent
labels aren't supported).

If labels are first-class citizens, they can have semantics that make
sense, you can get and set them independently of the kernel
architecture.  You can support translation routines between externally
visible strings and internal binary representations.  You can use
similar label-centric APIs for mount points, processes, network
interfaces, sockets, etc. and not rely on per-object semantics (yes,
much of this can certainly be done in a user space library).

It can also be the case that xattrs and in-memory inode labels aren't
the same.  The archives for the selinux list show that some issues
have been raised in the past.  The biggest problem is when you have an
on-disk label that is no longer valid (perhaps a policy change without
relabeling the file system).  Some tools would prefer to relabel the
file based on the old (now invalid) on-disk label rather than the
current inode label (typically unlabled_t).  There doesn't appear to
be a way to retrieve the on-disk label.  Instead, the vfs_getxattr()
call always defers to LSM for 'security.' xattrs and the selinux hook
will always return the in-memory label (I'm going to send a separate
email on this topic, probably to the selinux list).

Backups provide similar issues.  Is it preferable for tar or some
other file-based archive program to backup the xattr that is on disk,
or to backup the label of the in-memory object?  What is the correct
(or expected) behavior when you restore?

Finally, Relabeling files is typically considered a trusted operation
(security-relevant at the very least) and has special security
considerations that are irrelevant to the xattr system calls and
underlying file system implementation.  Is it easier to audit a
setxattr call and try to decode the log later, or to have an explicit
label change operation and audit event?

The vfs_setxattr call uses two LSM hook calls to change the inode
label depending whether xattrs are supported or not.  The SELinux
implementation for both is nearly identical, the label just gets
changed (since a prior setxattr access control check happened).
Curiously, one hook uses a substring of the xattr name, one doesn't.
One hook passes an inode, one a dentry.  One hook can possibly fail
and the other can't.  It was convenient to use existing APIs, but how
clean (and well integrated) is the resulting code?

Chris Vance
SPARTA, Inc.