Ok Ok...the above pic isn't a sandbox but of cottages by the sand taken during one of my trips to Goa, but it should still be enough to set the tempo for this blog post....and also hopefully take the people here to a nice tranquil place by the sea....the sun....the sand :)
So I've been toying with ideas on how we can sandbox the applications run by eBrainPool and enhance security and privacy. Our goal is that applications should run from a remote device but behave just as though it were a natively installed application. A user should be able to work on the data on his local device just like the software were actually installed on their device. In addition, neither party should be able to see each other's data but most importantly the host serving the application needs to have their data, configuration files, password files all safe and locked away. In other words we need a sandbox.
I've been going through what options we have and have come across quite a few sandboxing technologies such as chroot, Google's Chrome sandbox, SELinux sandboxing but the one that has struck a chord with me is the Linux Container (LXC) mechanism.
From the LXC website : LXC builds up from chroot to implement complete virtual systems, adding resource management and isolation mechanisms to Linux's existing process management infrastructure.
Linux Containers (lxc) implement:
-
Resource management via
process control groups(implemented via the cgroup filesystem) -
Resource isolation via new flags to the clone(2) system call (capable of create several types of new namespaces for things like PIDs and network routing)
- Several additional isolation mechanisms (such as the
-o newinstanceflag to the devpts filesystem).
What this means in our context is that using LXC we can have a virtualized container that uses the same kernel as the host but isolates resources such as the filesystem,networking,etc. My experiments with this have let me create a new container that shares the /usr, /bin, /sbin, /lib and /lib64 directories from the host. These directories are mounted readonly in the container. Therefore we can run the same software on the host inside the container. The container has its own /etc and /home directories complete with its own root and an ebp user. This gives us complete process,user and configuration/data abstraction from the host. Finally the container has it's own sshd and avahi-daemon processes running and does not share the X server on the host.
The idea I've been toying with is to have the eBrainPool client itself run inside the container. Since the container cannot see the X server on the host for now I've been ssh-ing and X forwarding the eBrainPool client from the host. Having the core eBrainPool client itself running inside the container automatically means that any processes it launches for a remote user will be inside the container i.e. sandboxed.
These processes will have their root different from the host system and the filesystem abstracted. These processes will also not be able to tamper with the processes or data on the host.
I'm currently toying with easy ways to have access to the network from inside the container. On eway that I have tested is to replace my eth0 on the host with a bridge, the container's veth network module then connects to this bridge. This works fine, however requires changes on the host system.
I'm currently working on creating a separate network bridge for the container and then routing traffic between my this and the host network interface. http://wiki.debian.org/LXC/SimpleBridge explains the technique however I'm trying to tweak this to best suit our needs. So stay tuned as I enjoy playing in the sandbox :)