[DotGNU]DotGNU Security System

[Peter Minten]

Hi folks,

as promised in my 'Fullback webservices' mail here is an explanation about the
DotGNU Security System (DSS) idea. DSS is build on the concept that all I/O
operations of an application have to be pass DotGNU objects. By modifying the
DotGNU I/O objects we can implement a security layer (for sandboxing and stuff
like that).

The setup I had in mind is this:
* DGIO objects enforce restrictions according to the rules in a config file.
* The config file tells for any file or group of files:
  - Whether it is visible to the app.
  - The usual rwx permissions but then for the app.
* The config file tells for any directory or group of directories:
  - Whether it is visible to the app.
  - Whether the app can read the directory contents.
  - Whether the app can create new files in the directory.
* The config file can specify a virtual directory structure for the 
application. 
  This means you can tell it that ~/DotGNU is root, and ~/DotGNU-Work is 
visible 
  as /work.
* The config file will be written in XML.
* There will be a number of standard config file templates (security levels).
* There will be an application to modify the config file.
* The following security levels should be implemented into config templates
  - None (all data is accessible as if the application would run locally)
  - Low (just a little bit of security, programs can not be executed)
  - Medium (no writing to files outside current dir + no reading from 
            files outside homedir)
  - High (no reading/writing/executing of any files)
  - Paranoid (virtual dir structure, root at current dir)
* Security levels are cumulative, all restrictions for lower levels apply.
* All security restrictions can be bypassed either by explicit user permission
at runtime or by rules in the    config file, all bypasses have a limited range.

I believe that the implementation of this system, when done right, will allow
maximum security for users (and sysops, I guess they will like the idea of
control over the I/O of an app :-). It's also much simpler than the ECMA/MS
variant.

Greetings,

Peter