Nicolas Williams wrote:
It's not clear to me how much information is sufficient to guarantee a subset of policy is consistent so that labeled communication is safe and correct. One extreme is to require systems to be configured identically. As I understand it, roles/types on DTE systems usually depend on what kind of applications are run on the systems, and the types are defined to constrains what the applications can do on a system. In other words, policy on different systems are most likely different.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.
I believe this is a problem for MLS end systems (client and server), even when CALIPSO is in use. If labels are defined differently on different systems, e.g. same binary bit patten on two different systems maps to different labels, label comparison is meaningless. The underlying assumption is that if two systems use different label mapping schemes, they should not be using the same DOI to communicate without some sort of translation mechanism. The agreement of associating a DOI with a particular label mapping is done outside of a protocol option such as CIPSO (for IPv4) or CALIPSO (for IPv6). Just to be clear, CALIPSO spec defines "on-the-wire" format of (MLS) sensitivity label option for IPv6. It is not designed to communicate policy agreements among systems.
Jarrett
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.