lkml.org 
[lkml]   [1998]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.087 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site