You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: