Capabilities in Squeak (attn: Lex Spoon and friends)

Michael van der Gulik <[hidden email]> writes:
> Hi all.
>
> Does anybody have code (particularly VM modifications) which allow
> Capabilities in Squeak?
>
> In particular, I'm referring to code that implements stuff described
> on this page:
> http://minnow.cc.gatech.edu/squeak/uploads/2074/sandbox.html

This is my old "Islands" project, done during an summer internship
with the Squeak group in 2000.  The group was just starting to work on
sharing EToy's.  For example, that was when the SuperSwiki and the
web-browser plugin were developed.

I had recently been "Millered", and was fascinated by the possibility
of object references and message sending being your security kernel.
So, I attempted to use this approach so that you could run untrusted
EToy's inside Squeak without needing a special VM mode.  You could
then email someone an EToy and they could read play with it right in
Celeste.

I got so far as getting BouncingAtomsMorph to run in a sandbox, but
then ran out of time.  I went back to hammering on type inference,
which was engrossing and sucked away all of my next 6 years.


Full information about Islands is available at this page:

    http://minnow.cc.gatech.edu/squeak/2074

It includes the rationale, the source code, a pre-built image, and
notes about updating it to newer Squeaks.


I still think the basic approach is good.  The next thing I would do,
were I to continue, would be to get rid of the dynamically bound
global variables, and instead to have separate, static namespaces.
The reason for the current approach--i.e. all global references are
bound indirectly through the currently active island--is that compiled
code can be reused across multiple islands.  In retrospect, it would
be better to maintain conceptual pruity and simply recompile any
reused code.


More broadly, I still think the object capabilities approach is
important and worth giving a good look in any new language.  It is a
feature you cannot very well add late.


-Lex

Lex Spoon wrote:  > [...]
> I still think the basic approach is good.  The next thing I would do,
> were I to continue, would be to get rid of the dynamically bound
> global variables, and instead to have separate, static namespaces.

That does sound good.


> The reason for the current approach--i.e. all global references are
> bound indirectly through the currently active island--is that compiled
> code can be reused across multiple islands.  In retrospect, it would
> be better to maintain conceptual pruity and simply recompile any
> reused code.

A different compilation strategy would still allow compiled code to be shared
-- by treating these the way other languages treat captured outer lexical
variables.


> More broadly, I still think the object capabilities approach is
> important and worth giving a good look in any new language.  It is a
> feature you cannot very well add late.

