Re: JANOS+ANTS: nodes crash when old code is replaced with new?

[Robert Watson <rwatson@tislabs.com>]

On Sat, 5 Feb 2000, Patrick Tullmann wrote:

> Robert Watson wrote:
> > Patching JANOS to allocate on demand seems to work great, so I'm making
> > some progress now :-).  BTW, don't know if you've thought at all about
> > masking the ANTS Node calls at all for visiting code, 
> 
> The next version of Janos includes package-level access controls on
> each flow.   In ANTSR we limit dl'd code to its own package and the
> ANTSR core package.  Locally-loaded code is a bit more privileged.
> However, we haven't attempted breaking the Node interfaces up like you 
> did for SANTS.  Though, I think that should be easy enough to fit in.

Our concern in the SANTS implementation was that visiting code should not
have access to most of the ANTS internals, only the APIs, and that extra
privileges should be required to munge the ANTS internals, such as the
code cache.  This both improves the ANTS tolerance for buggy visiting
code, and its security properties :-).

> I think this method (from both SANTS and ANTSR) of controlling access
> via the type system is the way to go.

Yes, this is in our view the best way to set up the security environment.
However, a way of mapping code->permissions for access control is
required: we used the Java 1.2 framework for mapping objects to security
domains/permissions and access controller in our last SANTs release.  What
we'd like to move to doing is allowing visiting code to hold onto
references to their permissions (but limiting their modification of the
permissions using the type system), which both gives us the ability to
work in a JDK 1.1 world, and also to provide visiting code APIs to modify
its privileges to the purposes of delegation.

For example, when the visiting capsule's evaluate() routine is called, we
would pass in a token reference.  When invoking other mutually untrusted
code via the IPC system, but wishing to delegate specific rights, the
visiting code could take advantage of a token API to dup the token, then
restrict the duplicate and pass the restricted version to the other code.
When making an API call that required privilege, capsules would pass in an
appropriate token reference that would allow the EE to check credentials,
and might also contain references to Node credentials to use on behalf of
the ANTS capsule.

> Once we get this next release out, I'll be very interested in what you 
> guys think of it, and if it meets your needs.

Sounds great--we're looking forward to your release.

Robert Watson
Research Scientist
NAI Labs at Network Associates