Re: [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux