Messages in this thread | | | Date | Wed, 22 Apr 1998 15:51:03 +0200 | From | Andrej Presern <> | Subject | Re: [patch 2.1.97] more capabilities support |
| |
Andrew Morgan wrote: > > If you are interested, I would very much like to explain it again to > > you. > > I, for one, would like to read it.
Linus Torvalds wrote: > >It is intresting what you say here. I have tried to explain a concept > >much securer than what is being presented here to some people, but have > >failed in doing so because of being unable to provide the complete > >implementation details due to my lack of Linux internals knowledge. > > > >If you are interested, I would very much like to explain it again to > >you. > > This concept was using segments to give very low-level access rights on > a per-object basis?
No.
Take a look at the following example (I have taken it from a post that I sent earlier to someone, and extended it where I felt I could be more exact):
You have three objects, A, B and C that want to access object D, created and held by object E. In the beginning, neither A, B or C has the ability to access D.
Obviously, E is the one who controls who gets to access D. If A, B or C want to access D, they will need E's permission. E is a friend of A and B and it will give them access to D. However, E doesn't like C and refuses to give it access to D. So E now needs to implement access control to selectively give access to D.
One way to do this is to create a list of objects who are allowed to access D.
Then E puts A and B on the list, while leaving out C. Now if A or B try to access D, they must contact E and E must look them up in the list so that it can verify that A and B are indeed entitled to access. If the object that wants access has been found on the list, E executes function f(D), which performs the requested action on D. The key notion here is 'look them up' and 'verify', which means that resources need to be used for authority checking before performing an action on D. The object can try to access and the authority checking mechanism can either let it through or not.
An alternative way to do this is to use pure capabilities.
Instead of keeping a list and then performing f(D) for objects that are on the list, E could create a 'capability' to D and then give that out to A and B. A capability identifies the object (D) _and_ describes the action (f) that will be performed on D. When A or B want to excercise their authority over D, they invoke the capability to D to trigger the defined action. Becuse the capability cannot be forged (it is of vital importance that the capability cannot be forged), holding it is a sufficient condition for a process to be granted access. Because the capability describes the object _and_ the action that will be performed on the object, no check needs to be done to validate the request (neither the authority nor the action). The key notion here is 'no check needs to be done', which means that no resources need to be used for authority checking before performing an action on D. The object can't even try to perform an action.
Confusing?
Here's the same example as a 'shooting yourself in the foot' example: Let's say that D is the gun, E is the owner of the gun and A, B and C are those who want to use the gun. A and B are friendly and may use the gun, while C is not and may not use it. So E needs to do access control.
Pure capabilities (aka key/lock) control mechanism:
Instead of keeping a list of allowed objects that may fire the gun, E creates a capability to the gun. This capability defines the gun (calliber, location, where to pull to trigger it, how to pull the trigger, etc) and the action that will be performed when the capability is invoked (the gun will fire). To give A and B the ability to shoot the gun, E gives them the capability that it created. Now if A or B want to shoot the gun, they invoke the received capability and E shoots the gun as defined in the capability. Because C wasn't given the capability and it can't produce one itself, C cannot use the gun.
But because A and B officially only want to practice shooting in the target, just handing them a gun seems like giving them too much authority - when they have the ability to point the gun they can shoot anywhere, including each other (and themselves too) if they are malicious or buggy. So E reduces the authority of the capability that it created by specifying that the gun can only be shot in one direction, into the target. Now when A or B invoke the capability, the gun will only shoot into the target. It doesn't matter if they are malicious or buggy, the bullet will still only go into the target. Notice that A and B still receive only one capability, so no more space is required to make control more fine grained. Also notice that because C didn't receive the capability to shoot the gun, it doesn't have to allocate space to accomodate it.
This is like screwing the gun to the video game console - the player can only shoot into the video screen. Because the gun can be fixed to point into one direction, the owner of the gun, E, does not have to check if the gun is being fired into the right direction or not (ie if the authority is being excercised in the agreed manner), because there is only one direction that the gun can be fired at anyway. The users of the gun can't even try to shoot somewhere else, because the gun is attached to the console. Also, because C can't forge the capability, E doesn't have to check if only authorized objects are trying to invoke the capability.
If A and B want to play the game, they must pay E. Because they need a token to start the game, they can't just start the game without E giving them the token (and they can't produce it themselves). When they pay, E will give them the coin that will give them the authority to shoot the gun into the screen. When E wants to terminate A and B's access, it simply takes away the token (or makes it so that it will expire after some time, or makes it so that the game can only be started once with the token, etc - revoking the authority can be quite flexible).
The benefits of using pure capabilities are such that we a) save space, b) improve performance, c) get good security.
We save space because not every object of some type needs to allocate space for the capability, and the code is shorter because no checks need to be done.
We improve performance because we don't have to perform checks to validate the authority and the action, leading to shorter code paths that execute faster.
And this mechanism is fundamentally more secure than ACLs and capability lists because it allows the two basic security principles to be implemented efficiently, the principle of the least authority and the principle of separating the authority from identity. Because the access control can be virtually arbitrarily fine grained, it is possible to give very small amounts of authority to objects. And because the authority is not bound to the object but can be given and taken from the object in the form of a capability, the authority is separated from the identity of the object.
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |