Shared address space and trust and what is a "user" [Re: Our

[BRIAN SPILSBURY]

> > Delegation is something that needs to be handled.
> > Sometimes I need to delegate powers to another entity.
> 
> I'd arrange that by giving some privs (I've heard capabalities as
> another word for them, now - I'll try to stick to that from now on)
> to the target object. This is a feature of the security Hierachy
> object - if you have a capability registered with it, you can in turn
> grant it to others identities on the hierachy, and revoke it from
> them (but only if it /was/ you that granted it). 

Well, this involves all your authentication going though a third party,
just thinking about this from a pov of speed. 

Also, since its bound to _objects then I think we get into trouble.
If I'm using the 'ls' object to look at my files then I need to grant it
access rights. But unless I have a personal copy of 'ls', then everyone
else gets those rights for that period.

Is this the case if your system, and is there a solution?

With the capabilities system I pass the object the capability it needs to
authenticate itself to my files, which means unless ls is naughty
and steals my capability then its on a per-thread basis. We can safely
share ls between threads.

The problem comes when you have a naughty program that snaffles your
capability and keeps it for later.

Having two capabilities might be a solution, one being a list
of capabilities which are valid. And with the list kept private.

Single shot capabilities are then possible, when they are granted
they are added to the list by the user, the list being shared across
a large number objects (ie all your files), then the single-shot cap is
passed to the ls object, which then passes it to the directory object to get
access to its list. The directory object then removes that capability from
the list and returns the list to the ls object which returns them to
whoever called it.

This removes the race condition, and prevents stealing caps, removes the
need for a third party authentication object, and the worst that can happen
is that the ls doesn't use that cap, but instead gives it away to
someone else to ue later, but without it it can't give us the list
and that's pretty susicious, also we can kill capabilities from that list
after a certain time.

Can you see any holes here?

> > Capabilities seems to address everything you've covered here, and
> > without adding anything extra.
> 
> As usual, I've reinvented the wheel...
> 
> > Note that we don't need to add anything new to do this.
> 
> Except for capabilities :-)

Well, we don't need to even add them :) they're already here. Any object
will do as a capability, although I wouldn't use a symbol or a number :)

> > Ok, this is basically a roundabout way to deal with forgable capabilities
> > with a capability vendor, but we don't need this level of roundaboutness
> > most of the time, capabilities in lisp are unforgable, since they're
> > references to unique objects.
> 
> I'm thinking accross networks here; this system was designed for big,
> bad, untrusted WANs.
>  
> > I may well have missed the point here, if so, please correct me.
> 
> No, I think you understood everything I said; my thing is a bit like the
> capabalities of which you speak, but with some differences. It delegates

Hmm, I don't really see how the delegation works in practice here.

> nicely, and the Hierachy offers a centralised place where trusts can be
> looked at... as I see it, a problem with your kind of capabalities is that
> a communications-level object could sit and read all the capabilities
> going through it and record them? I've turned to cryptography to
> remove this trust of the medium.

Hmm, I instinctively recoil at the idea of 'heirachy' they seem to make things
extra complicated.

Well, for forgable capabilities, you need encryption, perhaps
something like public/private key? I don't know, I'm not too well up
on cryptography.

But for ones being using internally you can ditch the encryption,
perhaps something like a forgable->nonforgable capabilities vendor
at each end would do nicely.

Brian