dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DotGNU]A humble discussion of the SEE design


From: Gerard Toonstra
Subject: [DotGNU]A humble discussion of the SEE design
Date: 30 Jun 2002 01:15:44 +0000

SEE Design
=-=-=-=-=-

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
      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 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
  document.

- 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 user.

- 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 
  a socket.

- 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
  not.

- The SEE inspects the first bytes of the image and identifies the
 correct plugin.

- The SEE caches the image and calls the appropriate plugin, specifying
  the location.

- 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
  'rogue' plugin.

- 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!


Kind regards,

Chiraz




reply via email to

[Prev in Thread] Current Thread [Next in Thread]