Plugin Security (Was Re: How do I create a SqueakPlugin.image from a 2.9a ?)

Bert Freudenberg bert at isg.cs.uni-magdeburg.de
Tue Jan 23 07:50:53 UTC 2001


On Mon, 22 Jan 2001, Russell Allen wrote:

> I appear to be able to read and write the entire directory that the
> image is in.  On Windows machines this is the directory that all of the
> plugins are in, so theoretically I could write a squeaklet that deleted
> all competing plugins such as shockwave and flash :)  
> 
> Worse, I could replace them (and Squeak) with alternate binaries :(

That's why I made the image directory a subdirectory of the plugin
directory in Unix - you can only write (and read) there.

[Note: You can still read the entire disk via the "file:"-URL hack.]

> Even if I was only allowed to save the image, I could at the very
> least mount a DOS attack on the machine by filling the HD up with an
> image bloated with random data.

Yep, that's true.

> Obviously in time a full security system with sandpits and trust levels
> would be nice; in the meantime could we disable the ability of
> SqueakAsPlugin to write to the local drive at all?

Of course you can - change plugInAllowAccessToFilePath() to answer false.
Wait, this prevents reads, too?!

>  (With the exception of automatic updates to the VM/image - maybe that
> should be done at the VM level? With cryptographically signed updates?
> :)

IMO we should leave VM/Plugin updates to an external installer.

Regarding signed applets, this is actually built-in: Michael, could you
elaborate?

-- Bert






More information about the Squeak-dev mailing list