>
> On Wed, Mar 17, 2010 at 9:03 PM, Michael van der Gulik
> <mikevdg at gmail.com> wrote:
>> On Thu, Mar 18, 2010 at 2:23 PM, Chris Muller <asqueaker at gmail.com> wrote:
>>>> In SecureSqueak, direct invasive object access using basicAt:put:,
>>>> at:put: and so forth will be disallowed.
>>>
>>> I've always wondered what good this would do, blocking particular
>>> kinds of object-access api's.  Couldn't an attacker easily just
>>> (mis)use whatever legal-api to wreak havoc anyway?
>>
>> No.
>>
>> The goal of SecureSqueak is to provide an image that can run foreign
>> untrusted code in a way that doesn't affect the running of the rest of
>> the image, VM or operating system. I won't be providing attackers with
>> any APIs or objects that let them wreck havoc.
>>
>> Java, for the most part, already does this. The only security feature
>> Java doesn't implement is the ability to control excessive memory or
>> CPU use.

On Thu, Mar 18, 2010 at 3:42 PM, Chris Muller <asqueaker at gmail.com> wrote:
> Yes, I have always found your project interesting, even if I don't
> understand it.  For immutability I understand that blocking
> basicAt:put:, instVarAt:put:, the Compiler, etc., might help for
> secure immutability from attackers, but can you support object
> serialization?  Beyond that, I was curious about is whether
> SecureSqueak addresses how to prevent an attacker from using any
> object as a confused deputy.  Or from changing someone's name from
> Peter to Paul, etc.  Does SecureSqueak employ capabilities to address
> these issues?

The general idea behind SecureSqueak isn't too complicated. When the
user clicks on some link in the UI or somehow causes remote code to be
loaded over a network connection, that remote code (bytecodes,
effectively) will be loaded into the image and executed. The idea
behind SecureSqueak is that untrusted code can't do any harm to any
other code or objects in the image; the only things that remote code
has access to is a window to draw in, events from the UI when that
window is active, and maybe some services it needs access to such as
logging. So it's basically like a web browser, but for Smalltalk code
rather than HTML.

Serialization is implemented manually by each class. I prefer this
way: you only serialize the object state that needs to be serialized,
and you can choose the most efficient way of serializing that state.

As with the confused deputy (which I assume is an object that
overrides doesNotUnderstand: with minimal implemented methods), I'm
going to be adding a whole lot of ways of verifying the authenticity
of an object.

I don't understand the attack about changing somebodies' name. Objects
won't have access to the SystemDictionary (unless they ask really
nicely), if that's what you're referring to.

I should be making a release of SecureSqueak (0.2) sometime soon, but
it won't be a very interesting or secure one. I'm still a couple of
years away from the really interesting stuff. No rush, right :-).

Gulik.


-- 
http://gulik.pbwiki.com/