Unprivileged BPF and authoritative security hooks

Posted Apr 27, 2023 19:57 UTC (Thu) by geofft (subscriber, #59789)
Parent article: Unprivileged BPF and authoritative security hooks

I'm thinking about the suggestion in the list discussion to grant all users CAP_BPF and use the LSM to restrict it again, and the absurdum that you might as well grant all users root and use the LSM to restrict their abilities, and whether it actually is absurd.

If you look at it from another angle, it seems like the problem is that the standard Linux security controls - caps, file ownership/permissions, user IDs and their namespacing, etc. - basically constitute an LSM with unusual rules: it cannot be turned off and it sits in front of any other LSM. What you really want is for the standard controls to be treated like any other stackable LSM (now that LSMs are stackable), removable, and most importantly configurable. Just like you can tell AppArmor or SELinux to e.g. label or not label packets, you should be able to tell the standard security controls to get out of the way for a particular thing, like BPF. Or like user account checks, for that matter.

There is in fact a little bit of precedent for turning off user account checks in the form of the CONFIG_MULTIUSER option, which when disabled gets rid of UIDs and GIDs and capabilities and all associated system calls and effectively runs everything as root. And now that I go look up the history of it, I see there was objection to it precisely because of the no-authoritative-LSMs rule: https://lwn.net/Articles/631853/

So maybe this really isn't that absurd and we should treat "running without permission checks" as no more technically unreasonable than "running without SELinux." This would basically redefine the problem so that the authoritativeness of an LSM is no longer a concept: if the traditional-permissions LSM is loaded and is configured to enable checks for an operation, then it stacks just like any other LSM, and the remaining LSMs in the stack are "non-authoritative" in current speak. If not, they're effectively "authoritative."

Unprivileged BPF and authoritative security hooks

Posted Apr 28, 2023 7:31 UTC (Fri) by taladar (subscriber, #68407) [Link] (5 responses)

The problem would still exist though. Even if every mechanism to make security decisions is a stackable LSM (or some other, newly designed security plug-in system) you still need to decide what each of those can do.

Can each LSM only block operations, making the operation forbidden if any of them does? Can each LSM on its own allow operations even if other LSMs want to block it? Can each LSM veto decisions of other LSMs that run earlier or later than itself only?

If you aren't careful with permission systems you design something overly complex that leads to more accidental errors while its expressiveness goes unused due to its complexity.

Unprivileged BPF and authoritative security hooks

Posted Apr 28, 2023 11:10 UTC (Fri) by farnz (subscriber, #17727) [Link] (4 responses)

If everything's stackable LSMs, and you assume a competent administrator, you only need the ability to remove permissions at each layer.

Before the LSM stack gets to make decisions, your user is omnipotent, and can do everything. Each layer of the stack can reject the user's request; if nothing in the stack rejects the request, then the user is allowed to do the thing.

It then becomes debuggable - all requests are approved by default, and the kernel can tell you which part of the LSM stack rejected any given request. You can thus design your stack so that all layers deny by default, and use the kernel's advice to open up permissions as and when you need them.

Unprivileged BPF and authoritative security hooks

Posted May 4, 2023 6:35 UTC (Thu) by ringerc (subscriber, #3071) [Link] (3 responses)

This sounds good in theory. What I've found is that you often land up with situations where only layer C has the knowledge necessary to say that some particular case should be an exception to the more general rules applied by higher layers. But doesn't know enough to enforce the restriction elsewhere.

The "campus" layer knows you can only use your key card at the campus you study at. The correct keycard is sufficient to grant access.

The "police and emergency services" layer knows that you can get if you know the right keypad code, but doesn't know anything about key cards and campuses.

The "rich alumini" layer knows that no matter what anyone else says, you WILL let them in anywhere unconditionally because you want their cheque book.

It's hard to compose security with orthogonal layers of checks if each layer can only give a final denial or a no-decison.

With that said, authoratative permit rules are massive foot guns and it's incredibly hard to design a system that's secure and easy to understand when you use them. I'm more interested in having a default-deny model where each layer can say "yep that's ok", "abstain" or "deny". An approve decision requires at least one explicit approval from a module and no denies. Most of the time most modules would abstain or approve, not deny.

I've always found it easier to layer these sorts of models where you default to denying then you layer grants.

Unprivileged BPF and authoritative security hooks

Posted May 4, 2023 10:14 UTC (Thu) by Karellen (subscriber, #67644) [Link]

> I've always found it easier to layer these sorts of models where you default to denying then you layer grants.

I personally think this sounds like a better approach than "default allow with layered rejections", because it sounds like it has a better chance to "fail closed", which seems like a better security paradigm than "fail open".

Unprivileged BPF and authoritative security hooks

Posted May 4, 2023 11:30 UTC (Thu) by farnz (subscriber, #17727) [Link]

I like this - because you have three states ("no decision", "allow", "deny"), the policy can fail closed on no decision.

And it avoids the composability issue that "authoritative allow" brings in - if your policy includes a "deny this access" rule, you can't be surprised by a later "allow this access" rule, since the "allow" rule can't override you.

Unprivileged BPF and authoritative security hooks

Posted May 4, 2023 15:10 UTC (Thu) by Wol (subscriber, #4433) [Link]

This is why I don't like the Windows and Linux implementations of ACLs as I understand it. All sorts of confusing rules.

Pr1me ACLs were simple. Default whatever (defaulted to none). Groups were additive and over-rode default. Named were absolute and over-rode everything else.

So if I didn't want Jo Bloggs to see anything in my project directory, an acl of "Jo Bloggs : none" was definitive.

So provided your security layer could categorise an "allow" or "deny" as being at the group or personal level, a personal deny would be final, a group allow could be over-ridden.

Cheers,
Wol

Unprivileged BPF and authoritative security hooks

Posted May 1, 2023 18:27 UTC (Mon) by bartoc (guest, #124262) [Link]

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.