Re: [DotGNU]Re: DotGNU Security System

[Chris Smith]

On Sunday 05 January 2003 17:20, you wrote:
> Peter Minten wrote:
> > 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).

Looks good.

Each 'app' would come with a set of 'resources' (files directories etc).  
I've often wondered how these would be packaged and stored (particularly when 
I've my VRS hat on, but generally in all cases).

This XML example of yours has multiple apps in a single doc, which possibly 
won't be appropriate - trivial quibble granted!

I'm assuming this information would be set up by the system administrator, as 
it contains a lot of system specific info.  How do we deal with the 
self-contained automated server which allows users to upload webservice 
applications?

I suppose each user would have their own sandbox.  They can configure what 
goes where within that sandbox.

This information should be supplied as part of the dgmx file (cos this is 
what it is designed for), or a partner to it at least.


I'm interested how this fits in with the resource manager of the DGEE/SEE/VRS 
(required as such as in the VRS sense, nothing is on disc at all - though I 
reserve the right to announce later that I never said it *would* work, when 
we find that it doesn't! :o) hehe )

Anyway, the DGEE now provides resource limiting (cpu time, memory usage etc) 
and sandboxing.  Yay!
This is for the 'entire' DGEE in that any of the invoked webservices have the 
same sandboxed filesystem.   This is fiddly to arrange as you need to make 
sure all the pnet and pnetlibs stuff is available in the 'natural' place 
within the sandbox.  I'm doing some testing and documentation on this, and 
writing a script to automatically make the hard links on installation, so 
it's currently disabled by default.

Sandboxing is also tricky to engineer because the process setting up the 
sandbox must be running as root.  I had to seriously re-engineer a lot of 
code yesterday to make this safe.

If you were to do this on a per app basis it would mean the VM blob running 
as root.  It would have to PERMINANTLY give up its root priv before running 
the bytecode (or whatever) having set the sandbox.  But now it will never be 
able to get out of the sandbox, so we'd need to dump that process and start 
another one as root to be able to set a new sandbox for the next app/ws.

And suddenly you've got a system which is fork-exec'ing all over the place, 
probably far more than one of the worse cgi webservers out there.  Not good.

You can give registered users there own sandbox by dynamically starting their 
own sandboxed VM's.  These owner-specific VM get cleaned up if they've been 
idle for a while.  This brings with it the overhead of duplication VM 
processes for each of your registerd users bacause they cannot be shared.  
And when you've multiple VMs for Python, pnet, etc etc etc you get lots of 
processes hanging about (luckly idle).

However (big however), there's always a way to achieve a goal, even if the 
steps/ideas to it have to be re-thought.

This is just a cautious wave that's all. Technical and security limitations 
may stand in our way of achieving 'exactly' what we want.  Shame init?
(Said just in case excellent ideas such as this get into the public domain 
and become expected, and then we find we can't quite deliver....  Boo! )


I'd like to discuss this more, with vigour, as it's an area I've been 
juggling with for many months.  And I'm now starting to lay down the 
architecture to support this.


Cheers Peter,

Chris

-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk