Norbert's specs (was Re: [DotGNU]SEE architecture)

[S11001001]

Myrddian wrote:
> *he he* I was originally taking care of SEE before I "disappeared", I am
> just recently trying to catch up on what's been going on regarding this
> project, if it's worth my time to try and design it
> or if it's been designed already.
>
>
> I think I wrote a small document regarding what SEE should and should
> not do, it's my personal belief that SEE is not intended to act as
> a server to remote web services, it was more of a Jailing Daemon.
>
> Well if you want to talk to me further about it, or let me know about
> what's been going on with SEE E-mail me or talk to me on IRC

Here are two specs from nb, one in reply to my question about what SEE 
does, and one in reply to some1 else (but more detail). I reformatted 
them in texinfo; what I paste here is the info output.

"Official" Specification
========================

   The SEE daemon should probably be little more than a slightly fancy
`inetd' which is capable of handling three types of requests

  a. user connects to run a program on the server

  b. user connects to download a program to their machine

  c. server connects to run a program on the user's machine

and which does the following:

  1. Examine a "portable executable" and determine what VM is suitable
     for this.

  2. Call the `auth' system which determines whether it's ok to run
     this code.

  3. Depending on some configuration file, determine whether an alarm
     should be raised or not.  Raise the alarm if necessary.

  4. If the auth system said that it's ok to run this code, fork-exec
     the appropriate VM.  Otherwise print an error message and close
     the connection.

in reply to the other inquirer:

"Unofficial" Specification
==========================

   Welcome!!! :-)

   There is one part of DotGNU which needs to run well not only on
GNU/Linux and other free operating systems, but also on the Microsoft
Windows platform (because that is currently holding huge desktop OS
marketshare).

   This is the "Secure Execution Environment" (SEE).  It is supposed to
solve the following problems:

   * A user connects using a web browser to a SEE on a remote
     webservice server, and uses it in a way similar to how "web-based
     applications" work today.

   * A user (who also has SEE installed locally on the PC) who happens
     to be the "owner of the data" for a program that runs on a remote
     webservice server, tells the SEE on his local machine to connect
     to be the "owner of the data" for a program that runs on a remote
     webservice server, tells the SEE on his local machine to connect
     to a SEE on a remote webservice server, and download the data and
     the application program, so that it can then be executed locally.

   * A program which runs in a SEE on the user's local machine should
     be able to present a decent user interface on the monitor.
     (Working through a web browser is just painful.)

   * A user (who has SEE installed locally on the PC) should have the
     option of accessing a webservice application (which runs on a
     remote webservice server) in such a way that if that webservice
     application can transfer to the user's PC code which implements a
     decent user interface.

   Previous discussion have led to the idea of implementing this with a
daemon which can execute VMs or other "plugins" similar to what `inetd'
does.

   For a first proof-of-concept, it's probably best not to worry much
about the authentication/authorization problem.

   What we'd love to have is a simple daemon which can honor local
requests and remote requests to execute bytecode which either comes
from the local disk or from a remote SEE, and which can also do some
data transfers (to implement all of the four scenarios above).

   For the proof-of-concept, a single virtual machine is enough, the
obvious choice is the one in Portable.NET--it comes with a verifier
which can check whether it's safe to attempt to execute this bytecode.

   (Since users don't normally talk with daemons, in addition to that
daemon also a client is needed which will connect to a SEE daemon and
tell it to do something.)

....

hmmm, all this is probably Copyright (C) 2002  Norbert Bollow. Making 
retroactive request for reprinting rights ;)

--
Stephen Compall
DotGNU `Contributor' -- http://www.dotgnu.org

Microsoft is the natural development of a software industry based on
dividing users and taking away their freedom. When criticizing
Microsoft, we must not exonerate the other companies that also make
proprietary software. At the FSF, we don't run any proprietary
software--not from Microsoft or anyone else.
        -- RMS, "Is Microsoft the Great Satan?"