[RFC] Security Enhanced NFS (SENFS) Requirements - draft 05

[J. Bruce Fields]

On Sat, Jun 23, 2007 at 01:45:45PM -0400, James Morris wrote:
> NFSv4 has named attributes, which are modeled on Solaris subfile-style 
> extended attributes.  Technically, I think we could emulate Linux style 
> xattrs over named attributes, but it's ugly:

Agreed.

I don't understand the argument against using xattrs for security
labels, though:

> 4. SELinux labels, and potentially other kernel-managed Linux xattrs, 
> require considerably more state than can be conveyed by any simple notion 
> of attributes over the wire.  xattrs are an appropriate local mechanism 
> for security labeling, because they provide a consistent API and 
> filesystem portability.  However, other local security state is also 
> utilized by the security system, such as the current security label of the 
> process accessing the file (as opposed to the one which opened it) and its 
> fscreate attribute.  Once we start to distribute SELinux labeling, it 
> becomes apparent that we need to a lot more than simply send file labels 
> over the wire.  In addition to managing volatile client security state, we 
> need to cater to many other aspects of the system, including but not 
> limited to: binding SELinux-specific authentication credentials to 
> operations; allowing the client to obtain SELinux labeling and enforcement 
> decisions from the server for cached/delegated objects; ensuring 
> consistency when server policy changes; and conveying audit messages 
> across the wire.

This mostly seems to be an argument that we need something more than an
xattr protocol on its own, which is obviously true.  But I don't
understand why xattrs couldn't be used just for the purpose of getting
and setting file labels.  Maybe an example would help me understand the
problems you're seeing?

> Btw, I will be in Ottawa next week.  Perhaps it might be worth organizing 
> a lunch or similar for people who are there and interested in discussing 
> this.

I'd be interested.--b.