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

Jason Johnson jason.johnson.081 at gmail.com
Mon Jul 7 08:43:22 UTC 2008


Ok, then I have understood your use correctly. :)  Is the Namespace
implementation you have so far from something Squeak could use (I ask
because you previous message seemed to indicate otherwise)?
Personally I wouldn't be interested in the secure image, but your
Namespace solution sounds pretty good from what I've read.

On Mon, Jul 7, 2008 at 1:02 AM, Michael van der Gulik <mikevdg at gmail.com> wrote:
>
>
> 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/
>
>
>



More information about the Squeak-dev mailing list