[Mono-dev] The State Of Mono Assembly Verification?

[Sebastien Pouliot]

Hello Jim,

On Thu, 2006-02-02 at 21:41 +0000, Jim Purbrick wrote:
> Hi Everyone,
> 
> It's good to see a healthy debate about these issues
> :-)
> 
> > I second this. It would be very very useful for us
> > if mono wouldn't g_assert
> > but throw exceptions when the dll is
> > invalid/broken/obfuscated/maliciously
> > modified.
> 
> Does that mean that you might be able to contribute
> some time to this too, Joachim?
> 
> > I believe it would be useful to many people - even
> > if most don't realize it today. Until then Mono is
> > "restricted" to run trusted code which,
> > IMHO, "limits" it usefulness (I admit the "limit" is
> > probably rather low as there are very few 
> > applications supporting partial trust today).
> 
> Certainly being able to run untrusted code was a big
> reason for us to embed Mono as a scripting engine. We
> want a system that will run untrusted code and to have
> the performance to do some heavy lifting beyond the
> lightweight scripting that is currently possible in
> Second Life using the current LSL interpreter.

That's great and I do admire what (and how) you're doing this :-). This
is a terrific (and unexpected) use of Mono and many of it's features.

But I hope you (and everyone) realize that there is NO mention,
anywhere, of running untrusted code safely before Mono 2.0 (and again
this is only a roadmap, not a blood-signed binding contract with the
devil ;-).

> > Anyway the truth (please feel all free to prove me
> > wrong ;-) is that security, especially runtime
> > security, hasn't been very popular with
> > contributors - in any form (e.g. code, samples,
> > reviews, test cases...).
> 
> It's probably a catch 22. While you can't run
> untrusted code on Mono, people who want to run
> untrusted code won't use Mono and so won't contribute
> to it.

Sorry Jim but I don't buy that argument (not even part of it ;-). 

First a project like Mono could never start (at least from scratch) if
this was true (and that would also mean we live in a real sad world, or
maybe we are... but for different reasons ;-).

Second there is (and has been) a lot of contributions in non-working
parts of Mono. Some of them are now working (e.g. COM support), some
aren't (let's call them work in progress) and some may never work (e.g.
WSE). People contribute for many reasons - many because something
doesn't work or doesn't even exist (and deserve to be). Also many people
contributes their free time so they are free to choose on what work (and
I have absolutely *no* problem problem with that, in fact I don't even
have a problem begging for more contributions ;-). I wish that security
was more popular and btw I'm seeking contributors for creating a
"security is cool" marketing campaign ;-)

Third, if Mono could execute (safely) untrusted apps then no one would
need to contribute it (yes, it's a joke, I see, but do not share, your
point ;-)

> While the implementation of security features is
> incomplete it would be useful to make clear which
> untrusted uses are possible and to aim to slowly
> increase the gamut of untrusted uses.

There is a lot of information on the wiki (including the CAS section and
the roadmap) but for the sake of the discussion let me be clear:


*** Today (and every day until *at least* Mono 2.0) there is NO safe way
of executing untrusted applications on Mono. ***

			... Period ...


Yes, you can trick, hack, add, remove, pre-process ... managed code but
it doesn't change the fact that once it gets to mono, it MUST be
trusted. So...


*** Today (and every day until *at least* Mono 2.0) there is NO safe way
of executing untrusted applications on Mono. ***


Hopefully it will score better and Beagle (local) / Google (net) will
pick it up ;-)

> It would seem that complete bytecode verification
> might be a good starting point. 

Yes it could - but for most people (including my employer) there's no
benefit until the whole (checks + CAS + class lib + audit) is completed.
The order was thus unimportant (hmm... except for the audit part). I
started with CAS because I could demonstrate (more visually, e.g.
NRobot) the advantages of running unmanaged code and, I admit, encourage
contributions based on "something existing" (it didn't happen, btw
that's another blow to catch-22 ;-).

Maybe I selected a bad starting point - but at least I wasn't alone (yes
it's a very small consolation ;-). I emailed the mailing list asking on
what people wanted so I could adjust my priorities. Guess how many
answers I got ?

Hint: if you multiply the answer by 0 it will still give you the same
number.

> Once a complete verifier exists presumably untrusted code that makes
> no framework calls can be used. 

I understand this is your goal (or that it satisfy some minimal
requirements you have in the short term) and I'm glad there is a
solution to your problem (beside waiting for the features). However that
scenario may not appeal to many people (i.e. not fx call technically
includes no calls corlib).

> In our case, where the
> only method calls that can be made are iCalls that we
> already trust, this minimal usage of untrusted code
> would be very useful.

yes the "white list" but again *very* useful to *very* few...

> >From that point implementing CAS or other security
> features in such a way that Mono X.Y can allow
> untrusted code to be loaded as long as conditions N
> and M are met would gradually increase the utility of
> Mono for untrusted applications.

There isn't many "useful" stepping stones (again for most people). Why ?
One reason is that because people will compare it to what other (i.e.
MS) ECMA VM offers.

But again I would be happy if someone (or many) have suggestion(s) to
offer for the next development cycle (1.2 -> 2.0). I can't promise
anything but there's no big risk for suggesting ;-)

> The question "Under what conditions can Mono be used
> to run untrusted code?" is the one that I've been
> trying to answer by talking to Sebastien, Miguel and
> this list and I think its a useful question to have an
> answer to. 

I can go thru my emails but I'm sure the first answer I gave you was
clear and probably something like "it's not ready (yet)".

Maybe I should have stopped there? I think any unclear answers comes
from further questions about "what can I do to make it so - or partially
so".

In that I'm afraid I failed. First I've been answering many emails (not
just from you Jim ;-) about similar questions without ever receiving a
single line of code back (damn, this will look bad on my next
performance review :-( unless I receive some contributions until
then ? ;-)

OTOH I'm glad if the most useful stuff (for some) is still to be done.
Why ? because it means there's still room for much contributions ;-)

> Having a number of partially implemented security
> features seems to be of little use, while having some
> completed features and an understanding of the
> conditions under which they can be used seems to be
> useful.

I agree but I think you draw the wrong conclusion. There isn't a number
of partial security features - there is one: CAS and I think it is at a
really nice stage now (it's definitively not what you need but that
wasn't the original target).

There was never, to my knowledge, someone tasked to implement the
verifier. What we have today is the hard work on the JIT people that
implemented the (or some of) security checks required for what they were
doing. This is exactly what every contributors should be doing when
implementing the class libraries, the mono tools ... I think they all
deserve credit for it - even if what they did was partial (or wrong ;-).


To conclude, if some parts if this email didn't sound funny then :
(a) blame my English skills (please);
(b) blame my lame sense of humor; or else
(c) blame me

Cheers


P.S. oh, just in case someone scrolled to the end and missed it...


*** Today (and every day until *at least* Mono 2.0) there is NO safe way
of executing untrusted applications on Mono. ***


-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/