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
Linus Torvalds wrote:
>
> In article <353C7192.44E6F6C1@luz.fe.uni-lj.si>,
> Andrej Presern <andrejp@luz.fe.uni-lj.si> 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. You must have mixed it up. Pure capabilities are not about
organization and implementation, they are the concept of holding and
passing authority.

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 want
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.

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.

Confusing?

Here's the capability explanation 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.



- spremeni in dodaj zgoraj -
if you want A and B to be able to shoot into the target, you create a
capability to the gun that holds the authority to fire the gun into the
target. Because a capability completely defines the object (the gun) and
the action (firing into the target) A and B cannot abuse the gun to
shoot at each other. Because the gun can only be fired in the target,
neither A nor B can shoot itself in the foot. And if some C should come
along that would take take over A or B, it couldn't do anything else
with the gun either, because the capability that A and B have to the gun
only includes shooting into the target.

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    [from the cache]
©2003-2011 Jasper Spaans