Joy Latten wrote:
On Wed, 2008-08-27 at 17:56 -0400, Paul Moore wrote:
On Wednesday 27 August 2008 5:21:17 pm David P. Quigley wrote:
I would like Paul to give his opinion on this as well but I think the
best thing at the moment would be go submit your draft where the DOI
is a tuple of (mechanism,doi). I personally like the idea of
representing the 32 bit value as a series of four octets for human
readable purposes but your idea does have some merit with regards to
what information should be stored with these numbers by IANA. By
having your draft out there recommending your method of handling DOIs
it gives people one more thing to consider for discussion during the
BOF.
Our emails may have crossed in flight, but just in case it isn't clear
from the response I sent earlier this afternoon I think we are best
served with the DOI as a unified 32 bit value (the dotted notation is
just for display/readability purposes).
Ok, just for my clarification, the consensus is that I change this to a
32 bit value field and keep it generic for now as in labeled nfs doc?
I would encourage us to stop thinking about specific DOI values
as "SELinux", "Smack", or whatever. There is no reason we can't get
the different labeled security implementation to work together but if
we continue to propagate the notion of implementation specific DOIs
then it becomes that much harder. I think we need to think of DOIs as
defining a mapping between an on-the-wire label format to a semantic
meaning; the actual format of the wire label isn't important, the
meaning of the label is what really counts. Once we understand what a
wire formatted label means we can internalize it however we need to so
that the implementation can do the necessary access control.
Ok, yep. The label should be an "opaque" (I might be over-using that
word by now) blob to the IPsec protocol. I guess in my thinking, it just
acts as label storage for the packet and the security mechanism.
I guess my concern is this, and it may be because I am not understanding
something. My concern is defining DOI as a mapping between an
on-the-wire label format to a semantic meaning. Could the mapping be
NULL or bypassed sometimes? What I mean is that IPsec could sometimes
store things just as they are represented by the security mechanism
since it doesn't put anything on the wire. So if both endpoints are
using SELinux, it would not need a mapping.
Well ...
It would need a mapping when
the endpoints' security mechanisms are different.
Which it may be if the policies on the two systems don't mesh.
For example, if one system has no apache it needs no apache_t,
hence a mapping is required to deal with that. In fact, two
SELinux systems will obviously require mapping if you're sending
sids in your opaque label and most likely require mapping even
if the label is the context unless the machines have identical
installations and policies.
Thus why labeled ipsec
was bent on a (securitymechanism,doi) tuple. Would it be possible for
the new DOI scheme to also take this into consideration?
For the cases where securitymechanism is sufficient to describe
the structure to which a DOI is applied its specification is
useful. A securitymechanism of SELinux would need to discriminate
between MLS, MCS, and none of the above. This is a problem with
any flexible scheme, Smack has it worse than SELinux because there
is no way to even hint at a structure to the label.
Does even a DOI make sense in a case where the two ends have
irreconcilable policies? Can you get away with anything less
than label mappings maintained on each host?
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
