[squeak-dev] Gulik's Unnamed Grand Project (was Namespaces).

Michael van der Gulik mikevdg at gmail.com
Sun Jul 6 23:02:50 UTC 2008


On Mon, Jul 7, 2008 at 5:24 AM, Jason Johnson <jason.johnson.081 at gmail.com>
wrote:

> On 7/5/08, Michael van der Gulik <mikevdg at gmail.com> wrote:
> >
> > These Namespaces are not for Squeak. They are for a fork of Squeak I'm
> >making, called SecureSqueak.
>
> I'm not sure I have ever understood your use of the word "security"
> here.  When I think of security (as relates to technology) I think of
> firewalls, access rights and the like.  Is something like this what
> you mean, i.e. that unknown users can inject code into the image but
> it has no rights unless someone grants them, etc.?
>
>

Okay; some background:

I'm currently working on a project, called the "Unnamed Grand Project". It
doesn't have a name yet because I can't think of a good one. Suggestions
welcome :-).

The "Unnamed Grand Project" (1) is kind of like a web browser for something
like Squeak "Projects" on the Internet [by "Projects", I'm referring the
Morphic projects you can load from a .pr file]. I call these "Sites". Each
"Site" is loaded from another computer, and contains bytecodes which are
executed locally. In other words, I'm making a better World Wide Web using
replicated objects(7).

These remotely loaded bytecodes (aka classes and methods) are untrusted and
need to run in a locked-down sandbox of sorts, and local services that these
bytecodes have access to need to be very defensively coded so that this
untrusted code can't do anything other than draw on the screen, play sounds,
and so forth.

By "security", I mean that remotely loaded code does not have access to any
more of your system (image, VM and OS) than it needs to run. Remotely loaded
bytecodes shouldn't be able to destructively modify the image or lock it up.
It should not have access to the operating system except through carefully
controlled, secure interfaces. It shouldn't be able to get references to
objects it does not need, even through malicious tactics. Remotely loaded
code should have resource controls placed on it(2) for CPU, memory, and
external services it may have access to like disk access or network access.

So, my active projects are:

SecureSqueak(3) is a fork of Squeak that's be specially designed to run
untrusted bytecodes;

Namespaces(4) and Packages(5) are a way of organising code in SecureSqueak
so that it can be transferred between machines (as well as other features);

Subcanvas(6) is the 2-D API which is passed to remotely loaded code so that
the code can draw stuff on the screen and react to events.

(1) http://gulik.pbwiki.com/Unnamed+Grand+Project
(2) http://gulik.pbwiki.com/Dominions
(3) http://gulik.pbwiki.com/SecureSqueak
(4) http://gulik.pbwiki.com/Namespaces
(5) http://gulik.pbwiki.com/Packages
(6) http://gulik.pbwiki.com/Canvas
(7) http://www.gulik.co.nz/dpon_design.pdf

Gulik.

-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080707/4085a12c/attachment.htm


More information about the Squeak-dev mailing list