Re: [DotGNU]Re: DotGNU Security System

[Peter Minten]

Chris Smith wrote:
> 
> 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!

IMHO for a user it's appropriate, it allows for example to disallow file
operations to any webservice of some companies. Couple the system to security
certificates and stuff like that and you have instant restrictions without the
user having to take action for every new webservice.

But we could add an option to simplify the code:

Instead of 

  <applications>
    <app>
      <name>Hello*</name> <!-- All apps who's name start with Hello -->
    </app>
    <app>
      <name>*</name> <!-- Any app -->
      <vendor>Foobar</vendor> <!-- From Foobar -->
    </app>
    <app>
      <name>*</name> <!-- Any app -->
      <trustlevel>untrusted</trustlevel> <!-- That we don't trust -->
    </app>
  </applications>

This is also possible when there is no applications block:

  <app>
     <name>Hello</name>
     <vendor>Foobar</vendor>
     <version test=">=">0.4.1</version>
  </app>

This allows to specify only one app (unless you use regexps in the block) but
multiple versions of the app, allows to set rules according to the version of
the app (for example when 0.3.0 has a security bug but 0.4.0 not you could set
rules to compensate for that).

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

VIRUS ALERT, VIRUS ALERT, VIRUS ALERT :-)

Never trust programs uploaded by the user to an automated server. The best idea
there is to automatically enforce Super-Paranoid-Sysop level. If you'd do
anything less you'd have a huge security risk because a virus could propagate
itself by uploading itself to automated servers. Personally I don't like
automated servers for that job, you need trained humans to check out the
programs first with a virus scanner on who can then transfer the programs to a
general accessible area.

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

That's the idea of the virtual directory structure. But for a server sandbox you
must be able to control the memory and certain types of code (assembler can be
very dangerous). I know Rhys is working on that kind of stuff but you must be
able to enforce it for every type of webservice lang.
 
> 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.

Just for the record: what does the dgmx file? (I've been rather caught up in
Butler work so I didn't have the opportunity to look at the example yet)

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

Cool. Now let's see how we can fit this into the xml:

<restrictions>
  <cpu max="10"> <!-- In percents -->
  <memory max="1000"> <!-- In Kb -->
</restrictions>

Would it be a good idea to allow restrictions on stuff like symlink making by
apps?
 
> 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 tell me, I have the butler forking and creating named pipes, after one
debugging session my /tmp/DotGNU/501 dir where the pipes are located has at
about 30 files (15 program runs) and there are child processes all over the
place (I should really send some SIGKILL's and delete some pipes when the butler
ends :-).

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

IMVHO that's not a good idea. Isn't it possible to run the code for different
users in different threads and implement thread security. That would save
processes. 

Couldn't we just implement the restrictions code inside the VM's, change the I/O
classes for enforcement. Would probably mean somebody has to restart dgbase
since it might break ECMA compat (this kind of thing is exactly why I started
dgbase a whole while ago, CLI is far from perfect and some improvements have to
be implemented in the baselib).

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

The first thing to remember here is that my DSS works client side while the DGEE
Security System works server side. The Client DSS has a much easier task than
the Server DSS. I believe however that the Client DSS is essentially a subset of
the Server DSS. The Client DSS knows only file restrictions and vdirs (virtual
directories), the Server DSS should now about additional restrictions to
disallow dangerous operations.

DotGNU would probably be best server with a clearly defined security system. If
we had a spec we could mark some areas as Server DSS only and some as applicable
to the Client DSS too.

Anyway I believe the XML docs are the way to go. But the system clearly needs to
be enhanced. For example it would be nice if the sysop could set global
restrictions and the user could override some of these for it's own dirs and add
some restrictions of course.

Greetings,

Peter

PS: Jargon file entry for DotGNU: "Secure, powerful, simple, oppose .NET ." ;-)