[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DotGNU]A humble discussion of the SEE design
[DotGNU]A humble discussion of the SEE design
30 Jun 2002 01:15:44 +0000
This document extends discussions on the SEE architecture.
The official specifications seem to be laid down by Norbert Bollow.
Although not very verbose, a lot of information can be retrieved
from those specifications.
The SEE in the official specification has the following tasks:
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
2. Call the `auth' system which determines whether it's ok to run
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
In this document, I shall try to document and design my view on what the
SEE should be doing, how it should be doing that and for what reasons.
It should not be regarded as official statements for the dotGNU project,
since I cannot be regarded as a leading memeber. It is humbly provided
to you to review and compound the design of the SEE. Some of the above
specifications are not very clear on how this is done. In my design, I
will often refer to policies. Policies are configuration files which
determine the behaviour of the SEE.
Description of SEE:
- The SEE assumes there are no 'rogue' plugins in the system. The SEE
determines what plugin to call based on the MAGIC bytecode. Plugins
are called determined by the same magic bytecodes these advertise.
The SEE executes the bytecode in the first VM it finds appropriate.
- The SEE implements a 'secure assembly'. This is where the VM turns to
when system calls are made. In particular file system access, network
access, environment access and possibly more under the
"/pnet/support" and "/pnet/engine" source tree. The SEE does this by
exposing an API to support fine-grained security policy, as configured
by the SEE.
- The SEE contains a pool of authentication plugins required to control
local access. (the SEE may run on a multi-user machine or allow direct
remote connections via a webbrowser). Some authentications have
particular uses. The plugin will register itself on the type of
authentication it wants to have control of. These plugins have
separate configuration files or may be provided in the SEE
configuration file and exposed by the SEE daemon in a specific way.
- The SEE runs as a daemon with a socket interface where requests come
in for local execution. If remote execution proxied through this SEE
is required, this is where DEE comes in and is out of scope for this
- The SEE implements a socket interface and implements the Jabber
protocol, (depending on whether this should not be done in the VM).
This means that no other VM should concern itself with implementing
Jabber and it becomes a common point of entry and maintenance.
I have removed the scenario's listed as 'a', 'b', 'c', as it does not
particularly matter from where the connection comes. Not assuming where
the connection originates from makes the model more secure.
a. connect from A to B to C
This describes a user on localhost A, who uses a loader object, which
contacts SEE B to startup an application. The application will try to
contact server C.
- The user starts an unrestricted VM and loads the application loader.
The loader should be seen as some kind of 'shell' or 'desktop'?
- The loader contacts the SEE, which would instantiate the object for
- The SEE does security checks and confirms the object may be started
for that session.
- The appropriate plugins for connection authentication are called from
the 'auth' pool and the user is verified.
- The SEE 'retrieves' the image requested and checks the first MAGIC
bytes. It then invokes the appropriate VM plugin to start.
- The image (which can either be downloaded or on disk) is subsequently
loaded in the VM.
- The image tries to contact another server. For this it needs to open
- The VM requests socket permissions through the SEE and throws
"SecurityException" if this is not allowed. (parameters to be
determined. local trust for objects or "running users" or 'signed
objects' is to be stored somewhere.) This socket permission check is a
check to allow for proper running of code. Should the VM open the
socket straight away it might/would fail.
- The image opens a socket and starts to communicate through Jabber.
b. downloading an image.
- The VM _must_ request the SEE to download an image.
- The SEE downloads an image and authenticates it through the auth
chain. The auth chain will determine if the image is to be trusted or
- The SEE inspects the first bytes of the image and identifies the
- The SEE caches the image and calls the appropriate plugin, specifying
- The VM loads in the image and starts the object.
- If the object requires more permissions, the same applies as above.
Gaps in the above design:
- How does Jabber locate the appropriate VM/object to call?
- VM Plugins cannot be jailed entirely on any OS. It may be
recommendable to 'sign' and 'digest' plugins for use by the SEE. This
causes several crypto problems, since it requires a private key on the
system that can (perhaps) be modified, unless stored on disk only
readable by the SEE. For this reason, the SEE should probably start as
a specific user and then continue with permissions of a lower one. It
may offer the user the option to run it anyway if it finds a possible
- Stephen Compall posted an interesting discussion on using a
distributed architecture on several SEE's, each configured with
particular security policies. An advantage of this architecture may be
that it enables system admins to configure global access policies to
the machine, where each individual user may set it's own, restricted
by the global ones. Not sure there though, because home users may just
like only to run one particular SEE and propagating traffic through
various SEE's makes the system rather complex.
- If the image opens a socket to communicate through Jabber, the image
needs to know about the Jabber protocol. That may a desirable option
anyhow, even if it would mean that the SEE knows about Jabber. I am a
newbie at Jabber, but if there are ways to build the actual Jabber
request in the SEE it may be a good option to do so. It may also be
acceptable to run Jabber through a C# imp. of Jabber when it owns the
socket anyway (and the comm. has already been allowed). In this case,
the SEE would only handle new 'incoming' Jabber requests.
- It is _important_ to distinguish between 'incoming' traffic and
'outgoing' traffic for the SEE.
Feedback much appreciated!
|[Prev in Thread]
||[Next in Thread]|
- [DotGNU]A humble discussion of the SEE design,
Gerard Toonstra <=