On Tue, 13 Oct 2009, Trond Myklebust wrote: [added the ecryptfs folk] > On Tue, 2009-10-13 at 18:02 +1100, James Morris wrote: > > This xattr approach would only cover the "dumb server" scenario, where the > > server simply stores and retrieves security labels on behalf of the > > client. It's intended primarily to enable things like nfsroot, backups, > > serving virtualized file systems etc., and not for fully trusted sharing > > like Labeled NFS. > > > > It is essentially just security label transport. > > > > Support for this feature would be configured at the server, possibly an > > option in /etc/exports which enables specific security namespaces, e.g: > > > > /opt/share 10.0.0.0/8(rw,insecure,xattr="user.*,security.SMACK64") > > > > This says that the XATTR side protocol is enabled and clients can read and > > write user and security.smack xattrs (local DAC would be applied to both). > > > > The server kernel would likely need to know that these are foreign labels, > > and not necessarily 'trust' them for its own use, so a root_squash -like > > option may be used to remap them to an 'untrusted' local label for local > > enforcement purposes -- if it was running SELinux or Smack at all, which > > it may not be. > > Fair enough. That might indeed work. > > One simple alternative might be to just store the exported xattrs in > something other than the 'security' extended attribute namespace so that > your server processes don't have to deal with any conflicts. > > IOW: maybe add a 'nfs.security' xattr namespace, which would contain > those security labels that are actually exported by this XATTR protocol, > and which the clients could then translate into their local 'security' > labels. This sounds like a really good idea, and may provide a general solution for non-user xattrs. i.e. any system, security or trusted xattr is stored in the 'nfs' namespace on the server, and these are always opaque to the server -- semantics are managed at the client. The wire protocol would always carry the client view, for simplicity, and there's no negotiation -- label mapping is always configured at the server by the admin. i.e. the client always sends and receives "security.selinux"; the server by default maps these locally as "nfs.security.selinux"; and may be optionally configured to map to "nfs.$(custom).security.selinux" I wonder how to handle ecryptfs -- it strikes me as a special case where the semantics are always local i.e. files can always be decrypted locally because of the crypto metatdata stored with them. > You might even be able to store per-client security labels as something > like 'nfs.$(hostname).security', or perhaps have a namespace like > 'nfs.fedora11.security' that applies to all clients running fedora? I don't know if there's an established need for this, but some kind of generalized mapping scheme might be useful, and I suspect it's pretty simple to implement as long as the xattr values are always opaque to the server. - James -- James Morris <jmorris@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
