[Labeled-nfs] Current status

[Casey Schaufler]

--- James Morris <jmorris at namei.org> wrote:

> Here's the current status of the project:
> 
> There's a need for SELinux to provide full support for NFS, i.e. extend 
> labeling over the wire.
> 
> A few weeks back, I tried to capture all of the requirements for this, 
> based on a review of previous research (e.g. DTOS, NFSv3 SELinux work), as 
> well as combing through various email discussions which have occurred on 
> the subject over the years.
> 
> These requirements were published for initial review, and the latest is 
> located here:
> 
> http://namei.org/lnfs/senfs-requirements-draft-06.txt
> 
> One of the feedback items (from Paul Moore), was the possible desire to 
> approach the work more generally, to provide a general facility for MAC 
> enabled NFSv4.
> 
> Thus, we are now looking at "Labeled NFS" as a generic MAC scheme, and 
> then SELinux-specific support as a flavor of it.  Note that the "SENFS" 
> draft is now a little out of date, and will likely be split out into 
> generic and SELinux-specific components rather than being revised again.
> 
> Since then, there have been a couple of discussions off-list between 
> various interested parties, and I'll attempt to summarize some of those 
> here:
> 
> - There is likely a need to provide some limited-functionality forms of 
> labeling via NFSv4, to take into account scenarios such as:
> 
>  - "dumb" server, which is not itself MAC enabled, entirely trusts
>    clients, and simply stores and retrieves MAC labels with the data
> 
>  - nfsroot (requires great trust in server and may not have local 
>    authentication services running)
> 
>  - Orthogonal security services, not using RPCSEC_GSS e.g. physically 
>    secure networks; labeled networking (CIPSO, labeled IPsec); bump in the 
>    wire security etc.
> 
> - Need to ensure Kerberos data is MAC-protected on a per-domain basis 
> (Linux implementation issue, where krb data is maintained in /tmp, IIRC).
> 
> - Discussion of label transport mechanisms has further confirmed that MAC 
> labels are likely best conveyed as recommended attributes, rather than 
> named attributes or Linux/BSD-style xattrs.  However, perhaps we can allow 
> for flexibility in label transport in any case.
> 
> - Must be able to support mixed environments well, e.g. users running 
> several operating systems, some not MAC-aware, accessing the same 
> file server.
> 
> - Need to ensure manageability (e.g. Linux implementation may integrate 
> with FreeIPA http://www.freeipa.org/page/Main_Page).
> 
> - Lots of discussion around DOI (domains of interpretation).  We will need 
> some way to ensure that systems understand each other, e.g. type of MAC, 
> policy format version, policy model etc.  How do we identify DOI and then 
> provide a means for systems to negotiate relationships ?
> 
> - We need to at least identify DOI handling points, as well as locations 
> where labels are encoded/decoded/translated.
> 
> - Potentially allow for interaction between different types of MAC 
> systems, e.g. SELinux box talking to a Trusted Solaris server.
> 
> 
> ** If you see any issues to discuss which are not mentioned above, please 
> raise them here on the list. **

I would very much like to see a model whereby the server is the
only interface to the file system. NFS provides an exported view
of a local file system, and supporting two sets of semantics
(local and network) leads to no end of complications. I would be
very surprised if providing only a network interface doesn't
reduce the complexity of the problems dramatically. I have done
some prototyping and even using my out-of-date design skills it
seems like a huge win.

> Status of work:
> 
> - Initial prototype code is being developed by Sparta to get SELinux 
> labels transported across the wire.  This has not been posted publicly as 
> yet.
> 
> - I am investigating alternative label transport and authentication 
> mechanisms.
> 
> - We need to re-visit the requirements to split out generic labeling, 
> aiming for the IETF standards track.  If anyone would like to help out in 
> this area, especially if you have IETF standards experience and/or an 
> interest in non-SELinux MAC models, please feel free to step up!

Smack labels are 8byte, null terminated charactor strings,
if that helps at all. I have dealt with the IETF as part of
the TSIG work 200 years ago, but we didn't have a whole lot
of success, so I don't know how valueable that experience would
be. I am interested in doing what I can.


Casey Schaufler
casey at schaufler-ca.com