[Mono-list] bootstrapping mono with free software?

[Ben Maurer]

On Tue, 2004-03-23 at 14:24, Noa Resare wrote:
> > In short, the verification of mcs is probably the least of your
> > problems. There are much bigger things you would really need to verify,
> > and mcs is easy in comparison.
> 
> I disagree. Yes, mcs is "easy" to verify, but it is also a very powerful
> point of entry for some black hat since the abstraction level is much
> higher than say the CPU or even your average lib/c compiler.
> 
> One can never be totally secure, but an attack that propgagates a trojan
> from my cc/libc by the way of the Portable.NET runtime into mcs is
> several orders of magnitude more difficult to execute than the attack
> that I described in my original post.

Not really. If you can get a backdoor into the C compiler, you can make
any kernel routine do anything. So, rather than just your app accepting
a backdoor password, i have a nice little rootkit.


> Then there is hack value, and that is of course the most important
> reason for trying bootstrapping mono from Portable.NET.
Yep, there is a hack value to this. Just dont trick yourself into
thinking that you are enhancing security when you are doing a hack ;-).

> > > I just tried to this, with mixed success. A trivial patch to mcs/decl.cs
> > > to work around a bug in enum initialization in cscc made mcs.exe
> > > compile. Some more kluges applied to to the mcs sources made mcs.exe
> > > work in the Portable.NET environment for simple test cases, like
> > > compiling a runnable HelloWorld.exe.
> > The correct way to go about this is to fix up cscc. MCS's source is
> > valid, it can be compiled with csc. 
> 
> Of course. But hacknig mcs is so much easier since it's written in a
> better language :) If there is ever an officially supported way of
> bootstrapping mono with Portable.NET all fixes would of course be
> applied on the appropriate places in the respective trees first.
I don't think shifting around mcs source code is the correct way to fix
cscc. Anyways, where is that hack value? Don't you want to make the
software you are touching *less* buggy.

> > Also, you can just compile our corlib with cscc, (that is how it was
> > created in the first place, mcs and corlib were compiled with csc, and
> > scp'd over to linux).
> 
> True, but that would mean that I'd need to buy windows licenses that I
> won't use for anything else.
What i mean to say is:
You do not have to use mcs to compile corlib, you can just use any other
c# compiler. MCS is not able to compile corlib on the MS runtime, I
would not expect any runtime other than Mono to bootstrap corlib with
mcs.

> > 
> > For the reasons stated above, I think this is an effort that will not
> > net you any additional security.
> 
> I fail to see how you draw that conclusion. The total security is equal
> to the security of the "weakest link" in the chain and you can't know
> beforehand which link is weakest. Therefore improving the safeguards
> against a certain class of attacks against the distributed mcs/corlib
> binaries will give additional security. It might not be much though. And
> then there is hack value :)

I am pretty sure that the potential to have a rootkit inside your kernel
is much greater than the risk that mcs is corrupt. And the ability to
detect the former is very low, given that you would pretty much have to
inspect the bytes on your disk with a `clean' computer. MCS on the other
hand, you could just disassemble.

Again, there is a hack value here, but the security benefit is very
marginal, I argue that it does not even exist.

-- Ben