I've been toying with Linux Containers (LXC) to provide a sandbox for eBrainPool. Design objectives of the eBrainPool system with regards to sandboxing can be roughly jotted down as :
-
applications on the host should be run within this sandbox and shared to the outside world.
-
filesystem isolation - host's data should be inaccessible to someone running software from the host. The container should have a separate configuration directory (/etc). All shared directories should be mounted read only within the container.
-
Isolation of other resources such as network access, users and groups, X server, OpenSSH keys, etc.
- Do the above with minimal impact to the host system and overall network - changes required to the gateway/firewall,etc of the network are out, changes requiring a lot of root access on host are out, changes that may somehow cause disruption or degradation of service to the host user are out.
I have doodled on a few sandbox designs trying to determine which most successfully meets the above objectives. I shall present these and discuss the merits / demerits of each of these designs both to crystalize my own thoughts and hopefully gather information on any other design or factor I may not have considered.
Design 1 - Bridging network interface on host
Here we have a Linux Container that shares the /bin, /sbin , /usr, /lib,/lib64 directories from the host. These are bind mounted read-only within the container. Therefore, the container can run the same applications within itself as are accessible on the host. However, the container has it's own /etc directory, users / groups and their home directories. The container also has it's own OpenSSH server (sshd) and Avahi daemon.
The host's X server is isolated away from applications running in the container. The eBrainPool client itself is X forwarded from the container to the host i.e. the client runs in the container, since the container has no access to the X server running on the host to display the UI we use ssh's X forwarding.
The container is placed on the same network segment as the host via a bridge - for e.g. if eth0 is the network interface on the host of interest to us then we create a bridge and add eth0 to it. The container then gets it's IP statically or dynamically and is seen as another host on the main system.
This requires a change on the host's networking subsystem - creating the bridge and adding the network interface to that bridge. This most likely will be non-trivial and may not be possible to blindly automate. It could possibly need changes on other configurations on the host for these to work properly. It also needs root access to setup and any time we wish to have eBrainPool listen on a different network interface say the WiFi or Bluetooth interfaces a setup of the bridge for this interface needs to take place.
In short this requires complex and substantial changes to the host. It meets all of our other objectives but the last - however this maybe the most crucial objective of them all - simplicity, that's what we want in the end for a user. Changes required by this design can potentially bring to a halt a perfectly well running system and so is a no-go.