Re: ANN: ANTS v2.0

[Sandy Murphy <sandy@tislabs.com>]

>That's all you could do with what's there now.  We don't claim that
>its complete, just a place to start.

Yep.  Just wanted to make sure I/we understood what security is here.

>It probably wouldn't be too hard to attach an identity to the current
>Capsule.  Ideally the NodeOS would create this association and the
>ANTS code could just expose it.  However, it might be a bit awkward to
>figure out what the "current capsule" is at a given permission check.
>(Probably just a bit more bookkeeping or another parameter on the Node
>APIs.)

We bound the identity to the capsule as it was class loaded so the
protection domain the capsule executed in contained the identity.
Each protected method could then do a Java permission check to see
if the call was allowed.

In the Node architecture ideal, the NodeOS could do the authentication
check and assign the packet to a "resource domain" (whose identities
were established on resource domain creation).  Each NodeOS call from
the EE is supposed to contain the "resource domain" ID, so the NodeOS
can mediate all protected services on the basis of the "resource domain"s
identities.  (Which, by the way, makes EE's pretty darned trusted
parts of this system.)        

>Alternatively, the APIs could be extended so that installed ANTS code
>could drop some privs.  Then the protocol could manually implement the
>priv. drop based on the source of the packet.

So the AA running in ANTS tells ANTS when its privileges need to be
lowered?  Isn't that putting a lot of trust in the AA?

--Sandy