[Mono-list] Implementing "sandbox" security using Mono
Tue, 20 Apr 2004 12:06:21 -0400
Sebastien Pouliot wrote:
> I normally suggest the ".NET Framework Security" book from LaMacchia et al.
> but MSDN also has many articles on the subject.
Can you suggest an order that I should start reading in? I can normally
pick stuff up through web reading fairly quickly, but I have trouble
when I'm faced with a large domain without any idea where to start. I
keep finding snippets of information but no good overview of how all the
pieces fit together or what parts are required understanding before
learning others. For example, I've no idea how CAS and AppDomains
interact, if they do at all, and what role AppDomains play in security,
I feel like I'm trying to understand a picture by looking at it through
a microscope - I can understand some little bits of the picture, but I
still have little idea how it works overall.
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.
> You probably already know about it, but if not, you may be interested to
> look at gotdotnet's Terrarium.
Well that's depressing. I hate when I find that someone else has done
something much more advanced than something I'm working on...
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 :)
> Sadly not enough.
> CAS isn't on the roapmap for Mono 1.0.
> My hope is to have something working (experimental, not secure) for the 1.2
Non-secure security wouldn't help much :( So I'm looking at 1.4 at the
earliest, which is scheduled for mid-2005, for something truly secure,
> Benjamin Wootton is working on some important parts of CAS for his
> university 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.
> 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,
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). Still, it might be worth it if otherwise I'm faced with
being insecure until 2005.
> 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 :(
Stuart Ballard, Senior Web Developer
(215) 283-2300, ext. 126