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.
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. 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.
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. The security
administrators need to make sure your dog_has_no_nose_t is same as my
dog_has_nose_t on two systems.
- Jarrett
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
