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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Michael van der Gulik-2


On Mon, Jul 7, 2008 at 5:24 AM, Jason Johnson <[hidden email]> wrote:
On 7/5/08, Michael van der Gulik <[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

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

Jason Johnson-5
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 <[hidden email]> wrote:

>
>
> On Mon, Jul 7, 2008 at 5:24 AM, Jason Johnson <[hidden email]>
> wrote:
>>
>> On 7/5/08, Michael van der Gulik <[hidden email]> 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/
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Michael van der Gulik-2


On Mon, Jul 7, 2008 at 8:43 PM, Jason Johnson <[hidden email]> wrote:
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.


Please reply under postings.

My Namespaces implementation requires a complete refactoring of everything in the image and review of all code ever written. It would be a major effort and would break backwards compatibility.

Sure, it /could/ be used for Squeak. In reality, it will never become part of Squeak because the community would be shifting paradigms without a clutch and would probably disintegrate into chaos. The infighting would be terrible. There might be blood. There would be so much flaming that you could cook eggs on your mail client.

It would be easier and less stress to wait for SecureSqueak to be usable, and use that as a base for any Namespaced projects you want.

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Reply | Threaded
Open this post in threaded view
|

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

Jason Johnson-5
On Tue, Jul 8, 2008 at 1:29 AM, Michael van der Gulik <[hidden email]> wrote:
>
> Sure, it /could/ be used for Squeak. In reality, it will never become part
> of Squeak because the community would be shifting paradigms without a clutch
> and would probably disintegrate into chaos. The infighting would be
> terrible. There might be blood. There would be so much flaming that you
> could cook eggs on your mail client.

:)

> It would be easier and less stress to wait for SecureSqueak to be usable,
> and use that as a base for any Namespaced projects you want.

Yea, but that's the thing: I don't plan to use SecureSqueak.

Thanks for taking the time to explain it.  Who knows, perhaps someone
will do the work you mentioned to make a version of the image on your
namespaces to try out.