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

[Alaric B. Williams]

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

That's the downside!
 
> 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?

The kind of philosophical backdrop this was up against would
have something like ls not being a seperate object. You'd ask
the directory to print itself. OOP and all that - so you don't
have this delegation of control flow to procedures (which is
how UNIX works!). Besides, and external ls object would have to
be passed cruft about who was running it anyway, so it knew what
to write the results to.

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

Exactly :-(
 
> 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.

How does this work with other people's directories, that they may grant
you a look into, on another machine? You wouldn't trust the remote
object with your capability list!

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

I pass a note to the appropriate hierachy (a user, in general, has more
than one, since he may have his finger in various trust domains; my
personal system, my friend's personal system, my work's network, etc)
that I want to temporarily grant a priv I have to somebody else.

I can ask it for a list of all my privs, unless the hierachy is set up
to require a priv for that, too, of course, and decide which to grant.

At my end, I keep a list of Hierachies and a secret key shared with
each. When I get an "identify yourself!" request back from a remote
object, it specifies the hierachy that object uses, so I know which
one to use.

I'm working on a scheme where different hierachies use different 
techniques; instead of sharing a secret key, you can share a closure,
which is a little more general.
 
> > 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.

The name comes from a concept I was dealing with where the user is
in a tree - perhaps like the organisational tree of a corporation -
and privs can be inherited. That's still in research mode!
 
> 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.

Ok, the basic idea here is symmetric encryption, which is much faster
than public-key; in symmetric encryption, both ends share the same key.
Basically, there is a function which the user and the hierachy share
between them secretly. To prove it's identity, the user asks the hierachy
for a random number, passes it through the function, and returns it.
The hierachy passes the number through it's function, too, and compares
the result with what the user returned. If they're the same, the user
seems to have the same function.

Now, an eavesdropper can see the random number go out and the result
go back, so the function must be so designed as to be hard to
"crack" from these data pairs, even if the eavesdropped witnesses
many different random number encryptions. To help limit this, I think
the hierachy and the user should automagically agree to update their
functions from time to time. If the function they used was adding
a constant to the number (it wouldn't be, in practice), then the
hierachy might think of a random number, add it to the constant
in it's copy of the function, and pass it to the user to add to his
number. Therefore, an eavesdropper needs to know the existing
function anyway to find the new one. 

32 bits of random number passed back and forth should be enough for
most purposes, since there are four billion possibilities, and a well-designed
function would need a lot of those possibilities to be seen by the eavesdropper
before he can guess the function! Also, 32 bit arithmetic is somewhat fast
in most modern machines, so the work done by the user would be something
in the order of ten to twenty machine instructions. More than an eq
test for a capability, I agree, but a little more paranoid :-)

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

Yes, I mean a capability in your sense of the word could be used as
an identity check with the Hierachy for local use. So with your personal
hierachy, you would grant your user agent and other representatives
capability-checked identites, but grant cryptographic identities to
visitors. The ability to escape having to use encryption is something I'm
working on in sharing functions rather than just constants to use in
agreed, known, functions.

> Brian

ABW
--
Alaric B. Williams (alaric@abwillms.demon.co.uk)

   ---<## OpenDOS FAQ ##>---

Plain HTML: http://www.delorie.com/opendos/faq/
            http://www.deltasoft.com/faq.html

Fancy HTML: http://www.deltasoft.com/faq0000.html