Unprivileged BPF and authoritative security hooks
Unprivileged BPF and authoritative security hooks
Posted May 4, 2023 6:35 UTC (Thu) by ringerc (subscriber, #3071)In reply to: Unprivileged BPF and authoritative security hooks by farnz
Parent article: Unprivileged BPF and authoritative security hooks
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.
Posted May 4, 2023 10:14 UTC (Thu)
by Karellen (subscriber, #67644)
[Link]
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".
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.
Posted May 4, 2023 15:10 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
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,
Unprivileged BPF and authoritative security hooks
Unprivileged BPF and authoritative security hooks
Unprivileged BPF and authoritative security hooks
Wol
