Application cage
CC0-1.0 License
kagome
is a collection of scripts helps to run programs in Linux in isolated environments.
As for now this repository doesn't provide installer or similar product-ready installation guide. It's just an example on how to make your desktop more secure by running each program in their own isolate environments. Though this may change in future.
Indeed, why the hell someone should invent crazy methods to run programs? Err, docker? And anyway, Linux doesn't have viruses, does it? I'm already overprotected just by running Ubuntu!
Well, it's true that Linux isn't the most popular desktop operating system. Though it does have viruses and there are a lof of blackhats who regularly search security holes in Linux programs. Even if their attack will not target just you, you still be nice link of huge botnet chain.
By the way do you now what in Linux:
xev -id <windowid>
)If even this doesn't hesitate you then maybe you should read Nothing to hide (russian translation) or just buy the MacBook (joke).
TODO: Add more links to security holes to make you scared.
So one of the solution of running extremely buggy software along with the sensitive data at the same machihe is to use sandboxes. This idea is not new though virtualization field and especially the lightweight containers gained broad attention recently and make things much easier:
The main concept of kagome
is to run all your applications in separate lightweight Linux containers with separate filesystem and X server.
In many ways subuser
very similar to kagome
. It solves the GUI isolation problem with Xpra X11 bridge.
Someone may suggest SELinux or other MAC implementation. Indeed, isn't such mechanisms should solve this kind of problems instead of doubtful reinventing the wheel with the containers? Well, partly this is true though SELinux has it's own disadvantages:
On the other hand if we assume for a moment that container isolation is unbreakable then we may don't care about application details at all: just run it inside the sandbox and do you work. In other words: with SELinux it's a lot of work for each application, with VM/container you just run inside whatever you want.
By the way we could use MAC rules for Docker/LXC to make it harder to break container isolation.
While writting software in a right way seems to be right thing to do, the world is a terrible imperfect place. In my opinion it's better to assume what you run bad programs on bad OS on bad hardware (and find the ways to workaround it) than try to make everything you touch unbuggy and perfect.
Though it's perfectly fine and good to use grsecurity/PaX-enabled kernel. Just don't rely on it as one and only security measure.
Let's think about virtualization for a moment: why do we need containers when we already have much more robust KVM/XEN/VirtualBox hypervisors? The answer is one word: overhead. You just can't run dozens of KVM guests on an average desktop box while there could be hundreds of containers without much troubles.
Even more, how do you plan to support/upgrade/fix operating systems in all of your guests? If you eventually come with the Vagrant & Puppet/Chef it's still a lof of hard work. And I don't think what anyone will be excited to spend so much effort just into single desktop.
Qubes OS tries to solve both of this problems though it's still very expiremental and you can't install it into your current system (it's separate Linux distribution). Although I don't know much details about implementation (e.g. how do they solve memory overhead because deduplication seems to be disabled) I think this is very promising OS and definetely going to investigate into it further.
Possible security flaws (see also TODO section):
Summing it up: though as for now implementation is far from ideal it should be more trust-worthy in near future. And theoretically breakable sandbox is much better than no isolation at all.
TODO: Graphical overview.
Docker flaws:
Seems like choice of Docker was poor: they haven't improved security since the 1.0 release and probably won't do it in near future. There are few new projects in lightweight container area like rkt, LXD, systemd-nspawn and they should be considered instead of Docker. See also this issue for additional info.
Install the tmux, Xephyr and Docker.
Create user kagome
and /home/kagome
directory, add it to the docker
group:
$ useradd kagome -s /bin/false -m -k /dev/null
$ chown user:user /home/kagome/
$ gpasswd -a kagome docker
$ git clone https://github.com/Kagami/kagome.git && cd kagome
$ cp scripts/* /usr/local/bin/
$ visudo
...
user ALL=(kagome) NOPASSWD: /usr/local/bin/docker-run
user ALL=(kagome) NOPASSWD: /usr/bin/docker build *
user ALL=(kagome) NOPASSWD: /usr/bin/docker images
user ALL=(kagome) NOPASSWD: /usr/bin/docker pull *
user ALL=(kagome) NOPASSWD: /usr/bin/docker rmi *
user ALL=(kagome) NOPASSWD: /usr/bin/docker rm *
...
Go to the images
dir, fix Dockerfiles for your needs, build images with make image1 image2 ...
(don't forget to pull needed base images with docker pull
, e.g. docker pull ubuntu:latest
).
Create /etc/conf.d
directory, config for your first containerized application and symlink kagome-gui
script to make runnable:
$ mkdir -p /home/kagome/home/firefox/
$ mkdir /etc/conf.d/
$ cat >/etc/conf.d/firefox-home <<EOF
IMAGE=gui-nonfree
APP=firefox
MOUNTS=/home/kagome/home/firefox:/home/user/.mozilla
SOUND=y
EOF
$ ln -s /usr/local/bin/kagome-gui /usr/local/bin/firefox-home
firefox-home
from you main user inside the X session and enjoy!TODO: Write human-friendly CLI utility for managing containers configs.
kagome
utilitykagome - application cage
Written in 2014 by Kagami Hiiragi [email protected]
To the extent possible under law, the author(s) have dedicated all copyright and related and neighboring rights to this software to the public domain worldwide. This software is distributed without any warranty.
You should have received a copy of the CC0 Public Domain Dedication along with this software. If not, see http://creativecommons.org/publicdomain/zero/1.0/.