Running GUI apps with Docker(fabiorehm.com)
fabiorehm.com
Running GUI apps with Docker
http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/
11 comments
[deleted]
FYI, Fábio Rehm is also the author of the great LXC provider for Vagrant[1], which I sucessfully use for fun and profit almost every working day.
PS: I you like Fábio's work, consider tipping him[2] (I already did, with bitcoins! :)
[1]: https://github.com/fgrehm/vagrant-lxc
[2]: https://gratipay.com/fgrehm/
PS: I you like Fábio's work, consider tipping him[2] (I already did, with bitcoins! :)
[1]: https://github.com/fgrehm/vagrant-lxc
[2]: https://gratipay.com/fgrehm/
Share your X11 socket/cookie, and now everything you input (keyboard/mouse,etc.) is readable by a so called "contained" application; this is not a secure solution, but more of a comfort solution, and it should be used as such.
On a side note, I've been doing this with chroot/debootstrap for years, but lxc/docker provide a nice "engineered" solution.
On a side note, I've been doing this with chroot/debootstrap for years, but lxc/docker provide a nice "engineered" solution.
While I think this is cool, could someone explain to me why I'd bother using a docker setup over let's say a... traditional VM? And I don't need justification for using containers on a server, that makes sense... on a desktop though something just seems off.
Seems like there's little to gain and a lot to configure/worry about with the Docker setup. Happy to be learned somethin' ... just would like to know what that somethin' is.
Seems like there's little to gain and a lot to configure/worry about with the Docker setup. Happy to be learned somethin' ... just would like to know what that somethin' is.
There are a couple reasons I can think of:
* You can run different versions of program side-by-side: FF 32 in one window, and FF 31 in another to test compatibility and regression.
* You can install programs without polluting your base system. I don't want to have Java installed, but sometimes I just need to run an applet.
All of that can be achieved with traditional VM, but with the performance penalty. As Docker runs on top of the native kernel, speed should be comparable to the application running directly on host.
* You can run different versions of program side-by-side: FF 32 in one window, and FF 31 in another to test compatibility and regression.
* You can install programs without polluting your base system. I don't want to have Java installed, but sometimes I just need to run an applet.
All of that can be achieved with traditional VM, but with the performance penalty. As Docker runs on top of the native kernel, speed should be comparable to the application running directly on host.
My guesses are speed - not that relevant if you are interacting with an app that is waiting for user input - and memory usage.
In a traditional VM, you have to reserve memory that is used by the guest OS and the apps you want to run, and is unavailable as soon as the VM comes up.
Docker is incredibly lightweight in comparison. Also, you can move your development environment around, same way you would move a VM disk around. That requires less resources, again, as there is no OS install.
In a traditional VM, you have to reserve memory that is used by the guest OS and the apps you want to run, and is unavailable as soon as the VM comes up.
Docker is incredibly lightweight in comparison. Also, you can move your development environment around, same way you would move a VM disk around. That requires less resources, again, as there is no OS install.
If it's helpful to anyone else, I used X virtual frame buffer with VNC to do something similar earlier this year https://github.com/clifton/docker-ib-gateway
humm, the sudo makes me shudder.
Why? It's being run inside the docker container, it should be ok.
Docker "isolation" is not as strong as most hipsters think. :-)
Interesting, any links which expand on the issues?
Docker is based on Linux namespaces.
The first thing which comes to mind is that Docker does not use user namespaces. Hence, the root within Docker is the same root as on the host side. Of course Docker papers over the issue by using apparmor and other tricks but this does not cure the issue itself.
Linux containers (LXC, libvirt-lxc, Docker) are shared kernel visualization. Every single kernel vulnerability will hit you hard.
In contrast to LXC and libvirt-lxc Docker lets you configure a lot of insane setups which are not secure. (But easy to setup) Also keep in mind resource issues. If you setup your container in a wrong way it my eat all your available file descriptors, all memory, etc... (Because it is shared kernel)
Let's face it, the whole technology was not designed for sandboxing, more for easy deployment of applications.
That said, I really love container and use them a lot in production with libvirt-lxc. But I don't use them for sandboxing.
Linux containers (LXC, libvirt-lxc, Docker) are shared kernel visualization. Every single kernel vulnerability will hit you hard.
In contrast to LXC and libvirt-lxc Docker lets you configure a lot of insane setups which are not secure. (But easy to setup) Also keep in mind resource issues. If you setup your container in a wrong way it my eat all your available file descriptors, all memory, etc... (Because it is shared kernel)
Let's face it, the whole technology was not designed for sandboxing, more for easy deployment of applications.
That said, I really love container and use them a lot in production with libvirt-lxc. But I don't use them for sandboxing.
This is the first that comes to mind:
http://blog.bofh.it/debian/id_413
http://blog.bofh.it/debian/id_413
That's an article from 2011. This evasion does not work today.
That example is old, but yes it does work, and will continue to work until docker uses user namespaces.
That said the example is not a good one because of the changes applied these days, e.g. the use of the UID on the host-side.
That said the example is not a good one because of the changes applied these days, e.g. the use of the UID on the host-side.
I actually tried it on Docker 1.2.0 with the ubuntu:14.04 image.
/sys is already mounted and it is read-only, and it cannot be mounted manually:
/sys is already mounted and it is read-only, and it cannot be mounted manually:
root@07ba8c752195:/# mkdir sys2
root@07ba8c752195:/# mount -t sysfs sysfs /sys2
mount: block device sysfs is write-protected, mounting read-only
mount: cannot mount block device sysfs read-onlyBTW: Just one example of a typical Linux namespace vulnerability:
http://git.kernel.org/cgit/linux/kernel/git/ebiederm/user-na...
I tested this with the busybox image, and received a warning that /sys was already mounted, but the attack then proceded to work as expected.
kalmi@sylph ~> docker run -t -i busybox:latest
/ # mount -t sysfs sysfs /sys
mount: permission denied (are you root?)
/ # mkdir sys2
/ # mount -t sysfs sysfs /sys2
mount: mounting sysfs on /sys2 failed: Permission denied
kalmi@sylph ~> docker --version
Docker version 1.2.0, build fa7b24f
kalmi@sylph ~> uname -r
Linux sylph 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/LinuxWe don't need to argue about this, but I see the same permission-denied issue as you, but that doesn't matter.
The /sys is mounted already and reading/writing to it succeeds:
The /sys is mounted already and reading/writing to it succeeds:
/ # mount -t sysfs sysfs /sys
mount: permission denied (are you root?)
/ # echo /var/lib/docker/aufs/mnt/638ae26bb710384a8ebade3a66049277affea8b0f3e96003d351f167a9706aef/tmp/evil-helper > /sys/kernel/uevent_helper
/ # cat /sys/kernel/uevent_helper
/var/lib/docker/aufs/mnt/638ae26bb710384a8ebade3a66049277affea8b0f3e96003d351f167a906aef/tmp/evil-helper
A lot developing in this space. Will have more to talk about soon :)
Firejail anyone?
http://l3net.wordpress.com/projects/firejail/
http://l3net.wordpress.com/projects/firejail/
Are there still problems with apps that require the initialization system. I never was able to get things like dbus working in Docker.
Does OpenGL work with this?
Nice... previously I'd just installed vnc.
Noob here. What are the possible usecases?
Skype, for example, can be run inside a container [1], allowing you to use it while hiding the rest of your system from the obfuscated and traffic-encrypted binary which no one knows what it does to your system.
It uses X11 forwarding for the GUI, and PulseAudio for the sound.
[1] - https://registry.hub.docker.com/u/tomparys/skype/
It uses X11 forwarding for the GUI, and PulseAudio for the sound.
[1] - https://registry.hub.docker.com/u/tomparys/skype/
Also Skype has been caught reading the UNIX passwd file and your firefox profile:
http://linux.slashdot.org/story/07/08/26/1312256/skype-linux...
The thing that made me finally uninstall it (from everything) is when my phone OS (MIUI) informed me that Skype wanted to suddenly take a photo of me even though I hadn't touched the app for days.
http://linux.slashdot.org/story/07/08/26/1312256/skype-linux...
The thing that made me finally uninstall it (from everything) is when my phone OS (MIUI) informed me that Skype wanted to suddenly take a photo of me even though I hadn't touched the app for days.
This Skype use case really interests me a lot, as I have to use it professionally and do not trust this application at all and would like to limit it to a bare minimum: microphone, webcam, screen and one single folder for file exchange.
I never tried Docker, but I wonder, if this requirements can be achieved with SeLinux or AppArmor as they are supported by many distributions and are around longer than Docker?
Would be great to be able to tighten the corset around any non open-source application, to make sure it is not siphoning data.
I never tried Docker, but I wonder, if this requirements can be achieved with SeLinux or AppArmor as they are supported by many distributions and are around longer than Docker?
Would be great to be able to tighten the corset around any non open-source application, to make sure it is not siphoning data.
I'll note that X11 has practically no security and that windows can read contents from other windows, if you happen to be worried about that attack. Essentially, anything that is displayed can be read by anything.
You'd need some form of "X11 firewall" to be secure.
You'd need some form of "X11 firewall" to be secure.
Untrusted SSH X-forwarding (via -X) is a start.
Just guessing - internet explorer under wine.
Automated testing of native clients could leverage this.
Might I assume that the approach in the article gives processes in the container full access to one's X11 session and contents?
[1]: SSH X11 forwarding