On Mon, Apr 13, 2026 at 12:42 PM Jason Gunthorpe <[email protected]> wrote: > 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.
Points for thinking outside the box a bit, but from what I've seen thus far, it differs from secmark in a few important areas. The secmark concept relies on the admin to configure the network stack to apply secmark labels to network traffic as it flows through the system, the LSM then applies security policy to these packets based on their label. The firmware LSM hooks, at least as I currently understand them, rely on the LSM hook callback to parse the firmware op/request and apply a security policy to the request. We've already talked about the first issue, parsing the request, and my suggestion was to make the LSM hook call from within the firmware (the firmware must have some way to call into the kernel/driver code, no?) so that only the firmware would need to parse the request. If we wanted to adopt a secmark-esque approach, one could develop a second parsing mechanism that would be responsible for assigning a LSM label to the request, and then pass the firmware request to the LSM, but I do worry a bit about the added complexity associated with keeping the parser sync'd with the driver/fw. However, even if we solve the parsing problem, I worry we have another, closely related issue, of having to categorize all of the past, present, and future firmware requests into a set of LSM specific actions. The past and present requests are just a matter of code, that isn't too worrying, but what do we do about unknown future requests? Beyond simply encoding the request into a operation token/enum/int, what additional information beyond the action type would a LSM need to know to apply a security policy? Would it be reasonable to blindly allow or reject unknown requests? If so, what would break? > ... Once classified we want this to work with more than SELinux > only, we have a particular interest in the eBPF LSM. One of the design requirements for the LSM framework is that it provides an abstraction layer between the kernel and the underlying security mechanisms implemented by the various LSMs. Some operations will always fall outside the scope of individual LSMs due to their nature, but as a general rule we try to ensure that LSM hooks are useful across multiple LSMs. > 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? As Casey already mentioned, any sort of classifier would need to be able to support multiple LSMs. The only example that comes to mind at the moment is the NetLabel mechanism which translates between on-the-wire CIPSO and CALIPSO labels and multiple LSMs (Smack and SELinux currently). > Would there be an objection if that in-kernel function was using a > system-wide eBPF uploaded with some fwctl uAPI? We'd obviously need to see patches, but there is precedent in separating labeling from enforcement. We've discussed SecMark and NetLabel in the networking space, but technically, the VFS/filesystem xattr implementations could also be considered as a labeling mechanism outside of the LSM. > 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? Keeping in mind that from an LSM perspective we need to support multiple implementations, both in terms of language mechanics (eBPF, Rust, C) and security philosophies (Smack, SELinux, AppArmor, etc.), so it would be very unlikely that we would want a specific shortcut or mechanism that would only work for one language or philosophy. > Is there some other way to enable eBPF? If one develops a workable LSM hook then I see no reason why one couldn't write a BPF LSM to use that hook; that's what we do today. > I see eBPF doesn't interwork with SECMARK today so there isn't a ready > example? I'm not aware of anyone ever doing to work to try/enable secmark with BPF, but I see no reason why someone couldn't work on that. Just make sure to take into account Casey's comments about multiple LSM support; any new LSM interfaces will need to support multiple simultaneous LSMs (the original secmark work predated that). However, it seems like direct reuse of secmark isn't what is needed, or even wanted, you were just using that as an example of separating labeling from enforcement, yes? -- paul-moore.com
