
Running graphics-accelerated GUI apps in LXD containers on a Ubuntu desktop - simosx
https://blog.simos.info/how-to-easily-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/
======
simosx
As a sidenote, Chrome OS uses LXD in a similar way to run Linux GUI
applications like the terminal application they showed in Google I/O 2018.

Here is an article on how they do it, [https://blog.simos.info/a-closer-look-
at-chrome-os-using-lxd...](https://blog.simos.info/a-closer-look-at-chrome-os-
using-lxd-to-run-linux-gui-apps-project-crostini/)

------
indigodaddy
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.

------
asfdsfggtfd
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.

~~~
simosx
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...](https://www.techrepublic.com/article/10-new-vm-escape-
vulnerabilities-discovered-in-virtualbox/)).

~~~
asfdsfggtfd
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?

~~~
simosx
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...](https://cloudplatform.googleblog.com/2017/01/7-ways-we-harden-our-
KVM-hypervisor-at-Google-Cloud-security-in-plaintext.html) 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.

------
bmullan
Simos I just tried this on Ubuntu 18.04 and it worked great!!

Started Firefox in an LXD container created w your customized "profile" went
to YouTube a was playing music videos great... All from the LXD container.

Really great work making this so easy now.

~~~
simosx
Thanks!

------
mkesper
You might also try vagrant-lxc ([https://github.com/fgrehm/vagrant-
lxc/blob/master/README.md](https://github.com/fgrehm/vagrant-
lxc/blob/master/README.md)). Can give you some ruby dependency hell, though.

~~~
pwnna
Another alternative is lxdock
([https://github.com/lxdock/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.

------
shmerl
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.

~~~
simosx
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](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.

~~~
shmerl
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.

~~~
simosx
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.

~~~
shmerl
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.

------
enteroo
Anyone managed to get this to work?

~~~
bmullan
I just did and it worked great !

Super easy as using the custom "profle" meant I really had to do nothing other
than the single cmd to create the LXD container.. which took 15-20 seconds to
create.

