Casey Schaufler wrote:
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.
OK. The point I try to get across is that enforcing coherent label
policies is another critical piece in MAC interoperability, and that
piece is outside the scope of a labeled networking protocol.
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.
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.
Right. Sometimes the bits matter :-) . I think we are still discussing
how many ways a labeled opaque blob can be parsed. For example, if
on-wire representation of a label is always CIPSO/CALIPSO, it's simpler
as there is already a defined IP option number and no Label Format
Selector is needed. This means label transformation overhead for non-MLS
systems.
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.
Maybe true. But that's clearly out of scope of a labeled networking
protocol. At end of the day, people who deploys this technology need to
bear the responsibility for obtaining the right level of assurance that
the systems are going to behave correctly.
- Jarrett
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
