On Wednesday, February 14 2007 8:48:32 pm Joshua Brindle wrote: > Joy Latten wrote: > > I always wondered if getpeercon() would someday lift its head and bite, > > I just wish it had not been on Valentine's Day. :-) > > I am concerned about the mls label being returned. > > > > So, my question is, how is this suppose to work? > > Does CIPSO, when given an mls range, like s3-s9, only pass > > the effective level through in ip options? If so, is this > > what labeled ipsec should be doing? Should we be setting only the > > effective level in the SA? If so, that could potentially create > > even more SAs. Or should xinetd, when given a range, should only > > set the effective level for the new process? I kinda like this > > solution best, that is, xinetd setting single effective level. But > > I don't know if that is correct resolution? > > IMO the entire context should be passed, in CIPSO's case that should be > the range, if your clearance is s9 on one machine why wouldn't it be on > another that uses the same levels? I'd hate to see userland interpreting > ranges like this, it will cause assumptions about the mls policy to be > made in userspace. While CIPSO is done entirely in the kernel (i think?) > the decision should still not be made outside the security server which > is the only part of the system that understands what s2-s9 even means > (consider a modified mls policy where the second part of the range is > something other than clearance. > > It is (again, IMO) entirely inappropriate for racoon or xinetd or the > CIPSO code to interpret contexts, this issue keeps coming up and the > answer should always be that the context is interpreted by the security > server exclusively.
The CIPSO protocol does not have any concept of a MLS "range", it only allows for packets to be labeled with a single sensitivity level and category set. Currently the NetLabel code only supports a single MLS level. There are two reasons for this: 1. I tend to think packets are objects and as we have seen through numerous discussions, "ranged" objects don't make much sense. 2. NetLabel doesn't currently support any protocols which provide a "ranged" packet label. The decision to use the lower/effective/zero-element-in-the-range-array when setting the security attributes of a socket using NetLabel is done in the SELinux code, not the general NetLabel code and not userspace. -- paul moore linux security @ hp -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
