Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More intuitive summary of why Access Control Lists (ACLs) don't work and why capabilities may be better #19

Open
void4 opened this issue Jul 18, 2018 · 0 comments

Comments

@void4
Copy link
Owner

void4 commented Jul 18, 2018

I held a 5-minute presentation at RC recently: https://gitlab.com/void4/presentations/raw/master/pres.odp


Source: ACLs don't

Intro

This summary applies to multi-user systems. In Linux operating systems for example, there is often only one user. This of course violates the principle of least-privilege (since all processes have access to everything). Even unprivileged programs can capture all keyboard inputs for example. Processes inherit all rights from the user that runs them.

Security Systems

In both following systems, permissions are unforgeable. This is guaranteed by some actor-external mechanism.

Access Control Lists

In ACLs, permissions are attached to identities. If an actor receives permissions to write to two files, it cannot separate them because of this.

The actor might accidentally switch them up and overwrite the wrong file, or be maliciously moved to do so. This is called the confused deputy problem. It's like a security guard with a key ring. The keys cannot be separated. In an opportune moment, an attacker could confuse him to open doors for him he shouldn't have access to.

Key (Capability) based systems

Opinion: The word "capability" is utter abstract nonsense. So I'm using "key" instead.

Permissions are a form of object that can be reached around.

They may be duplicated and passed along with other messages.

Them being an object makes it easy for programs to keep permissions separate when receiving input from different users.

If a process receives two file write permissions, it can refer to these permissions separately.

In some systems, keys may be revoked ("exchanging the lock"). Arbitrary mechanisms can be used for revocation, this may even be time based.

Access Matrices

Every row is an actor (also called "principal")

Every column is an object that is acted upon. An actor may be one of these objects.

Each cell denotes the actions the actor can apply to the object

Yeah no I'm too sleepy for doing this now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant