On 4/13/2026 10:36 AM, Casey Schaufler wrote: > On 4/13/2026 9:42 AM, Jason Gunthorpe 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. >> >> 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. > If you want to pursue something like this DO NOT USE A u32 TO REPRESENT > THE SECURITY CONTEXT! Use a struct lsm_context pointer. The limitations > imposed by a "secid" don't show up in SELinux, which introduced them, but > they sure do in Smack, and they really gum up the works for general LSM > stacking.
Whoops. I meant a struct lsm_prop pointer. It must be Monday morning.
