Running the Xserver in a container

[metux]

Hello folks,

anybody where who's running the Xserver within containers / jail / chroot ?
The testing ground has (limited) ability to do so, but it's just for pure testing purpose there.

I wonder whether it makes sense offering a container or chroot build (plus a bit of startup script) that can be deployed independent of individual distro.

What are your thoughts on that ?

[metux]

@callmetango

[callmetango]

@metux In general a very good idea! Especially for testing other architectures than amd64.

I made a small POC running some distribution provided Xorg Xserver with XFCE in QEMU and it worked very well with the modesetting driver on QEMU's standard VGA emulation and KVM acceleration. Only Chromium and Firefox completly crashed QEMU even when given loads of RAM. I think this could to be related to missing graphics acceleration like OpenGL/VirGL etc.

My next step is to bring in the "real thing" 😉 by compiling it and make it work too. I'll report back once I've done so.

Some additional goodies were to make the VMware driver work for basic acceleration and add some SPICE there too. Using network bridging it should even be possible to use the builtin network transparency feature to run xclock/xeyes/... or any other X program on the host and have it rendered on the guest's XLibre Xserver, shouldn't it?

[callmetango]

As promised, I have been working on containerizing a Linux distribution in qemu. There is a guide how to do this at XLiberating Alpine Linux · X11Libre · Discussion #290.

[metux]

cool :)

[Tautvydas411]

Tangential and a lot of extra effort: What about offering static build - everything in single executable ?

[metux]

Tangential and a lot of extra effort:

Already have most pieces in the testing ground. Yet missing is storing the final chroot tree as a OCI image.
Plus some startup script with a bit trickery (eg. bind-mount udev state dir, etc, grant device permissons, etc)

What about offering static build - everything in single executable ?

Not so easy for various reasons, eg. we'd first make sure that all of the dependencies can be built as static archives, and the driver loader still works (drivers are still external repos and have to be shared objects). And finally still depending on dynamically linked glibc (on most Linux'es at least).

[callmetango]

I just stumbled upon mviereck/x11docker: Run GUI applications and desktops in docker and podman containers. Focus on security. and according to the README this could be interesting in this context. Sure, they use the "wrong" 😉 X server but still...

[Frontrider]

What about offering static build - everything in single executable ?

Not so easy for various reasons, eg. we'd first make sure that all of the dependencies can be built as static archives, and the driver loader still works (drivers are still external repos and have to be shared objects). And finally still depending on dynamically linked glibc (on most Linux'es at least).

I just stumbled upon mviereck/x11docker: Run GUI applications and desktops in docker and podman containers. Focus on security. and according to the README this could be interesting in this context. Sure, they use the "wrong" 😉 X server but still...

The most relevant bit in my opinion is packing the applications that want x11 into a sandboxed/isolated environment. I'd prefer docker/oci containers for that over flatpak, as it is more widespread (it is not desktop only, plus has better security out of the box) so we get better support for it.

Not gonna say that "running the xserver in a container does not matter", but running the application itself in a container matters more, and using the host's xserver is a good way to do that.
IF you have a framework that can properly expose all needed resources from the host and interact with new namespaces out of the box for improved security (IF it can limit the older x11 client that does not expect that extension), then running the server in a container is just a nice to have imo.

I'd also say that this tech is one of the best tools to preserve 30+ years of software that we can not patch anymore. (No, not even updating wine is a solution because some software does not run under newer wine versions)

[b-aaz]

IDK if this counts as running an X server in a container but I think it was worth mentioning
I use the Xephyr nested server to connect to my isolated GUI jails on FreeBSD.

An secondary, empty X11 socket directory is mounted through a readonly nullfs mount from a folder on the host to the /tmp/.X11-unix/ of the jail.
Then the Xephyr socket on the host's /tmp/.X11-unix/ is symlinked to the jail's /tmp/.X11-unix/X0.
This way the jail works as if it was accessing the DISPLAY number :0.

The only thing that does not work in this setup is HW acceleration, because Xephyr can not use the hosts acceleration capabilities, but that is not really a issue for me because I do not need acceleration.
It would be nice if we could maybe "pipe" the hosts GLX ... .

[DtxdF]

Hi @b-aaz

I have implemented a new subcommand in AppJail to run x11 applications with MIT-MAGIC-COOKIE-1 authentication already configured, so with this feature we can run x11 applications in jails, or in other words, in an isolated environment, even if we share /tmp/. X11-unix as I do below (although the directory is nullfs mounted as read-only). Before this change, I used xpra for both VMs and jails, but since I wanted a lightweight alternative to xpra, I implemented this feature, so now I only use xpra for VMs, such as the one I use to run Obsidian.

Example: https://github.com/DtxdF/x11appjail/tree/main/badwolf

x11appjail-2026-02-03_17.38.48.mp4

I think both xpra and Xephyr+containers have advantages and disadvantages. I think xpra offers a better user experience than any other similar tool for running applications as if they were local. I'm not just talking about painting the window with the application, but also synchronizing the clipboard, microphone, file transfer, etc., but of course, from a security standpoint, this may not be very good. The good thing is that xpra subsystems can be disabled when they are not really needed. The main drawback is that it is a bit slow and, being Python, it can install many dependencies when running inside a jail. This is where Xephyr stands out.

From a security perspective, xpra may have a larger attack surface compared to Xephyr due to the numerous subsystems it depends on. However, I found this document describing an old vulnerability in Xorg, which states the following:

”sandbox -X” utility creates an environment for executing untrusted GUI applications. For each application A, an instance of Xorg server (more precisely, Xephyr) is run; A is confined by SELinux, and can talk only to its Xephyr server.
The latter connects to a ”real” X server to display A’s output.
Using the vulnerability described above, a malicious application can execute arbitrary code in the context of the Xephyr server, and then escalate to root by attacking the ”real” Xorg server that Xephyr is allowed to talk to. As a result, the whole mechanism of ”sandbox -X” is defeated.

Of course, I accept that there is no bulletproof solution (although QubeOS excels in this regard for security reasons), but at least with Xephyr+containers or xpra, it is decently isolated, and it is likely that a bad configuration or vulnerability will ruin everything.

Maybe you folks find the following articles interesting:

• https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
• https://danwalsh.livejournal.com/31146.html?es=1
• https://doc.qubes-os.org/en/latest/developer/system/gui.html

The only thing that does not work in this setup is HW acceleration, because Xephyr can not use the hosts acceleration capabilities, but that is not really a issue for me because I do not need acceleration. It would be nice if we could maybe "pipe" the hosts GLX ... .

See the following:

• https://wiki.archlinux.org/title/VirtualGL
• https://www.youtube.com/watch?v=fhKoZedyhHc