Re: [patch 2.1.97] more capabilities support

Andrej Presern (andrejp@luz.fe.uni-lj.si)
Wed, 22 Apr 1998 16:07:13 +0200


I appologize for this mail. It was a draft that I wrote late at night
(see the time) and wanted to continue in the morning so I saved it into
the outbox (yes I know, stupid me) and posted it together with other
mail. Please see the other mail which is more complete.

Andrej

Andrej Presern wrote:
>
> 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

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