Plugin Security (Was Re: How do I create a SqueakPlugin.image
from a 2.9a ?)
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
More information about the Squeak-dev