[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Virtual Machine in the abstract (was Re: [DotGNU]What languages shou
Re: Virtual Machine in the abstract (was Re: [DotGNU]What languages shouldDotGNU support?)
Fri, 6 Dec 2002 09:32:24 +1100
On 05-Dec-2002, Peter Minten <address@hidden> wrote:
> Fergus Henderson wrote:
> > The drawback of this approach (compared to using just the one intermediate
> > language, CIL) is that it is less secure, because it relies on a larger
> > trusted code base. Instead of needing to trust just one interpreter,
> > you need to trust all the different languages interpreters. Bugs in
> > the Ruby interpreter, for example, could result in security holes.
The problem is that the trusted code base needs to be larger.
Larger code bases have more bugs. It's that simple.
> The webservice programmer can decide what language he/she wants to use.
> If the programmer doesn't believe a language is secure enough he/she can pick
> another language. And the user who downloads a webservice can chose to
> execute or not.
In general, individual users can't be trusted to make good decisions
about what to execute or not. System administrators need to provide
policy settings about which VMs can be trusted.
Suppose a user wants to use three DotGNU web services, all written by
different programmers. DotGNU may support five different VMs, all of
which are about equally secure. So, given that they are equally secure,
the programmer will choose on other criteria (e.g. suitability of the
language for the task). There's a good chance that different developers
will end up choosing different VMs. So our user, in order to execute
these three web services, needs to trust the security of these three VMs.
A different user from the same organization, who wants to use some
different web services, may need to trust the security of the other two VMS.
The security of the organization is now dependent on the security of all
five DotGNU-supported VMs.
In order to penetrate the organization's security, all a cracker needs
to do is to find a bug in any one of the five supported VMs, write a
web service that exploits this bug, and then trick on of the
organization's users into accessing this web service. The more
supported VMs there are, the easier the cracker's job is.
Fergus Henderson <address@hidden> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.