Designing SEE before anything else (was Re: [DotGNU]SEE and interaction with vm's)

[Barry Fitzgerald]

Gopal V wrote:
> 
> (the security layer may even be implemented in C# , but that would
>  not be portable if DotGNU goes on to have more VM's)
> 
> IMO this is a middle path of the two approaches involved ... we've
> been thinking the wrong way all the time ... ie integrating the runtime
> into the SEE . Time we turned around and attacked from the other side.
> 
> This approach removes complicated IPC/CORBA ... and still protects SEE
> the daemon from a SEGFAULT in the VM ....
> 
> The real issue is why we need a daemon now ? ie just ./ilrun_see will
> provide the permission side of life .. and ./ilrun is the ordinary VM.
> (some more #ifdef's ;-)
> 
> So we have two VMs in one -- the regular ilrun and the ilrun_see
> which are like the Java idea of  "java" and "appletviewer" ...
> 
> Obviously the DAEMON is only needed when we proceed to the DEE stage
> of the DotGNU "experience" ....
> 
> Eventhough this is presented from the myopic angle of Portable.Net ,
> I think that is the only VM DotGNU has CVS commit access to .. ;-)
> 

I think that Gopal is generally correct here, we're getting too
complicated with this.

I think we really need to design SEE.  Let's sit down and look at what
we need the SEE to do and decide whether that functionality is possible
or probable with it.  We want/need the following:

1) cert/hash/auth verification of the ability to run any given
program/code.
2) Once there, we need to be able to load a profile defining that
program's ability to access files and other resources.
3) Once the code is verified and the profile has been loaded, SEE needs
to sandbox the program accordingly and run the code.

1 and 3 are the "easy" parts.   1 can depend directly on the auth
projects by SEE utilizing their general facilities to store the
certs/hashes/login profiles to get the information that it needs.  So,
all SEE needs to do is to contact the auth component locally and use it
like any other program -- grabbing and verifying tokens of data.

3 is relatively easy because, idealy, all you need to do is to provide
the type of VM and location, along with the location of the image that
you want to run.  It's a simple exec function.

The complicator is #2.  But, it really isn't.  Up until now, we've been
looking at solving it through inheriting the profile and things of that
nature.  Well, that's all well and good but it causes complications that
will -- in the long run -- make SEE less secure than it could be (the
more complex the code, the greater chance of there being bugs).  So,
ultimately, the less unnecessary complication we build into SEE the
better.

The solution to 2: the VM and the libraries contain the profile support
and wall off the running code there.  That's the best way to handle it. 
The alternative is to trust the program being run to manage the profile
itself, which would not be good policy at all.  The other alternative is
the kernel, using RBAC, but that would introduce considerable
complication and make the system completely non-portable in nature.

Most of this could actually be menially achieved with a shell script.

If I have wetted your apetites, I have some further ideas on how this
could be implemented.

What do you guys think?

        -Barry