[Mono-list] Implementing "sandbox" security using Mono

[Sebastien Pouliot]

Stuart,

> Can you suggest an order that I should start reading in?

A suggest a book. Articles are often too short to explain CAS in sufficient
details. Reading many articles are difficult to order and often left holes.
A good book should (at least) put all subjects in a coherant order.

> One of the linked articles from Benjamin Wooton's site that you
> mentioned below gave the best overview of CAS I've yet found, though.

:)

> Still, (1) it's not free software, AFAICT, and (2) it seems like a very
> different model of competition. Plus feature-parity with Terrarium may
> be a useful goal to work towards in future versions of NRobot, I guess :)

I didn't include Terrarium as competition ;-)
But there's a lot of interesting stuff to learn from it.
It is very interesting from a security point of view.

>> CAS isn't on the roapmap for Mono 1.0.
>> My hope is to have something working (experimental, not secure) for the
1.2
>> release.
>
> Non-secure security wouldn't help much :(

Let's say "unproven security" ;-) But I see your point.

> So I'm looking at 1.4 at the
> earliest, which is scheduled for mid-2005, for something truly secure,
> right?

*My hope*

If CAS is ready (as in functional) in 1.2 then it will need to be reviewed
and all core class libraries will need to be audited (to be sure the
permissions are in place). So I guess 1.4 is the soonest possible for
sandboxing code a la .NET.

*My hope*

>> Benjamin Wootton is working on some important parts of CAS for his
>> university project.
>> http://www.benjaminwootton.co.uk/project/
>
>Is this work going back into Mono? I couldn't tell from his site whether
>it was or not, or whether his work so far could be downloaded in any
>form other than diffs.

Of course :-)
but (probably) most of it after Mono 1.0 (except maybe class libraries
changes but that won't help you).

>> Another possibility is a (automated) audit where you use reflection to
>> ensure that no "illegal" operations (reflection, p/invokes, ...) are done
>> before actually running the assembly. A simple implementation shouldn't
be
>> hard but would be far more limiting than what CAS can offer (at least if
you
>> want it secure).
>
>> I'd have to check all attempts to call methods in any other assembly,

In that case you could recurse into the other assembly until you found a
"trusted" assembly.

> though, and specifically choose which methods to enable from some
> configuration file. That would be pretty tough and by default I'd have
> to be pretty restrictive (nothing in System.Xml in case it tries to use
> WriteXml, etc).

I don't think that would be really hard - but that's pretty much depends on
what degree of liberty you want to give to the running code.
It's either complex for you - or for the robot designers ;-)

On the positive side this would be a one-time (pre-)check so performance
wouldn't be affected.

> Still, it might be worth it if otherwise I'm faced with
> being insecure until 2005.

I'll let you know if I think of something else...

>> Contributions welcomed ;-)
>
> Unfortunately I think that since I can't yet even figure out how to
> *use* this stuff, I'm a *long* way from being able to *implement* it :(

Heh, lots of way to contributes!

If you start to learn about CAS I'm sure you'll more than able to contribute
to (at least) the unit tests ;-)
and probably more!