[Labeled-nfs] Labeled NFS Update

[Casey Schaufler]

David P. Quigley wrote:
> Hello Everyone,
>     I know its been a long time since we've had some traffic on the list
> so it is a good idea to inform everyone as to the current state of the
> labeled NFS work. In each section below is the most recent progress and
> then what work there is still to do.
>
> Linux Prototype:
>
> Recently Matt finished updating the prototype to redo the way it passes
> the nfs4_label structures down the call chain. After splitting this
> patch and merging it with the existing patch set the prototype was
> rebased to the latest kernel version. There are currently some problems
> with the upstream tree but they are being worked on and will hopefully
> be taken care of soon.
>
> Things still on the table for the Linux prototype are:
>
> NFSD Client Label Extensions: Extensions to the NFS server to allow for
> a NFS server running SELinux or Smack to be able to specify the process
> label of the client based on some sort of criteria. This can be the
> network interface, the user credentials, the specific IP address, or
> some other criteria. This has benefits to NFSv3 servers as well as NFSv4
> servers. 
>
> RPCSECGSSv3 implementation: While the earlier methods used for process
> label transport in labeled NFS worked they weren't ideal. A proper
> solution to this problem was put forth and it is outlined in the
> RPCSECGSSv3 specification. RPCSECGSSv3 requires either a working v1 or
> v2 implementation. Since we already have these versions available, work
> just needs to be done to provide the additional functionality that v3
> outlines.
>
> Label Translation example: We currently have some patches to provide the
> label translation framework for the NFSv4 client and server to consume.
> We need to figure out how label translation is going to work and then
> provide a library which provides that sample functionality. From there
> people can provide other translation libraries to suit their needs.
>   

I will tell you what will work. I understand that there are issues
with the scheme, most importantly scalability, but having been through
the process back in the TSIG days (label translations between Unix
system vendors) I had reason to work with several mechanisms that did
not work (I am not saying they did not work well, they did not work
at all) and only one that did.

The scheme is based on two notions. First, every system has a native
label representation that it presents to people. For SELinux, this is
the secctx. Second, at some point in the process human judgment must
be invoked on the translation. This is perhaps clearest in the example
of the difference between (US) DoD "Secret" and DoE "Secret", where
the two are conceptually (by law) equal, but operationally distinct.

At some point in any translation scheme the relationship between
two labels needs to be defined. Without that, there is no hope of
translation. If a label is a compound entity there is some hope
of matching up individual components. In the old Unix/MLS world an
enormous amount of effort went into matching up the levels and
categories between various systems, and even creating languages to
do so. Of course, the system that also had Biba integrity still
had trouble dealing with the one that had Information labels.

What did work was the obvious approach of direct full label translation.
Each system gets a table for each source of foreign labels. This
could be at the host granularity, but if all the hosts in a group
used exactly the same labels that group could have a single table.
The table might contain:

    Local-Label  Inbound-Foreign   Outbound-Foreign
    Secret       secret            secret
    Blue         bleu              bleu
    _            system-low        system-low
    TS,A         TS,A,B            TS,A
    TS,A         TS,A              TS,A

For each and every label that comes from or goes to a foreign
destination an explicit mapping has to be provided. There are
rational cases where the inbound translation does not match
the outbound, in the example above there is no category "B"
on the local machine, but a desire to share the information
anyway. Yes, this is a real world case.

This mechanism will work with SELinux systems, Smack systems,
and Unix MLS systems. It does not make things easy for administrators
because they have to take responsibility for the security
implications of the translations. They have to do that anyway, but
making it explicit is never popular.

The interfaces required:

local_label = lt_inbound_to_local(source, in_label)
out_label = lt_local_to_outbound(destination, local_label)

I'm sure that tools to create the mapping tables would be welcome
as well.

I will also point out that there is no other scheme that can possibly
work in the presence of Smack labels, simply because there is no way
to decompose them. The only unit of translation you can use with
Smack is the whole label.


> IETF Documents:
>
> The most recent development in this space is that the NFSv4 working
> group has started work on the NFSv4.2 specification. The good news is
> that Mike Eisler has suggested that the MAC attribute be added to the
> list of features to be incorporated into the specification.
>
> Things in the works for the IETF:
>
> Impact Study: Tasked to us two IETF meetings ago was an Impact study.
> I've received contributions from the co-author and am working on
> integrating them into the document that the Working Group is looking
> for. Additional co-authors on this document are welcome.
>
> Label Format Specification: After wrestling with the interoperability
> problem we came to the conclusion that it makes the most sense to break
> what use to be referred to as a DOI into two parts. This method is
> similar to the original method suggested in the Labeled IPSec document
> but differs in that the first part is a label format specifier and not a
> specific MAC mechanism specifier. This document will explain how to
> specify label formats and semantics of the components of the format for
> use with Labeled NFS. This will allow us to specify an initial list of
> label formats to address some concerns from the working group about how
> implementers will be able to implement portions of the labeled NFS
> specification.
>
> Initial Label Format Document: It's unclear at the moment which label
> formats should be listed as the initial formats. One potential is taking
> the CALIPSO label format wholesale from the CALIPSO specification and
> using that as one of the initial ones.
>
>
> Additional Community Involvement:
>
> Recently I contacted several members of the FreeBSD community inquiring
> about their NFSv4 implementation for a potential second prototype. Both
> the NFSv4 maintainer and the MAC Framework maintainer responded
> favorably to the idea and have offered support when possible. If anyone
> is familiar with FreeBSD development and would like to participate in
> that process you can contact me.
>
>
>
> Hopefully this gives everyone an idea of where we are at and also
> provides some ideas for how people can get involved in the project if
> they are interested.
>
> Dave
>
> _______________________________________________
> Labeled-nfs mailing list
> Labeled-nfs at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/labeled-nfs
>
>
>