Unprivileged BPF and authoritative security hooks

One problem with this is that it means you are trusting the LSM to actually get the security model right, and when designing a new subsystem you then have a wider field of possible security models that you need to analyze to figure out if what you're doing is secure or could break any of them.

It might make sense to do this but have the LSM implementing the initial restrictions developed as part of the kernel and always applied in front of any other LSM, just like the classical DAC model is used today. However, because LSMs are code this doesn't really help you that much. There also may well be some hooks that you want this "base" LSM to have access to but shouldn't be available to other LSMs, and at that point you've almost gotten back to where you started.

Ultimately you need a security model to _actually_ analyze. Today most LSMs act more as security firebreaks that have a high probability of mucking up at least one link in some exploit chain than they do as airtight security where any mechanism of bypassing them is considered a bug.