The main two questions are:

1) can you disable compiler ? (that means no doIt)
2) can you disable loading of compiled code and class by other means ?

If you cannot remove compiler, then you must restrict its use.


Le Lundi 31 Juillet 2006 22:18, Ron Teitelbaum a écrit :
> Bert,
>
> Thank you for your comments, I wasn't planning on using the sandbox since
> there are a number of external connections like Glorp-PostgreSQL needed
> where I plan to ultimately use this new functionality.  I was hoping to
> address this with a signed image and VM.  A signed image and VM could keep
> any changes out of the system.
>
> The thing that concerns me is changes to a live system that happen without
> needing to save the image.  Plenty can happen as the system is running so
> the question is: how can we secure the image while it is running?
>
> Some things that would be needed off the top of my head are:
>
> 1) Disable file in
> 2) Disable the compiler for accepting or performing new code, but allow it
> for already coded performs.  (I'm sure this is much easier said then done).

A restricted compiler must not have access to Smalltalk environment but only a 
restricted one.
It must also have access to a restricted number of messages, expecially not 
the system reflexive ones like allOwners allInstances basicAt: subclasses 
become: etc...
It is safer in this case to authorize a few than forbid a lot of messages.

I did this kind of tricks in the days when ParcPlace runtime policy were 
really conservative. Maybe you will find more informations in commercial 
Smalltalk versions...

> 3) Disable interactive debugger.
> 4) Enable some sort of class level MAC checking which can verify that no
> changes were made to code before it is executed.

It is much simpler to close the system by reducing it's interface, than trying 
to secure the kernel.

Anyway, what do mean before it is executed? Once image loaded does execution 
ever stop ? You mean at some strategic or random points of execution ?

> 5) Prevent changes to compiled methods
>

You can try and lock MethodDictionary so that they do not accept to add remove 
or change any key/value, but for UndefinedObject doIt... (You just have to 
redefine few messages...). But you must make sure that there isn't a way to 
interpret some unbound CompiledMethod...

Without restricted compiler, I can figure some attacks on such a lock, like 
creating a simple dictionary, copying compiled methods from here and there 
and changing class to that of MethodDictionary and then replacing 
MethodDictionary's MethodDictionary via a become:., all this in a single 
doIt...

If you allow user relexive access to the Compiler, MethodDictionary or 
whatever you did protect, then your system is not closed enough.

Then you can play the game to protect the protections, but untill you find a 
way to have a protection loop, that is just adding complexity to the system, 
and you might well add more weak points if your design is too complex...

How to obtain a cyclic protection? That may be interesting...

> Plus more that I'm sure will also be needed.  If we can sign the image and
> VM and change the VM to check the signature before staring up and find a
> way to protect the live image then we will have gone a long way to having a
> more secure development platform.
>

And of course the plugins and DLL must be signed too.

> I've mentioned this before and got absolutely no comment from anyone.
> (Maybe the email was too long to read?)
>
> Some input would be very much appreciated.
>

Maybe i didn't had much value...

Nicolas

> Ron Teitelbaum
>
> > From: Bert Freudenberg
> > Sent: Monday, July 31, 2006 12:37 PM
> >
> > Am 30.07.2006 um 06:15 schrieb Ron Teitelbaum:
> > > Hello all,
> > >
> > > I'm currently working on a TLS / SSL implementation and on windows
> > > I am planning to support the Certificate Store that is built in.
> > > This requires me to use the CryptoAPI dlls.
> >
> > Well ... FFI is inherently unsafe - it allows to call any C function
> > in any library. So depending on the area of application this might be
> > a problem, since you're giving up the relative safety of a VM-based
> > system. For example, if the VM's sandbox is enabled, FFI calls are
> > disallowed, so you could not use crypto in a sandboxed environment.
> >
> > - Bert -