It has indeed been hard to add objcaps to Squeak after the fact, or rather to
subtract out the non-objcap parts of the language. (Motto: "Don't add
security, remove insecurity.") Other efforts have yielded varying results.
Securing Java to create Joe-E[1] looks quite good, and we have recently been
using this successfully within HP. Although Java is much more
"object-oriented" than Scheme or OCaml, W7[2] and Emily[3] were much easier
than Joe-E, whereas securing Common Lisp[4] was hard enough that the effort
seems to have been abandoned. The effort to secure Mozart/Oz is proceeding
slowly, but has yielded one of the best documents[5] about the issues in
retrofitting objcaps into an existing language. I am also hopeful about a new
effort to secure Python[6].

All these efforts have freshly encountered many of the same issues. It would
be good if they could learn more from each other. A secure Squeak-like
language would still be awesome. Perhaps we should have a workshop about
retrofitting objcaps into existing languages?

[1] http://www.joe-e.org/
[2] http://mumble.net/~jar/pubs/secureos/
[3] http://www.hpl.hp.com/techreports/2006/HPL-2006-116.html
[4] http://www.eros-os.org/pipermail/e-lang/2005-August/010923.html
[5] http://www.info.ucl.ac.be/~pvr/oze.pdf
[6] http://sayspy.blogspot.com/2006/07/security-design-doc-using-object.html

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

Oh yeah, and CaPerl[7,8], which looks more plausible than I could ever have
guessed.

[7] http://caperl.links.org/
[8]
https://www.opengroup.org/projects/jericho/uploads/40/8299/8_-_JFChallenge_Lawrie.pdf

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

Lex Spoon wrote:
Islands is used in Croquet. I'll have to see how they're used there and
what changes have been made.

Do you mind if I grab your code and run with it? Also, what license is
this released under? MIT?

Many thanks!
Michael.

Mark S. Miller wrote:

Wow! I have reading to do.

Thanks for the references!

Michael.

On Oct 17, 2006, at 12:19 AM, Michael van der Gulik wrote:

>> I have a vm changes file that changes #== and #class out there.
>
> Here?: http://minnow.cc.gatech.edu/squeak/2410

Here's a better link:  http://www.squeaksource.com/squeakelib/ 
SqueakElibVM-rww.1.mcz

>
> I'll be making changes to the VM eventually, so this code is much  
> appreciated. Do you mind if I consider it released under the MIT  
> license?

Yes, I released under MIT.

Cheers,
Robert

That's a very small .mcz :-). I've just had a look at your changes, and while they'd work, they'd come with a speed penalty. Essentially, you're just un-doing the optimisations on #== and #class.

I'm not sure this is the right way to go. I'll think about it some more.

Thanks for the code in any case!

Michael.

> > The reason for the current approach--i.e. all global references are
> > bound indirectly through the currently active island--is that compiled
> > code can be reused across multiple islands.  In retrospect, it would
> > be better to maintain conceptual pruity and simply recompile any
> > reused code.
>
> A different compilation strategy would still allow compiled code to be
> shared -- by treating these the way other languages treat captured
> outer lexical variables.

Yes, though for what I think you are suggesting, you would want to
have outer variables that are not global -- i.e., nested classes.

So that gives three solutions to the problem of having multiple (for
example) "World" variables.  The original Islands turns the global
variable World into an island-scoped variable, with a dynamic lookup
indirected through the current island.  This has the advantage that
existing code needs little modification; however, it has the
significant cost that you have to be very careful about which island
is currently installed as the active one.  That turns out to be rather
fiddly and error prone.

The nice thing, though, before moving on, is that a "global" variable
reference gives no new authority!  Thus, if you are reviewing the code
of a class, you do not even need to look at normal global references.
Instead, you only need to look at "hard-bound" references,
i.e. statically bound references, which are rare.

Anyway, the middle-level solution I propose above is to have multiple
global namespaces, and to recompile classes for each namespace.  This
way you can still reuse classes that refer directly to World, but you
have to fiddle with recompiling them.  I would try this first, just
because it is so unobtrusive to the existing language and libraries.

Perhaps we should go all the way, though, and explore nested classes.
The only issue there is that it is a major change.  Implementing it in
the language is not a big deal, but updating all the browsers and
debuggers and so on looks like a lot of work, especially if you try to
achieve anything like Smalltalk's level of tool quality.  Still, maybe
you have to go this far if you want to take the hard line on lexical
scope and get a usable, security-sensible system.



> > More broadly, I still think the object capabilities approach is
> > important and worth giving a good look in any new language.  It is a
> > feature you cannot very well add late.
>
> It has indeed been hard to add objcaps to Squeak after the fact, or
> rather to subtract out the non-objcap parts of the language. (Motto:
> "Don't add security, remove insecurity.") Other efforts have yielded
> varying results.


Thanks for the excellent overview.  I was only aware of some of these.

-Lex

Nested classes? What do you mean? Are you talking about nested Namespaces (org.squeak.kernel.numbers.SmallInteger)?

Michael.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Michael

Michael van der Gulik wrote:
Have you read papers about E? Have you read Mark Miller's dissertation?
http://www.erights.org/talks/thesis/index.html

"Nested classes", "nested functions" or lexical scoping is related to
the unusual (like in lambda-calculus, like in pi-calculus, etc) rules
which determine which variable names are visible in the particular point
in the source code. It may seem "weird" but it is one mechanism which
can be used to build secure language (in the sense of E).

Can we implement Point in Smalltalk and E? Yes.

What about ConstantPoint? Constant point is such an object which behaves
exactly like a Point except for that it cannot be moved (once it is
created). Can we implement such a thing in Smalltalk? Yes, it is
"enough" to implement E interpreter in Squeak and then you are done. Can
we implement constant point directly in E? Yes, it is trivial (few lines
of code).

Or am I wrong? Is it somehow possible to implement ConstantPoint in
Smalltalk?
- --
Matej Ko?ík
icq: 300133844, skype: matej_kosik, [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNykgL+CaXfJI/hgRAs3NAKDDbxKxZpJ+3TUGrgDrxNMZkHiDAACggP4s
l5V8WAp1Yf8Wzy6FOuxSfm4=
=CQjN
-----END PGP SIGNATURE-----

> Or am I wrong? Is it somehow possible
> to implement ConstantPoint in
> Smalltalk?

If you need a point that do not move,
 do not send #move messages to the point.
Nothing more efficient than the action
 that has not been done.
(if you have points that move and points that
 do not move... it is very provable to have a
 "failure" or a wrong point in the wrong place)

best,
Ale.



----- Original Message -----
From: "Matej Kosik" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Thursday, October 19, 2006 4:28 AM
Subject: Re: Retrofitting objcaps

classes.
> >     The only issue there is that it is a major change.  Implementing it
in
> >     the language is not a big deal, but updating all the browsers and
> >     debuggers and so on looks like a lot of work, especially if you try
to
> >     achieve anything like Smalltalk's level of tool quality.  Still,
maybe

Matej Kosik wrote:
> What about ConstantPoint? Constant point is such an object which behaves
> exactly like a Point except for that it cannot be moved (once it is
> created). Can we implement such a thing in Smalltalk? Yes, it is
> "enough" to implement E interpreter in Squeak and then you are done. Can
> we implement constant point directly in E? Yes, it is trivial (few lines
> of code).
>
> Or am I wrong? Is it somehow possible to implement ConstantPoint in
> Smalltalk?

Sure. It's not even hard and I can think of at least three methods
depending on how far you want to go with the level of support. The
easiest (and most illustrative, though not directly comparable) method
is this:

makePoint: aPoint
   "Create a constant point object"
   | pointClass pointObj |
   pointClass := aPoint newUniclass.
   pointClass compile: 'x ^', aPoint x printString.
   pointClass compile: 'y ^', aPoint y printString.
   ^pointClass new

The other two methods are:
* Use literal sharing, e.g., the identical x, and y values. The
difference to the above is that both x and y would be parsed again by
the compiler and therefore may not be identical to the input
* Use blocks as accessors which would also use lexical scoping rules and
be the most truthful (but least readable and hardest to implement
directly) solution.

The main thing that's missing in Squeak to support this more easily is
some "literal object" syntax by which you could create an anonymous
class in a method and instantiate that class directly. This would allow
you to reuse the same class over and over again, but it would not be
much different from the above.

Cheers,
   - Andreas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Alejandro

Alejandro F. Reimondo wrote:
>> Or am I wrong? Is it somehow possible
>> to implement ConstantPoint in
>> Smalltalk?
>
> If you need a point that do not move,
>  do not send #move messages to the point.

If I were the only one who would like to use that object than it would
be partially acceptable. But as soon as I would give others the
permission to that constant-point, I would like to *enforce* my
particular policy I had in mind.

If I do not want others to move that point then I do not want to give
them authority to move that point.

If I do not want other system to write more than 100 character log to
some file, then I do not want to give it authority to write more than
100 characters.

(other examples could be invented)

In Smalltalk such things are not enforcable. In E they are. Why is the
ability to enforce some policy important? It is usually useful when one
wants to cooperate with parties but he/she/it does not fully trust them.
In day to day reality this happens all the time.

> Nothing more efficient than the action
>  that has not been done.
> (if you have points that move and points that
>  do not move... it is very provable to have a
>  "failure" or a wrong point in the wrong place)
>


- --
Matej Kosik
icq: 300133844, skype: matej_kosik, [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNzZGL+CaXfJI/hgRAjAEAKCImxsnMNX9OkRtJYAUTu1HXZlagQCgrWpr
MB2WgDznluLlRfwMS6lTqyk=
=wNSJ
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andreas,

Andreas Raab wrote:
This is interesting. Thank you. Although I do not have `newUniclass'
method directly in my image, there is something similar. So if I do this:

        pointClass := Object newUniqueClassInstVars: ''
                             classInstVars: ''.
        pointClass compile: 'x ^ 100'.
        pointClass compile: 'y ^ 100'.
        point := pointClass new.

I can indeed see that

        point x

gives

        100

and
        point y

gives

        100

However, if I passed reference to the `point' object to you (to your
code), were I able to stop you (your code) from doing

        point class compile: 'x ^ whatever'

? If not, then this is not the solution to the original problem. It
would be necessary to ban the "compile:" class method. And since
Smalltalk has many crooked lanes, we could again miss some other
vulnerabilities.

Does `point' have a class? Yes. Its name is

        point class

In my case `Object1'. What would prevent anyone from doing this

        (Smalltalk at: #Object1) compile: 'x ^ 10'

this should again be banned. It must be enforced that something like
that is impossible. I am afraid that the number of possible
vulnerabilities is overwhelming. Although this is related to the
"libraries" rather than to the language, the question is, whether the
"libraries" can be "tamed" or whether the whole thing should be thrown
away and everything restarted with security in mind from the begining.
In E they've done it. I believe. The tendency to keep current languages
and "adding security" is caused by the fact that we love Smalltalk
(Python, Ruby, Java, Erlang, ...) and do not want to turn back to it. I
am not proposing everyone to swich to E, I am not part of the E project,
I am only amazed, the question is, if we are really concerned with
security, whether such switch (directly or indirectly) would not be
necessary. Adding convenience/nice gui/great gui tools to E could be
possible whereas adding security to Smalltalk/Java/Python/Ruby/Erlang
may turn out to be
- - either impossible
- - or we will end up with essentially some almost E-quivalent (and thus
contributing to world fragmentation)


- --
Matej Kosik
icq: 300133844, skype: matej_kosik, [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFN0j4L+CaXfJI/hgRAj/zAKDV7MEw2TlJ37Um7qGCBgWLqVa9rACgrKqX
rtfk+eneeCJO4Y98J4baTe0=
=eDen
-----END PGP SIGNATURE-----

Can anyone help me to get this to work.

MczInstaller installStream: (ReadStream on:
(('http://bugs.impara.de/file_download.php?file_id=2176&type=bug') asUrl
retrieveContents content))

I have tried a wide variety of variants

many thanks in advance

Keith

               
___________________________________________________________
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal
http://uk.docs.yahoo.com/nowyoucan.html

Ok I did it after 4 hours of trying

MczInstaller installStream:
(('http://bugs.impara.de/file_download.php?file_id=2176&type=bug') asUrl
retrieveContents contentStream)

many thanks in advance

Keith


               
___________________________________________________________
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html

Keith Hodges puso en su mail :
Clicking in the link automatic download the Join-kph.1.mcz (on Mac)
>From here, you could drag and drop or fileIn.
By the way , what do the .mcz ?



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

Matej Kosik wrote:
> However, if I passed reference to the `point' object to you (to your
> code), were I able to stop you (your code) from doing
>
> point class compile: 'x ^ whatever'
>
> ? If not, then this is not the solution to the original problem. It
> would be necessary to ban the "compile:" class method. And since
> Smalltalk has many crooked lanes, we could again miss some other
> vulnerabilities.

Of course you could prevent hat but the art is in restructuring the
class libraries to serve this goal. The trivial solution is to override
over access to the method dictionary by, e.g.,

ConstanstPoint class>>addSelector: selector withMethod: method
        self error: 'Poop'.

or somesuch. That's not enough by far but it shows the general direction
(Lex has a lot of that in his whitepaper).

> Does `point' have a class? Yes. Its name is
>
> point class
>
> In my case `Object1'. What would prevent anyone from doing this
>
> (Smalltalk at: #Object1) compile: 'x ^ 10'
>
> this should again be banned.

This is why I used #newUniclass. In Tweak, this creates an anonymous
subclass which is marked by an asterisk in front so

        Point newUniclass name -> #'*Point'

and it's not in the global system dictionary either. Of course there are
currently many other ways of getting your hands at it, like enumerating
the subclasses of point, or just all objects in memory. All of these
need to be tamed.

The easier thing to do is to introduce an arbitrary layer on top of our
current system and use that as a baseline for programming. As you
progress, you move more and more from the layers below (which
effectively form your TCB) to the layers on top.

Cheers,
   - Andreas

Michael.