On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <[email protected]> wrote: > > Netlabel has a similar issue to secmarks with its use of secids, and > currently supports only a single CIPSO tag in the IP header, making > multiple concurrent LSM support impossible.
That's not correct. We've talked about this multiple times Casey. The short version is that while NetLabel doesn't support multiple simultaneous LSMs at the moment (mostly due to an issue with outbound traffic), this is not due to some inherent limitation, it is due to the fact that it wasn't needed when NetLabel was created, and no one has done the (relatively minor) work to add support since then. 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. 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. -- paul-moore.com
