notes icon indicating copy to clipboard operation
notes copied to clipboard

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

Open void4 opened this issue 6 years ago • 0 comments

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

void4 avatar Jul 18 '18 04:07 void4