Re: [PATCH 01/11] Security: Add hook to get full maclabel xattr name

[James Morris]

On Thu, 28 Feb 2008, Dave Quigley wrote:

> There are several things here. I've spoken to several people about this
> and the belief I've gotten from most of them is that a recommended
> attribute is how this is to be transported. The NFSv4 spec people will
> probably say that if you want xattr like functionality for NFSv4 use
> named attributes.

NAs are a non-starter here for a couple of reasons.

1. They are specified as being user managed and opaque to NFS.  MAC 
labels are typically set by the OS, and may only be set by the user when 
permitted by MAC policy.  The labels need to be interpreted by the OS to 
allow MAC policy to be enforced.

2. The NA namespace is arbitrary and opaque to the OS.  There's no scope 
in NFSv4 design to allow a namespace to be specified for e.g. MAC labels, 
and trying to modify the spec to allow it seems impractical to me.  It 
would at the very least break backward compatibility with clients and 
servers, and lead to some ugly hacks to try and ensure that systems were 
reliably speaking to peers which understood the namespace.

It might be possible to implement Linux/BSD style xattrs for NFSv4, 
assuming that the IETF folk would approve of the idea, but I don't think 
this is really the right solution for conveying MAC labels across the 
wire.  The xattr API as a local interface is pretty good for this (as it 
is FS independent, simple, and established), but that does not 
automatically translate to an xattr wire protocol being the right thing. 
The problem with this, I believe, is that you end up with quite a lot of 
overhead and complexity being added to NFSv4 which does not actually meet 
the requirements of MAC labeling, and like NAs, seems more suited 
for arbitrary user-managed metdata.

Using RAs for MAC labels seems most appropriate, as they're simple, 
extensible and already used for similar protocol attributes such as ACLs, 
and other system-managed metadata.


- James
-- 
James Morris
<jmorris@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/