[Mono-devel-list] Limiting Memory Allocation

Sébastien Pouliot spouliot at videotron.ca
Thu May 5 16:22:43 EDT 2005

Hello Jim,

> --- Zoltan Varga <vargaz at gmail.com> wrote:
> >                                         Hi,
> >
> >   Keep in mind that mono currently doesn't support
> > code access
> > security (CAS), so
> > running assemblies containing untrusted CIL code is
> > not a very safe thing to do.
> >
> >                       Zoltan

Executing unsafe code will never be safe, even when CAS is completed. The
security runtime can be compromised by unsafe code - or any native code for
the matter. CAS isn't designed to help you for such scenarios (unless you
decide not to allow executing unsafe/native/reflection/... code).

However the problem is different if you take an "untrusted safe" assembly
and transform it to an "unsafe" (and still untrusted) assembly to add
specific functionalities (like tracking memory allocation...). In this case
you know the only unsafe parts are your own, at least if you ensure* that
the original assembly is really 100% safe. AFAIK the current Mono runtime
doesn't detect all possible unsafe cases (or at least isn't tested as such).

> Is there anything that can be done in the meantime?

Taking this as a "yes|no" question I can assure you the answer is: YES ;-)

Now if you ask "what ?" then things gets more fuzzy...

> Put extra checks in the bytecode translator?

Yes, it's possible to pre-check assemblies to ensure they only use
class/methods from within the script or from a "white list". The "white"
list can be the a part of the actual framework and/or an object model you
provide. However this approach limit extensibility, existing code reuse...

> Remove dangerous bits of the framework so they can't be
> called?

I'm unsure for your project but, in general, I don't believe this is a good
approach. First the balance (functionality/security) is hard to keep and
even when something gets completed you risk having a very crippled result
(functionality-wise), a still insecure subset or (most probably) both.

My (probably not very partial ;-) opinion is that both options requires a
lot of efforts and time (not just to get there but to continue supporting it
later). The same efforts could be invested in defining your security model
requirements (well you would need that anyway) and helping to complete CAS
to match them. But at this stage it's hard to guess when the payoff would

Sebastien Pouliot
home: spouliot at videotron.ca
blog: http://pages.infinit.net/ctech/poupou.html

More information about the Mono-devel-list mailing list