On 4/15/2026 2:03 PM, Paul Moore wrote: > On Tue, Apr 14, 2026 at 6:42 PM Casey Schaufler <[email protected]> > wrote: >> On 4/14/2026 1:44 PM, Paul Moore wrote: >>> On Tue, Apr 14, 2026 at 4:10 PM Casey Schaufler <[email protected]> >>> wrote: >>>> On 4/14/2026 12:09 PM, Paul Moore wrote: >>>>> On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <[email protected]> >>>>> wrote: > .. > >> CMW MLS and SELinux MLS can be mapped. They have the same components. > Yes, one of the fields in a full SELinux label can be an MLS field, > but that doesn't mean there isn't translation needed. The important > point is that security label translation, mapping, etc. is necessary, > possible, and has been proven to work across a variety of systems.
I'm not especially concerned about translation between systems. The problem at hand is negotiating between LSMs on the same system. > >>>> SELinux transmits the MLS component of the security context. Smack passes >>>> the text of its context. >>> Arguably the NetLabel/CIPSO interoperability challenge between SELinux >>> and Smack is due more to differences in how Smack encodes its security >>> labels into MLS attributes than from any inherent interop limitation. >> Yes. That is correct. The big issue I see is that SELinux does not represent >> the entire context in the CIPSO header. Thus, you're up against many SELinux >> contexts having the same wire representation, where Smack will have a unique >> on wire for each context ... > That isn't always true is it? From my understanding of the "cipso2" > interface an admin could easily map multiple Smack labels to a single > CIPSO label. True, but you can't map multiple Smack labels to the same CIPSO label without introducing ambiguity. > It's important to remember that if you wanted to utilize CIPSO to > communicate between SELinux and Smack, the label translation is not > between SELinux and Smack but rather between SELinux and CIPSO as well > as between Smack and CIPSO. > >>>>> Use of the NetLabel translation cache, e.g. netlbl_cache_add(), would >>>>> require some additional work to convert over to a lsm_prop instead of >>>>> a u32/secid, but if you look at the caching code that should be >>>>> trivial. It might be as simple as adding a lsm_prop to the >>>>> netlbl_lsm_secattr::attr struct since the cache stores a full secattr >>>>> and not just a u32/secid. >>>> Indeed. But with no viable users it seems like a lower priority task. >>> You need to be very careful about those "viable users" claims ... >> Today there are no users. > That you are aware of at the moment. You are also well aware of my > feelings on this issue and ultimately I'm the one who has to sign off > on that stuff. Understood. There are a serious number of considerations that need to be worked through. > >> There are other problems (e.g. mount options) that have yet to be addressed. > The existence of one problem does not mean another does not exist. True enough.
