[Etoys] Key generation
andreas.raab at gmx.de
Fri Oct 20 18:10:25 EDT 2006
Hi Guys -
I just had a chat with Scott about the issues of key generation etc. It
is important to understand what this mechanism is good for to understand
what to do about it. So here is some history: In the early days of this
mechanism at Disney we were concerned about someone slipping some code
into a project file, get you to click on it and cause some harm. We
decided to draw a line by using the sandbox model which disables access
to files, disallows saving the image etc.
However, one of the issues that we (thought we) needed to deal with was
how to determine whether to run in trusted or in sandboxed mode. We
decided to do that by each machine generating its own private/public key
pair and simply sign all projects. This allows us to determine when we
load a project whether it was created on the machine and kick in the
sand box if needed.
That was the theory. The praxis turned out differently. If there is a
single thing that I feel we got really, really right for dealing with
security was to enable the ability for users to drag and drop content
from the OS onto Squeak and have it accept it even in sandboxed mode.
Because of that mechanism, we really *never* had a need to run in
trusted mode since anything an eToy user would ever do with files can be
represented by drag and drop.
On OLPC we should draw the appropriate consequences from that
experience. In short that means that the sandbox should simply always be
on. And if we turn on the sandbox then we don't need any signing.
However, since we're so close to the deadline I wouldn't recommend
trying to get this done for this build. What I would recommend is the
* For this build only: Ship with a precomputed Squeak.keys file. The
implication is that the machines in this build are indeed vulnerable to
attacks if you load an eToy from an external source but since exposure
of BTest-1 will be so limited I don't expect that to be a problem at all
(basically all I expect people to do in reality is to show off the
tutorial and examples).
* Right after the deadline: Turn on the sand box and turn off all the
other security checks. There is really no reason for those if we're
always running in the sandbox.
* Some time later: Figure out what the logical equivalent to the DnD
interaction on OLPC would be. This depends largely on OLPC's view on how
applications/activities exchange data; it could just be the clipboard.
More information about the etoys-dev