SecureSqueak

 

Project locations

 

This is the main "Web Site" for SecureSqueak.

Latest News on blogspot.com.

Project page on sourceforge.net.

Squeak code on squeaksource.com.

Subversion repository (for Namespaced code) on sourceforge.net.

Download images / releases.

Bug reporting / Feature requests on sourceforge.net

 

(yes, I'm making good use of the Internet :-) )

 

There is a downloadable image to demonstrate namespaces here. A video demoing this is here on Vimeo.com.

 

There is no mailing list; contact mikevdg at gulik.co.nz for information. If more than one person shows interest, I'll make a mailing list.

 

Project Description

 

SecureSqueak is going to be a minimal, secure fork of Squeak. The goal of SecureSqueak is to allow any untrusted, foreign code to run in your image in a manner that is secure and will not affect other objects in the image. This means:

 

• Untrusted code has no access to plug-ins, devices, global variables or any other means of comprimising system performance and security unless such privileges have been granted.
• Untrusted code cannot consume excessive resources (CPU, memory, disk space, network bandwidth) such that other objects are denied these resources.
• The system as a whole is as stable and reactive as possible.

 

Classes inside SecureSqueak will be organised using Namespaces and Packages. SecureSqueak will consist of the following Packages:

 

• Kernel
• Collections (a basic, minimal version of this package. The user may load a more complex Collections package later.)
• Namespaces
• Dominions (probably integrated into Kernel)
• Networking
• Files (may be removed by the user?)
• Compiler (may be removed by the user?)
• REPLServer (may be removed by the user?)
• Debugger API that can be used by graphical or CLI debuggers.
• Debugger UI, probably based on REPLServer.
• Canvas (also called Subcanvas) for 2D graphics.
• (this list is work in progress)

 

SecureSqueak is initially intended to be a kernel for running DPON on. DPON is a distributed object architecture that will allow for remote Package loading over a network. The ability to load Packages from a file will also be included. It is intended that other people can use SecureSqueak for other projects, such as web servers.

 

As a core system, SecureSqueak's UI will be REPLServer or perhaps a simple console like KernelImage has. The intention is that further packages are loaded to make the system more user friendly.

 

Versions

 

SecureSqueak-TODO list. See also the bug reporting system on SourceForge.net.

 

Items with "UGP:" in front of them are items for the Unnamed Grand Project rather than SecureSqueak. This is a convenient place to keep these items.

 

The main priority is to get a working system going first. Components will be skeletel until extra functionality is needed. "Status: done" means that that item has been completed enough for that particular version; it does not mean that the item is complete or stable. Work will continue on all components as extra functionality or bug fixes are needed.

 

Version 0.1 - Make the infrastructure:

• Namespaces (Status: done).
• Usable tools (Status: done).
• A basic Canvas package (actually called "Subcanvas") with event handling (Status: in progress).
• Port DPON to Namespaces.
• UGP: Make a simple SiteBrowser (Status: in progress).

• Features:
  • Package loading is atomic.
  • Packages can have circular dependencies.
  • Namespaces!
  • You can view Sites on a remote test image.

Version 0.2 - Make the basic API:

• Import and modify the NewCompiler.
• Refactor classes: remove source code and make Class instances "binary only".
• Refactor Namespaces to be a proper secure API.
• Refactor code management tools so that source is managed externally to classes.
• Refactor Kernel: make wrappers for SmallInteger; create Object subclass: DominionedObject.
• Refactor Kernel: put system stuff in private namespaces.
• Perhaps import and refactor the debugger.
• Dominions API (Status: prototype kind of works, on back burner for now).
• APIs for secure programming: private methods, testing the sender, etc.
• Skeletons for restricted classes.
• Exceptions are stored - Processes that throw Exceptions not of interest to the user are suspended and made available for a sys admin to review (requires dominions; exceptions are handled by dominions).

Version 0.3 - Make it secure:

• ObjectInspecter
• ReadOnlyArray, ReadOnlyString, ReadOnlyLargePositiveInteger, ReadOnlyLargeNegativeInteger.
• Restricted Symbols, Characters.
• Restricted Semaphores, Delays.
• RestrictedBlocks
• Restricted classes.
• Restricted MessageCaptures.
• Restricted Exceptions.
• No privileged methods (typically primitives).

Version 0.4 - Make it stable:

• Can debug forking processes - Modify the debugger to automatically open any forked processes in another debug window.
• Dominions functionality.
• Run SmallLint.
• Lots of tests.

 

Version 0.5 - Make it usable:

• Management tools, possibly using REPLServer? Manage dominions, manage exceptions.
• Command-line telnet client (Done: it's called REPLServer. Needs porting to Namespaces).
• Add cryptographic APIs.
• UGP: add user management, authentication.
• UGP: add basic widget set. 

 

Version 0.6 - Make it more secure:

• VM modifications to harden it.
• Bytecode verifier.
• Lots of testing.

 

Version 0.7 - Make it small:

• Shuffle root-object pointers so the rest of Squeak gets GCed.

 

Version 0.8: Make it fast:

• Remove the SmallInteger wrapper (keeping it for possible ports to other VMs) and use a modified system SmallInteger.
• Use primitives again.
• etc.

Version 1.0:

• UNCRASHABLE

 

 

Plan of Attack

 

At some stage after this:

 

1. Write user interface tools (ReactiveUI).
2. Write UI / Site development tool.
3. Make example application (a TODO list manager?)
4. Implement sound, 3-D APIs?
5. Implement device access (disk, USB etc).

 

 

 

VM Modifications

 

 

Bootstrapping SecureSqueak

 

 

The standard Squeak release can be used to host SecureSqueak. If none of the SecureSqueak packages have any dependencies on the SystemDictionary bindings, then a minimal image can be made by removing keys from SystemDictionary.

 

Literals need to refer to their SecureSqueak equivalents. These could be:

• true, false, nil.
• SmallInteger, including -1, 0, 1, 2 which have special bytecodes. These will need to be done using a SmallInteger wrapper (yes, performance will die).
• Numbers: Float, Fraction(?), Points(?), large positive and negative integers, etc?
• Characters, Strings, Symbols.
• Arrays made with #() notation.
• Associations?
• BlockContexts. MethodContexts aren't available to the code.
• thisContext access -> return a wrapper maybe?
• Message. If a user overrides >>doesNotUnderstand:, they can get a Message instance.
• (what about CannotReturnSelector and MustBeBooleanSelector? MustBeBoolean)
• Exceptions
• (I believe these are safe: CompiledMethod, streams,

 

(is ContextPart>>blockCopy: safe?)

 

TODO: go through the Blue Book VM chapters looking for special objects and ways to get special objects, such as >>hash, >>asOop, >>nextInstance, etc.

 

The SecureSqueak compiler (separate from the Squeak compiler) needs also to not optimise the following optimised selectors:

	+	-	<	>
	<=	>=	=	~=
	*	/	\	@
	bitShift:	\\	bitAnd:	bitOr:
	(at:)	(at:put:)	(size)	(next)
	(nextPut:)	(atEnd)	==	class
	blockCopy:	value	value:	(do:)
	(new)	(new:)	(x)	(y)

 

Defensive programming guide

 

DPON

 

DPON ("Distributed Persistent object network") is a distributed object framework that will run on top of SecureSqueak. It will provide remote object replication and remote class loading.

 

Unnamed Grand Project

SecureSqueak and DPON are part of the Unnamed Grand Project.

 

Localisation

 

High-performance computing

 

The Cell processor (Playstation 3 etc) has SPEs that operate on 128-bit quadwords. Most machine code instructions are SIMD instructions treating the quadword as two 64-bit floats, four 32-bit floats, four 32-bit integers, eight 16-bit integers or sixteen 8-bit bytes. It would be nice to include forward-looking support for this in Squeak or SecureSqueak.

 

This also applies for SIMD instructions in other CPUs.

 

The OpenGL ES shading language uses vectors made of bools, ints and floats as a primitive language feature. It would be nice if Smalltalk code could somehow be translated to SL (which represents a limited C++) and run on a GPU.

 

Ideally, nice language support could be added early on, with efficient and fast implementations coming later. Implementations require access to hardware somehow, using plug-ins or a compiler like Exupery.

 

These features could potentially be supplied by a combination of:

• Adding classes and methods for bulk array operations. This would include aggregating operations (sum, averages, sorting, etc), as well as combining operations with other arrays (multiplying, adding, etc).
• Vertice and Matrix classes could be added with support for operations that these support.

 

Also, plugins such as movie encoding/decoding, image processing and music decoding could be done using whatever the hardware provides.

 

Some hardware won't be able to perform these operations as well; some metric API would be needed to determine whether a particular machine is suitable for these operations so that code can determine whether to attempt them.

 

Links and references

 

Squeak-E: http://www.erights.org/history/squeak-e.html

Islands: http://wiki.squeak.org/squeak/2074

Capabilities: http://wiki.squeak.org/squeak/uploads/2074/sandbox.html

Portability across platforms: http://www.seaside.st/community/conventions

http://home.cc.gatech.edu/tony/uploads/32/SharedSmalltalk.htm

 

Java security holes, mostly historical: http://www.securingjava.com/chapter-five/

 

- Should classes be able to implement their own doesNotUnderstand: method?