Re: [nfsv4] [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

[Nicolas Williams <Nicolas.Williams@sun.com>]

On Wed, Apr 01, 2009 at 12:46:33PM -0400, Paul Moore wrote:
> My only comment was that figuring out how to transfer information over the 
> network isn't really that important yet.  Reading through the thread I don't 
> think there is general agreement on what we even need to send to enable proper 
> label translation/encoding/etc.

I think we all agree that a client and server have to agree on the
meaning of any given DOI number so that they can properly encode labels.

In order to interop this means we need a common label encoding for any
given DOI.

I think we agree on that, no?

That leaves this problem: how to ensure that the client and server do
actually agree as to a given DOI's label encodings?

That's a big problem that to date has been solved by out-of-band
mechanisms.  That solution leaves interoperability in a lurch: it's up
to vendors to cooperate to obtain a common security policy for use on
the wire.

I think Jarret's quite right to ask that we do better than that.

Doing better means: a) coming up with a common labeled security policy
language for MLS and DTE, b) ensuring that clients and servers agree on
a DOI's policy.

(a) is hard because we'd have to harmonize the differences between
exiting operating systems' labeled security policies, but I doubt it's
infeasible.  (b) is easy: exchange name+version of a DOI's security
policy and you're done (this can be a URL, a hash of the policy
document, whatever).

> > True. The first question is whether we should try to solve, or at least
> > ease, the label interpretation / translation problem in the context of
> > NFSv4 protocol. I don't know if we can solve it, but it seems worthwhile
> > to explore further, to gain more understanding if nothing else.
> 
> I've been trying to look at this problem in a more generic sense and not just 
> from a labeled NFS point of view.  While the current pain point is labeled NFS 
> the idea of label translation/encoding/etc is not exclusive to NFS or network 
> filesystems in general; I'm sure we can all agree on this.  While we may need 
> to solve (as best we can) the label translation issues on a per-application 
> basis I really hope that we might be able to develop a solution which can be 
> used across multiple applications and not just NFS.

+1

> > The challenge of interpreting and translating labels is that one system
> > needs to know a lot of info about its peer. And there is no good way to
> > describe the (sometimes subtle) difference. I think this problem may be
> > harder on DTE systems than on MLS systems, I believe.
> 
> I'm not sure we will ever be able to arrive at a solution that requires a 
> system to be able to understand the security policy/labels of another; things 
> change to much and I don't think anyone's crystal ball is that good.  
> Personally I think the best we can do is hope for a solution that allows a 
> system to understand a security policy/label system defined by a pre-existing 
> DOI definition.  If we can do that then we can at least allow two different 
> systems to communicate via an agreed upon DOI regardless of their internal 
> security policies/labels.  I'll admit it isn't perfect, but I think the 
> problem space is much smaller and likely to have less churn over time.

+1

> > Assuming we can assemble all the information required to do
> > label translation correctly into a package, passing that around the
> > systems seem inefficient, non-scalable ...

There's no need to refer to labeled security policies by value at the
application protocol layer -- just by name/reference.  The common policy
can be referenced by URL so that it can be downloaded only when it's
changed.

> > ... and probably outside the scope of labeled NFSv4 enhancement.
> 
> Perhaps.  Keep in mind I'm trying to think a bit more generically; if that 
> isn't the goal I'll be happy to go back to my corner and sit quietly :)

Parts of the solution will be outside the scope of the NFSv4 WG.  That
doesn't mean we can't undertake a solution.  Assuming (a) (see above) we
need only specify (b) (see above) for NFSv4 -- we can leave (a) to
another WG.

Nico
-- 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.