On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote: > > We are not limited to LSM solution, the goal is to intercept commands > > which are submitted to the FW and "security" bucket sounded right to us. > > Yes, it does sound "security relevant", but without a well defined > interface/format it is going to be difficult to write a generic LSM to > have any level of granularity beyond a basic "load firmware" > permission.
I think to step back a bit, what this is trying to achieve is very similar to the iptables fwmark/secmark scheme. secmark allows the user to specify programmable rules via iptables which results in each packet being tagged with a SELinux context and then the userspace policy can consume that and make security decision based on that. Google is showing me examples of this to permit only certain processes to use certain network addresses. So this is exactly the same high level idea. The transport of the packet is different (firwmare cmd vs network) but otherwise it is all the same basic problem. We need a user programmable classifier like iptables. Once classified we want this to work with more than SELinux only, we have a particular interest in the eBPF LSM. In any case the userspace should be able to specify the security policy that applies to the kernel classified data. Following the fwmark example, if there was some programmable in-kernel function to convert the cmd into a SELinux label would we be able to enable SELinux following the SECMARK design? Would there be an objection if that in-kernel function was using a system-wide eBPF uploaded with some fwctl uAPI? Finally, would there be an objection to enabling the same function in eBPF by feeding it the entire command and have it classify and make a security decision in a single eBPF program? Is there some other way to enable eBPF? I see eBPF doesn't interwork with SECMARK today so there isn't a ready example? Jason
