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: > .. > >>> For those of you who are interested in a more detailed explanation, >>> here ya go ... >>> >>> NetLabel passes security attributes between itself and various LSMs >>> through the netlbl_lsm_secattr struct. The netlbl_lsm_secattr struct >>> is an abstraction not only for the underlying labeling protocols, e.g. >>> CIPSO and CALIPSO, but also for the LSMs. Multiple LSMs call into >>> NetLabel for the same inbound packet using netlbl_skbuff_getattr() and >>> then translate the attributes into their own label representation. >>> >>> Outbound traffic is a bit more complicated as it involves changing the >>> state of either a sock, via netlbl_sock_setattr(), or a packet, via >>> netlbl_skbuff_setattr(), but in both cases we are once again dealing >>> with netlbl_lsm_secattr struct, not a LSM specific label. Since the >>> underlying labeling protocol is configured within the NetLabel >>> subsystem and outside the individual LSMs, there is no worry about >>> different LSMs requesting different protocol configurations (that is a >>> separate system/network management issue). The only concern is that >>> the on-the-wire representation is the same for each LSM that is using >>> NetLabel based labeling. While some additional work would be >>> required, it shouldn't be that hard to add NetLabel/protocol code to >>> ensure the protocol specific labels are the same, and reject/drop the >>> packet if not. >> Indeed, we've discussed this, and I had at one point implemented it. >> The problem is that for any meaningful access control policies you will >> never get the two LSMs to agree on a unified network representation. > That is also not correct. In the early days when SELinux was first > being used to displace the old CMW/MLS UNIXes NetLabel/CIPSO was used > to interoperate between the systems and it did so quite well despite > the SELinux TE/MLS policy being quite different than the CMW MLS > policies. Yes, there were aspects of the SELinux policy that made > this easier - it had a MLS component after all - but they were still > *very* different policies.
CMW MLS and SELinux MLS can be mapped. They have the same components. Comparing a full SELinux context and a Smack label is another beast. >> 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. You'll have many-to-one mapping issues. > In fact, I thought the "cipso2" Smack interface was intended to > resolve this by allowing admins to control how a Smack/CIPSO > translation so that Smack could interop with MLS systems, is that not > the case? Indeed. A CMW MLS policy is way simpler than an SELinux policy. > >> Unless the Smack label is completely in step with >> the MLS component of the SELinux context there is no hope of a common >> network representation. If a *very talented* sysadmin could create such a >> policy, you would have to wonder why, because Smack would be duplicating >> the SELinux MLS policy. > Interoperability wouldn't be a problem if everyone the "right" systems :D Where would the fun in that be? ;) > >>> 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. There are other problems (e.g. mount options) that have yet to be addressed. >> And to be clear, I have no problem with netlabel as written. Multiple tag >> support isn't simple (we did it for Trusted IRIX) and the limited space >> available for IP options make it tricky. > That's an entirely different problem from the LSM and protocol > abstractions, but yeah. >
