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

[Casey Schaufler <[e-mail]>]

Nicolas Williams wrote:
> On Tue, Apr 07, 2009 at 08:02:50PM -0700, Casey Schaufler wrote:
>   
>> Wow.
>>
>> Before I go too far, how familiar are you with MLS, SELinux, or Smack?
>>     
>
> I'm familiar with Solaris TX (which is MLS).  I'm also familiar with the
> OpenSolaris community that is trying to extend the TX model to include
> DTE.  I don't know much at all about SELinux or Smack.
>
> I think common security policies for MLS are within reach.  DTE... not
> so much.  Some subsets of specific DTE policies, probably on a
> per-application basis, should be.
>
>   

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.

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.

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.

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.

>> All three provide general security policy models (Opinions vary on MLS)
>> but none would lend themselves as a "generic" model. MLS is strictly
>> oriented toward sensitivity, SELinux depends on the programs installed
>> on the machine, and Smack uses no syntax in its labels at all. An
>> interoperable encoding of policies might be possible for very limited
>> policies. I suggest that mapping any other policy to the SELinux
>> reference policy is beyond the state of the art, and I welcome an
>> informed argument that proves me wrong. Two peers negotiating a
>>     
>
> 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.

>> policy subset? How does that help? Regarding the notion that the issue
>> of label equivalences is "least critical", I don't see how you can
>> claim to have successfully addressed any of the other bullet items
>> without it.
>>     
>
> Why send data at some label to a peer who doesn't understand what that
> label is?
>
> As for label equivalencies I was referring to the example cited earlier
> of multiple agencies with different MLS policies needing to communicate.
> To clarify: by "less critical" I meant that we could solve the
> equivalency problem later (provided we don't paint ourselves into any
> corners).
>   

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

You are 100% correct. There is no point in sending a label to someone
who can't understand it.

You are also correct that in the case of MLS, where the label contains
sufficient information to make an access control decision, perhaps
after some amount of translation, label equivalence is a problem that
shouldn't require all that much work. Industry experience from the
1990's backs you up.

>> You're busy stocking the nursery and you haven't kissed the girl yet.
>>     
>
> Thanks.
>
>   
>> If the information from the client is meaningless to the server the
>> server can not use it to make an access control decision. Same goes
>> the other way. With Smack I can assert that the label space for the
>>     
>
> Therein lies the interop problem.  Will SELinux and Solaris TX interop
> with the labeled NFSv4 protocol we're working on?  Evidently: not w/o
> policy agreement (that was Jarret's point, which kick-started this
> thread on the NFSv4 WG list).
>   

Again, you are correct. Jarret is correct.

The assumption that policy agreement can be assumed is inappropriate.

>> client and server are the same and that it's OK if they use the labels
>> passed around even if their rule sets differ. I know a good number of
>> people who would find such an assertion dangerous, maybe even
>> criminal. Label representations are meaningless without the policy
>>     
>
> 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.

> So close up shop, forget interop?

Nope.

>   Or did I misunderstand you?  

I can see how you might come to your conclusions, sorry about being obtuse.

> What is
> the message that you're imparting here?  

The systems we created in an effort to appease "C2 in '92" were very
different from the systems we're using now. The interoperability
problem is not the same, and the mechanisms from the MLS era will
not address the interoperability issues, although they could be a
minor part of the end solution.

> I get the impression that it's
> "you can't solve this problem"

Sure you can. My concern is that y'all are looking at the issue as
a rehash of an MLS implementation, and it is much bigger than that.

>  and "I know what I'm doing" (and "you
> don't") but you're not telling us what it is that is.  Is what you
> really mean "forget labeled protocol interop"?  Please clarify.
>   

No. I do have a bit of experience in the field, including close
involvement with CIPSO, three different implementations of labeled NFS
(SunOS/MLS, and two for Trusted Irix) and TSIG throughout its life,
but in no way would I claim to be an expert on the right way to do
protocols. I do understand Mandatory Access Control systems, and I
do see that the discussion to date is missing an element that is key
to the problem at hand.

>> behind them and mapping policies is hard enough that you could probably
>> get a PHD from a reputable institution by measuring just how hard it
>> is.
>>     
>
> I'm not interested in a PhD.  I'm interested in solutions.  SPIF is
> evidence that it's been tried.  But I know little about how successful
> SPIF has been.
>   

I do not deny that SPIF (or CIPSO, or TSIX) has been successful for
the problem it was designed to solve. This is not the same problem.
I hope I've clarified the difference between the problem of MLS systems
and the problem of our current set of technologies.


Thank you.