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. > 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. 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? > 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 > > 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 ... > 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. -- paul-moore.com
