Re: [saag] [Labeled-nfs] Common labeled security (comment on CALIPSO, labeled NFSv4)

[Nicolas Williams <[e-mail]>]

On Wed, Apr 08, 2009 at 09:11:00AM -0700, Casey Schaufler wrote:
> The 1990's MLS solutions used labels that described sensitivity
> levels and category sets. There was variation on exactly how
> these were represented, some used fixed size bit maps, others
> arrays of category numbers, but the information they contain is
> a complete description of the information required to make an
> access control decision. Unfortunately to the task at hand, MLS
> is a technology that has seen its last development efforts.

But has MLS seen its last days for deployment?  I think that for generic
non-governmental agency deployment you're quite right that MLS is barely
sufficient.  DTE is needed.

Incidentally, I should clarify that in the context of labeled NFS I only
care to solve the sub-problem of how the client and server can determine
what policy or subset thereof they share.  I currently think that's a
simpler problem than how to represent policies (and equivalencies), but
only if we also assume a solution that.

> The SELinux label, whose textual representation is called a "context",
> contains enough information for the system on which it was generated
> to interpret it relative to the system policy. It does not contain
> sufficient information for a system that does understand that policy
> to make decisions based on that context. For a context generated on
> Stephen's machine to be meaningful on David's David's machine would
> need a full understanding of both policies. Last I looked the
> SELinux reference policy was approaching a million lines. Based on
> the many interrelationships between policy elements, I do not
> think that subsetting is going to be viable, although I'm willing
> to be educated on that.

I'm still learning about DTE.  If I understand correctly though we could
constrain ourselves to administrator defined policies built on system-
and vendor-defined types/roles.  If so then DTE policy subset agreement
seems within reach.

> In some ways Smack is even worse. The Smack label contains no
> actual information, it is just a character string and the access
> control is left completely up to the access control rules specified
> on the system. A Smack label from Etienne's system has no intrinsic
> value on Casey's and give no hint as to how it should be interpreted
> or enforced.

Ouch.

> Summary: Old MLS systems passed sufficient information in their
> labels for any number of mechanisms including SPIF, CIPSO, TSIX,
> and IPSEC to be useful. 21st century MAC systems, including
> SELinux and Smack, have labels that do not contain sufficient
> information for another system to make an access control decision.

Jarret's point was that this is true even for MLS labels because a node
might not know what the meaning of a given sensitivity and compartment
are.  This is not a problem for CALIPSO because middle boxes need only
determine label dominance, but Jarret thinks that this is a problem for
NFS.

> > IIUC it should be possible to generate SELinux policies from generic
> > ones, but not the reverse.  If so then that provides a path to
> > interoperable deployment, though it would mean sacrificing some
> > flexibility.  Can you clarify my understanding?
> 
> An SELinux policy can be created from scratch, and we're seeing some
> people in the embedded space trying to do just that. Sure, you can
> limit the problem by constraining the variation of the policies, but
> as we type the reference policy continues to be refined and expanded.
> I'm not going to tell Joshua that he has to slow policy development
> in support of NFS.

I see.  This is important knowledge.  I'm not sure what can be done
about that.

> Let's see if I can be clear for a change. (smiley here)

:)

> The assumption that policy agreement can be assumed is inappropriate.

I think you're very likely right about that w.r.t. DTE.  But I still
harbor some hope.

> > So you're saying that a) "a good number of people" think a solution is
> > needed that allows the client and server to each know with certainty
> > that the other will understand their labels, b) you're among those
> > people (?), but c) no solution is feasible.  Correct?
> >   
> 
> a) Else there's no point to labeled NFS.
> b) Yup.
> c) It is not feasible to meet "a" using just the information contained
>    in either an SELinux context or a Smack label, regardless of how
>    the information is transmitted between the client and server. You
>    can meet "a" for 20th century MLS systems using just the information
>    contained in the MLS label.

Crystal clear.  Thanks.

> I hope I've clarified the difference between the problem of MLS systems
> and the problem of our current set of technologies.

You have.  Thanks!

I'll need to think about the DTE issues, and SELinux vs. Solaris FMAC.

Nico
--