Jarrett Lu wrote: >> Joy Latten wrote: >> On Mon, 2009-12-07 at 15:02 -0600, Nicolas Williams wrote: >> >>> On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote: >>> >>>>> The proposed work item is, at first glance anyways, too SELinux- >>>>> specific. >>>>> >>>>> Note that SMACK encodes its labels as CIPSO labels, so a scheme that >>>>> uses CIPSO can possibly be used in SMACK and non-SMACK environments, and >>>>> possibly even be mixed. >>>>> >>>> Yes, I agree. >>>> >>>> Actually, we hoped the method we introduced was generic enough to >>>> accommodate both CIPSO and SMACK and any other MAC besides SELinux. >>>> We had hoped to do this by treating the security context as an opaque >>>> blob and introducing a DOI. >>>> >>>> I've actually discussed and collaborated about the "DOI" concept with >>>> Linux's CIPSO developer, and labeled nfs' developer. SMACK developer >>>> was included, but I do not recall if he said anything. We hoped that >>>> this "DOI" would not only be used by labeled IPsec, but CIPSO and others >>>> that use labels on the network. In a way, the "DOI" would help >>>> to identify the "mapping", thus perhaps allowing different MACs to talk >>>> to each other. Interoperability was and is a chief concern. However, >>>> I am sure the drafts most definitely can be improved upon. >>>> >>> See the long threads on related topics on the SAAG and NFSv4 lists with >>> subjects: >>> >>> - Common labeled security (comment on CALIPSO, labeled NFSv4) >>> - Why the IETF should care about labeled?ne tworking (was:CIPSO >>> implementations) >>> - Secdir Review of draft-stjohns-sipso-05 >>> >> >> Thanks for pointing this out. I was not aware of the threads and >> am finding them very interesting and informative. >> > > 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. > 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 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. > 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. > >> >>> I'm not sure what the best way forward is, but here are some thoughts: >>> >>> - A notification indicating what DOI(s) are supported by the sender >>> might help. >>> >>> >> Yes. The drafts suggest that by specifying the DOI as part of the SPD >> entry, that would identify the DOI to support for this traffic stream. >> >> >>> Not that I expect that any system will participate in multiple DOIs, >>> but then, IIRC SMACK supports mappings of SMACK labels (which hijack >>> a level in CIPSO) to non-SMACK CIPSO labels for interop, for example. >>> This idea is probably not too farfetched. >>> >>> - A label type in addition to DOI. >>> >>> >> Ok. I originally perceived this as part of the DOI description, but I >> could understand wanting to separate for perhaps flexibility. >> > > 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 stick by my claim that the right and only rational scheme is for each system to explicitly map the labels it understands from another system to local values, and vis versa. Any label without a mapping must be discarded unused. If you are brave and foolish you can say that the mapping is unity. > >> >>> Not that I expect a single DOI to use multiple label types, but at >>> least one can then parse the label payload according to the stated >>> type rather than having to find the right type for the given DOI. >>> >>> - Text on the encodings of specific label types' labels. >>> >>> Particularly I think you need to have normative references to the >>> relevant RFCs and other work for the 'core' label types. >>> >>> >> Yes, I agree, although I am unaware of any RFCs dealing with that yet. >> > > There are more references for MLS labels (FIPS 188, CALIPSO draft, > etc.) as they have a longer history. BTW, I don't think the label > format specification has to be IETF RFCs. Yeah, that would be bad. > > - Jarrett > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
