A new print-css.rocks release is available with support for some new tools: Typeset.sh
If you are member of the UNIX 'docker' must be considered harmful. Being member of the 'docker' group is not unusual because it gives you the right to build and execute containers as normal user but it also gives you full root access rights which I consider as a major security issue and a broken-by-design feature.
By default I can not access /etc/shadow because it is only readable by root or group wheel:
ajung@demo:~$ who am i
ajung pts/2 Feb 5 07:03
ajung@demo:~$ ls -la /etc/shadow
-rw-r----- 1 root shadow 897 Jan 25 10:05 /etc/shadow
ajung@demo:~$ cat /etc/shadow
cat: /etc/shadow: Permission denied
Now I create a simple Docker image that exposes /data as mount point for a volume
Now I can start the container and attach any local filesystem to the container and access it with full root rights.
In this case I can easily access the content of the formerly protected /etc/shadow file
ajung@demo:~$ docker run -v /etc:/data zopyx/test cat /data/shadow
I can also create content on a root filesystem as standard user
ajung@demo:~$ docker run -v /etc:/data zopyx/test touch /data/hello-world.txt
ajung@demo:~$ ls -la /etc/hello-world.txt
-rw-r--r-- 1 root root 0 Feb 5 07:36 /etc/hello-world.txt
The whole Docker security concept (is there a security concept?) appears completely broken.
So user accounts belonging to the UNIX group 'docker' are fully exploitable. Standard UNIX users can gain elevated rights on the local machine if they belong to the 'docker' group and can perhaps exploit other machines as well by tampering SSH keys etc....many attack vectors are possible.
Update (2015-02-05, 16:00 UTC)
The discovered behavior is in fact intentional and documented in the Docker security documentation. The first sentence is already completely broken.
"Only trusted users should be allowed to control your Docker daemon"
Building a secure IT system on human trust is fundamentally broken. A secure system must be build on the best technology practices. A human is always a weak factor when it comes to security.
Another point: the default security policy (if there is one?) is: everything is allowed, you are root, dropping the priviledges as needed is up to you. Complete improper approach. A secure system must be as closed as possible by default and give the container only the rights and capabilities that it really needs.
And yet another point: as standard user it is by design not possible to gain root permissions (except using sudo). The problem once again arises from the 'docker' group being practically root. An attacker might get hold of my SSH keys and login into a dockerized box. With the described attach vector an intruder has an easy game getting through Docker. The preassumption "Only trusted users should be allowed to control your Docker daemon" is therefore just wrong and the security concept of Docker is broken.
Docker leaves security to the user and administrators instead of providing a secure way for building secure containers for deployment. Instead Docker should be better compared to a rootkit generator.