Jarrett Lu wrote: > Casey Schaufler wrote: >> Jarrett Lu wrote: >> >>> Without rehashing the statements made in above discussion threads, >>> it's probably helpful to have a realistic interoperability expectation >>> for labeled systems. Defining label formats and security mechanisms in >>> various networking protocols is important. >>> >> >> This reflects the traditional viewpoint and is a major obstacle to >> progress in the modern world. The modern reality is that two SELinux >> systems installed with the same software from the same distribution >> at the same time with configuration parameters that you might think >> would be insignificant may well have policies with differences that >> can not be reconciled in a network protocol. >> >> But it's worse than that. Static label formats (e.g. Bell & LaPadula) >> are often cited as the downfall of the 1990's MLS systems. In the >> rest of the OS the notion has been discarded. None of the current LSMs >> use a structured label format, unless you want to argue that the >> SELinux label format is structured, in which case you're likely to >> hear that it is structured for flexibility. Networking is the final >> hold-out for the archaic notion that labels should be inherently >> meaningful. >> >> >>> Consistent label interpretation and label policy enforcement are also >>> key to labeled communication. >>> >> >> This has never ever been true, not even once. You need look no >> further than the level "Secret", which means something very different >> in the US Department of Defense and in the Department of Energy. >> The only case where a serious attempt was made was IPSO, which >> had a classified mapping of DoD categories in the label. >> > > Although your statements sound a lot different, I think we are > actually in agreement for the most part, i.e. having a labeled > networking protocol alone is insufficient for MAC system > interoperability. For example, it's pointless if two systems can't > agree on what "Secret" means.
The subtle distinction begin that they don't need to agree what Secret means, but they must each know what to do with a Secret presented to them by the other. > >> >>> Note the latter is mostly handled outside the protocols in this >>> discussion. So in reality, only systems that implement same Mandatory >>> Access Control (MAC) security models are likely to be able to >>> inter-operate. A possible example is OpenSolaris FMAC and SELinux. >>> >> >> This is also a common misconception. In truth, two SELinux systems are >> no more likely to interact properly than a Trusted Solaris system and >> one running UNICOS/MLS. >> > > The bottom line is that the MAC systems should enforce the same policy > in order for " interoperability" to make sense. Nope. I disagree. Two wildly divergent policies can interoperate. I have seen it done. It is not pleasant to gaze upon, and there is lots of human overhead to set it up, but it does happen because in the real world it must. > How to ensure policy consistency across communicating systems is > beyond Labeled IPsec, and is probably a burden on the system/network > administrators. This comes back to my earlier point of having a > realistic expectation of MAC system interoperability. Yes, with this I can agree. > >> >>> The term "DOI" has been used in traditional MLS system for about two >>> decades. In the MLS world, when systems use same DOI, it means they >>> agree to the same label definition and MAC policy, and the systems are >>> most likely under same administrative control (Note which policy is >>> agreed upon is handled outside of a networking protocol). The label >>> format is determined, i.e. it's CIPSO. >> >> Actually, the TSIG definition only requires that the two be able >> to work out their differences. They are not required to speak the >> same dialect. >> > > True. They need not be identical but must be consistent. > >> >>> In the current "Labeled IPsec" proposal, DOI is a Security Label >>> Format Selector. I really think you ought to use a different name, >>> calling it what it is and not be confused with MLS DOI. And use ISAMKP >>> DOI when appropriate to avoid confusion. >>> >> >> Sure. >> >> >>> David Quigley and I had some offline conversation about this, as he >>> has the same need for labeled NFSv4 work. The current thinking is to >>> have a separate draft describing the need to set up an IANA registry >>> and its content. Each entry consists at least the following fields: >>> LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO, >>> SELinux security contex strings, etc. >>> SUB FIELD: Used to aid label handling, e.g. SELinux could use it for >>> policy version numbers; CIPSO could use it for tag type; >>> LABEL FORMAT: pointers to reference docs on how labels should be >>> parsed. >>> >>> Both Labeled IPsec and labeled NFSv4 (and any future label protocol >>> extensions) can refer to this document. >>> >> >> Two systems, no matter how similar, will never be able to translate >> formatted labels reliably. It only takes trivial changes to an SELinux >> system for my_dog_has_no_nose_t to mean completely different things >> on the two machines. >> > > I don't think this is the problem we are trying to solve here. I > believe we are trying to solve the problem of getting packet labels > across the network with confidentiality and integrity protection. But once people start down that path they always start trying to dictate what the on-wire labels are going to contain. And that is what needs to get nipped in the bud. > The security administrators need to make sure your dog_has_no_nose_t > is same as my dog_has_nose_t on two systems. Can't be done reliably. > > > > - Jarrett > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
