Running graphics-accelerated GUI apps in LXD containers on a Ubuntu desktop(blog.simos.info)
blog.simos.info
Running graphics-accelerated GUI apps in LXD containers on a Ubuntu desktop
https://blog.simos.info/how-to-easily-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/
20 comments
BTW, +1 for Simos' blog, especially his series of Ubuntu+LXD+HAProxy (with SSL termination and host based ACLs) +ZFS, etc, etc. All really good stuff, easy to follow and setup, and IMO, even though over the years LXC has lost some of its gluster to Docker, the combination of LXD/HAProxy is actually a simpler and superior way method in a lot of use cases than Docker, et al.
How secure is this (when also running the GUI using Xephr)? Compared to say running Virtual Box VMs or Quebes or LXD virtual machines?
EDITED in response to a comment.
EDITED in response to a comment.
Answering the updated question regarding the security of running what is described in the post, but using Xephyr and not the desktop's existing X11 session.
It is as secure as the individual components, that is whether there are security vulnerabilities in LXD, and in Xephyr. There are currently no pending security vulnerabilities to fix in either (as far as I know).
Of course, the same goes with VirtualBox. It is as secure as there are no pending known security vulnerabilities (https://www.techrepublic.com/article/10-new-vm-escape-vulner...).
It is as secure as the individual components, that is whether there are security vulnerabilities in LXD, and in Xephyr. There are currently no pending security vulnerabilities to fix in either (as far as I know).
Of course, the same goes with VirtualBox. It is as secure as there are no pending known security vulnerabilities (https://www.techrepublic.com/article/10-new-vm-escape-vulner...).
So including Xephyr this is a reasonable way to sandbox a browser? To the same level of reasonable as browsing in any virtual machine is.
Is this sort of thing possible with Wayland? If so does Wayland already enforce the necessary process isolation or does something like Xephr for Wayland need to be developed first?
Is this sort of thing possible with Wayland? If so does Wayland already enforce the necessary process isolation or does something like Xephr for Wayland need to be developed first?
The X11 protocol has been around several decades. The Wayland protocol has been around several years. There are more tools available for X11 and it's used extensively in all distributions. Even in those that are based on Wayland, those have XWayland as well meaning that X11 works there as well.
Gradually, the Linux desktop will be moving towards Wayland and it's a good thing that this happens.
Xephyr is the appropriate tool for what we do (it's a display server for the X11 protocol, can reuse the acceleration of the desktop). There are equivalent tools for Wayland, it's just not required yet. It is possible though to do these things with Wayland as well and probably there is already a tool that I am not aware of.
There is already process isolation with the containers. The lingering issue is with the graphical output on either X11 or Wayland. That needs some extra care. With X11, choice is Xephyr. With Wayland, there should be something equivalent and is probably simpler.
In terms of security of Xephyr, there is an issue. It is a tool that is not used very much and may have some unreported security vulnerabilities. But the same goes with qemu, the hardware emulator. qemu is big and has too much functionality which makes it likely to have yet unreported security vulnerabilities. Have a look at https://cloudplatform.googleblog.com/2017/01/7-ways-we-harde... which specifically mentions the risk in points 2 and 3.
Nevertheless, it should be very important to also implement an option of using Xephyr as part of the application isolation efforts.
Xephyr is the appropriate tool for what we do (it's a display server for the X11 protocol, can reuse the acceleration of the desktop). There are equivalent tools for Wayland, it's just not required yet. It is possible though to do these things with Wayland as well and probably there is already a tool that I am not aware of.
There is already process isolation with the containers. The lingering issue is with the graphical output on either X11 or Wayland. That needs some extra care. With X11, choice is Xephyr. With Wayland, there should be something equivalent and is probably simpler.
In terms of security of Xephyr, there is an issue. It is a tool that is not used very much and may have some unreported security vulnerabilities. But the same goes with qemu, the hardware emulator. qemu is big and has too much functionality which makes it likely to have yet unreported security vulnerabilities. Have a look at https://cloudplatform.googleblog.com/2017/01/7-ways-we-harde... which specifically mentions the risk in points 2 and 3.
Nevertheless, it should be very important to also implement an option of using Xephyr as part of the application isolation efforts.
This is a convenience tool, that uses your existing X11 session. You would not use it when testing malicious programs because they would be able to attack the X11 session (but not your host's filesystem).
If you want to test programs that might be malicious, then you would set up a separate X11 server like Xephyr and get the output to get directed over there. In that way, both the filesystem and X11 session would be separate from those of your host.
I mention the use of Xephyr in the Conclusions of the post. There is some new functionality in LXD that is being released soon that will make it very easy to use Xephyr as well.
If you want to test programs that might be malicious, then you would set up a separate X11 server like Xephyr and get the output to get directed over there. In that way, both the filesystem and X11 session would be separate from those of your host.
I mention the use of Xephyr in the Conclusions of the post. There is some new functionality in LXD that is being released soon that will make it very easy to use Xephyr as well.
I'm going to edit my original question in light of this comment.
This all uses only "unprivileged" containers NOT "privileged" container.. so "root" in the container is NOT "root" in the Host!
You might also try vagrant-lxc (https://github.com/fgrehm/vagrant-lxc/blob/master/README.md). Can give you some ruby dependency hell, though.
Another alternative is lxdock (https://github.com/lxdock/lxdock), which uses LXD directly without dependency issues. The X11 support similar to what's done on this post is in a PR that I wrote.
Can be useful for running older games that don't work on modern distros anymore.
I didn't quite get why snap is needed in the above case. Doesn't lxd itself already offer sandboxing?
For Wine, something like snap / flatpak can be useful to get that sandboxing without running a full blown container.
I didn't quite get why snap is needed in the above case. Doesn't lxd itself already offer sandboxing?
For Wine, something like snap / flatpak can be useful to get that sandboxing without running a full blown container.
There are two steps to set up your LXD installation in order to create GUI containers.
If you are using the snap package of LXD, you only need to perform the second step.
If you are using the deb package of LXD, you need to perform both steps.
A snap package of LXD is not required to setup GUI containers, it just makes it a bit simpler (one step instead of two).
If there is some Windows application that is really useful to have on Linux, then it makes sense to invest the effort to create a snap package. The snap package will be usable to everyone. There are already Windows games that have been packaged as snaps, and the process could be replicated with some effort (example: https://github.com/snapcrafters/tmnationsforever).
The GUI container instead, is helpful if there is an application that you would like to run but cannot invest the effort to package it as a snap.
If you are using the snap package of LXD, you only need to perform the second step.
If you are using the deb package of LXD, you need to perform both steps.
A snap package of LXD is not required to setup GUI containers, it just makes it a bit simpler (one step instead of two).
If there is some Windows application that is really useful to have on Linux, then it makes sense to invest the effort to create a snap package. The snap package will be usable to everyone. There are already Windows games that have been packaged as snaps, and the process could be replicated with some effort (example: https://github.com/snapcrafters/tmnationsforever).
The GUI container instead, is helpful if there is an application that you would like to run but cannot invest the effort to package it as a snap.
Snap / Flatpak help with providing Wine configuration, but you can't pre-package stuff that's not open source for instance.
For example you buy some game on GOG, then something like pre-configured Snap / Flatpak or PlayOnLinux / Lutris scripts can help automating configuration but you still need to provide the installer to them first.
One problem that I personally encountered with that approach is that someone has to maintain those scripts. They tend to become obsolete, since Wine is changing and things are moving forward, while the amount of such games is potentially quite huge and there are not enough maintainers to update them all.
In the end it's just easier to install stuff yourself in a new prefix. Sandboxing though is a neat feature which you can use even without relying on such pre-made scripts.
For example you buy some game on GOG, then something like pre-configured Snap / Flatpak or PlayOnLinux / Lutris scripts can help automating configuration but you still need to provide the installer to them first.
One problem that I personally encountered with that approach is that someone has to maintain those scripts. They tend to become obsolete, since Wine is changing and things are moving forward, while the amount of such games is potentially quite huge and there are not enough maintainers to update them all.
In the end it's just easier to install stuff yourself in a new prefix. Sandboxing though is a neat feature which you can use even without relying on such pre-made scripts.
Sandboxing (snap or flatpack) is more fragile than running the application in a GUI container. If you do not grant a permission, the application will fail. You will get to know about these issues from bug reports.
With a GUI LXD container, you can set up Wine as best as possible, then take a snapshot of the container in its pristine condition. Then, you can install Windows programs in the same container, or clone the original container and install each in a separate container. Each action takes only a few seconds compared to what you would get with Virtualbox.
With a GUI LXD container, you can set up Wine as best as possible, then take a snapshot of the container in its pristine condition. Then, you can install Windows programs in the same container, or clone the original container and install each in a separate container. Each action takes only a few seconds compared to what you would get with Virtualbox.
Sure, containers should be better for sandboxing.
> Each action takes only a few seconds compared to what you would get with Virtualbox.
For VMs, I'm usually using Qemu/KVM with virtual-manager when needed, not VirtualBox (usually running Linux guest on Linux host). It has better integration and hardware support like USB redirection, and now there is also virgl acceleration catching up to OpenGL and Vulkan.
> Each action takes only a few seconds compared to what you would get with Virtualbox.
For VMs, I'm usually using Qemu/KVM with virtual-manager when needed, not VirtualBox (usually running Linux guest on Linux host). It has better integration and hardware support like USB redirection, and now there is also virgl acceleration catching up to OpenGL and Vulkan.
Here is an article on how they do it, https://blog.simos.info/a-closer-look-at-chrome-os-using-lxd...