Re: [PATCH v2 0/4] Firmware LSM hook

[Casey Schaufler <casey@schaufler-ca.com>]

On 4/14/2026 12:09 PM, Paul Moore wrote:
> On Tue, Apr 14, 2026 at 1:05 PM Casey Schaufler <casey@schaufler-ca.com> 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.

OK, you're right. However ...

>
> 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.

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.
SELinux transmits the MLS component of the security context. Smack passes
the text of its context. 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.

So there's really no value in pursuing that approach.

> 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.

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.