Smalltalk Source-Code Firewall?

Richard Staehli rastaehli at mac.com
Sat Apr 26 23:32:25 UTC 2003


I'm also designing a component architecture that must allow code 
fragments
to refer to platform (Squeak core) classes and objects as well as 
third-party-
defined classes and objects.  I believe the issues are the same as you 
have
described, including how to ensure that the Squeak core contains the 
same
(standard) classes and objects, how to resolve dependencies on 
third-party
components, and how to ensure "safety" properties for code loaded in a
particular user domain.  I don't have the answers, but had to respond 
with
some comments and questions on your email:

> Date: Thu, 24 Apr 2003 16:37:24 +0100
> From: "Paul Chapman" <paul at igblan.free-online.co.uk>
> To: "The general-purpose Squeak developers list"
> 	<squeak-dev at lists.squeakfoundation.org>
> Subject: Smalltalk Source-Code Firewall?
>
stuff deleted...
> I am designing an app in which I wish to allow users to write and =
> distribute Smalltalk source-code "fragments" with limited semantics, 
> to =
> run on other users' machines.  It is therefore essential that the =
> implementation of these semantics forbids fragments from accessing 
> parts =
> of the user's image (and underlying platform) not specifically 
> permitted =
> in the app's problem domain.
>
> I wish to know if anyone here agrees or disagrees whether the 
> following =
> approach should work in principle.
>
> (1) Define and build a set of wrapper classes to provide the domain =
> semantics.
Can you give an example of how a wrapper provides semantics?  Do
you mean that these enforce semantics and that all access must go
through these "firewall" classes?
>
> (2) Compile all fragments in the context of the instance-side of a =
> wrapper class specifically designed for that purpose, using an =
> adaptation of the Squeak Smalltalk compiler altered as follows:
What is instance-side?  To get a trusted component, you must be able
to trust the source and know that it was compiled in a trusted 
environment?
Are your users getting pre-compiled components or are they compiling in
their own trusted environment?
>
> (2a) Compiler resolves global references (capped ids) through a =
> compiler-supplied Dictionary containing only the wrapper classes; or =
> perhaps even disallow all capped ids and require a message to self to, 
> =
> eg, obtain a new instance of a wrapper class.
I like the idea of compiler support, but it does seem that it would be 
easier to
declare references to non-core objects in the environment as properties
that must be set when the component is instantiated.  This is the 
approach
I am taking in our project (http://www.simula.no:8888/QuA).

>
> (2b) Compiler flags as a compilation error any message-send whose =
> selector does not appear in a compiler-supplied Set.
...to avoid a runtime error when the wrapper class does not understand?
>
> (2c) Where necessary, compiler compiles "constants" (numbers, blocks, =
> {}s, thisContext, etc) as instances of suitable wrapper classes 
> instead =
> of the usual Kernel classes.
What is special about these in relation to code safety issues?
>
> Might it additionally be useful/necessary to subclass some or all of 
> the =
> wrapper classes from ProtoObject?
>
> Note that my app will NOT prevent any user from using the full =
> facilities of Squeak: I have every wish that users who wish to exploit 
> =
> the full range of Squeak facilities side-by-side with my app (Package) 
> =
> should be able to do so.  It is ONLY the code fragments which are =
> published by the users themselves by submission to an unmoderated 
> server =
> library whose behaviour must be coralled.
>
> ... Hmmm, I've just thought of another relevant question here...
>
> I don't know much about internet client-side firewalls (or any other =
> kind ;).  I do know that my firewall reports that "Squeak.exe" wishes 
> to =
> access the net as a client when I do any client stuff, like using =
> Scamper.
>
> Is it possible from within a "standard" Squeak image (with a 
> "standard" =
> VM) to present a network request through a firewall in the name of a =
> particular Squeak "subsystem" (in this case, my app), so that a 
> nervous =
> user can instruct his/her firewall to permit my app to access the net, 
> =
> but not other parts of the Squeak image?
>
> Does my question make any sense? ;)
I'm no expert in firewalls either.  I hope someone else will reply to 
your
questions.
>
> Cheers, Paul



More information about the Squeak-dev mailing list