One of the best things in Smalltalk or Squeak is the fact that there are almost no artificial barriers and you are free to explore. In a local environment, like on your laptop, there is not much to worry about. But if you use Squeak as a server and expose it to the world, like when you run a Seaside server, then you would like to have at least one high barrier that protects yourself from misuse.

What follows is my experience in setting up a restricted environment (chroot) on a linux box to run a Squeak server.The basic idea is that one sets up a directory with subdirectories and to enforce an environment, where only this directory tree is accessible and nothing else. This has the advantage that even if something goes wrong, it should be almost impossible to break out of this jail. So for example even if someone manages to open a filebrowser in Squeak via Seaside, all he could see would be this directory tree and nothing else.

The hard part is to setup such an environment, because everything you need during runtime has to be in that directory tree. I found that the article “chroot login HOWTO” by White and Rhodes describes very good how to setup a chroot login. This is a user, that after login has only access to a restriced directory tree. Following this HOWTO I found, that the only real problem was to build a working su program. On my minimal Ubuntu system I had to build a new su from sources and to run the installed su through strace to find every needed library.

Now we assume that you managed to setup an account sesidemo and that you can log into it. But you can’t do very much.  The restricted directory could be looking like this:

$ ls /home/seasidemo
bin  dev  etc  home  lib  tmp  usr

You need another trusted user account to install the squeak runtime into this restricted directory tree.

On my linux box the Squeak virtual machine is called squeakvm. Create a usr/bin directory and copy the VM to that place.

$ which squeakvm
/usr/bin/squeakvm
$ cp /usr/bin/squeakvm /home/seasidemo/usr/bin

You also need the shared libraries that squeak uses. As described in the HOWTO you can use ldd to find out, which libraries this are.

$ ldd usr/bin/squeakvm
        linux-gate.so.1 =>  (0xffffe000)
        libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb7f70000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7f6c000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f46000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7f2e000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7de4000)
        /lib/ld-linux.so.2 (0xb7f7b000)

Now you have to locate these libraries (but linux-gate.so.1) in /lib and copy them over to the restricted lib.

$ cp /lib/libutil.so.1 /home/seasidemo/lib
$ cp /lib/libdl.so.2 /home/seasidemo/lib
$ cp /lib/libm.so.6 /home/seasidemo/lib
$ cp /lib/libnsl.so.1 /home/seasidemo/lib
$ cp /lib/libc.so.6 /home/seasidemo/lib
$ cp /lib/ld-linux.so.2 /home/seasidemo/lib

Part of the Squeak VM is made out of VM Plugins. You need to copy them too.

$ squeakvm -version
3.9-12 #1 Sa 5. Jan 00:24:24 CET 2008 gcc-Version 20070929
Squeak3.9alpha of 4 July 2005 [latest update: #7021]
Linux avion.lazarevic.de 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux
default plugin location: /usr/lib/squeak/3.9-12/*.so
$ mkdir -p /home/seasidemo/usr/lib/squeak
$ cp -r /usr/lib/squeak/3.9-12 /home/seasidemo/usr/lib/squeak

These VM Plugins also use shared libraries. As you have guessed: You need them too. I decided to copy every needed shared library for every VM Plugin to fullfill the dependencies, even if the Plugins are not very useful on a server (eg. audio plugins).

I used a small script to find all the libraries needed on my system:

$ for i in /home/seasidemo/usr/lib/squeak/3.9-12/*.so; do ldd $i; done | sed "s/^\t*\([^ \t]*\).*/\1/" | sort -u
/lib/ld-linux.so.2
libGL.so.1
libICE.so.6
libSM.so.6
libX11.so.6
libXau.so.6
libXdamage.so.1
libXdmcp.so.6
libXext.so.6
libXfixes.so.3
libXpm.so.4
libXrender.so.1
libXt.so.6
libXxf86vm.so.1
libasound.so.2
libaudio.so.2
libc.so.6
libdbus-1.so.3
libdl.so.2
libdrm.so.2
libm.so.6
libnsl.so.1
libpthread.so.0
libutil.so.1
libuuid.so.1

Find all those libraries in /lib and /usr/lib and copy them to /home/seasidemo/lib.

At this point you could copy over a prepared headless image to eg. /home/seasidemo/home/server, login into the restricted account and start the squeak with that image.

$ mkdir /home/seasidemo/home/server
$ cp headless.image /home/seasidemo/home/server
$ cp headless.changes /home/seasidemo/home/server
$ cp SqueakV39.sources /home/seasidemo/home/server

Note that by doing that, the image and changes file belongs to the trusted user. Assuming default umask settings and that you don’t change filepermissions, squeak can’t save any changes to that files while running as the user seasidemo. That is a good thing, because it prevents that changes to the squeak system are beeing saved. This could be a problem, if you use the squeak image as an instrument for data persistence.

$ su - seasidemo
Password:
-bash-3.2$ cd server/
-bash-3.2$ /usr/bin/squeakvm -headless headless.image

Now this has the disadvantage, that the server stops if you log out. You might want to find nohup on your system and install that too, so that the server keeps running.

-bash-3.2$ nohup /usr/bin/squeakvm -headless headless.image &

If you need more control over your server you could additionally install Xtightvnc into your restricted environment and use a vnc client to get access to the Squeak desktop of that server.

What I described above just describes how to make squeak run in a more secure environment. It does not prevent the Squeak server from being modified and misused. There are additional measures inside Squeak that make even this more difficult, but this also depends on the kind of server you planning to run.

At http://seasidemo.blobworks.com:9090 you will find a Seaside demo server, that was setup this way.