Unprivileged BPF and authoritative security hooks

Posted Apr 28, 2023 7:31 UTC (Fri) by taladar (subscriber, #68407)
In reply to: Unprivileged BPF and authoritative security hooks by geofft
Parent article: Unprivileged BPF and authoritative security hooks

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