[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Re: DotGNU Security System
From: |
Chris Smith |
Subject: |
Re: [DotGNU]Re: DotGNU Security System |
Date: |
Mon, 6 Jan 2003 16:18:38 +0000 |
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