[GH-ISSUE #998] gui isolation through wayland

gitea-mirror commented

2026-05-05 06:26:00 -06:00

Owner

Originally created by @valoq on GitHub (Dec 23, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/998

Since the X11 protocol does not have any isolation between clients, all client application can e.g. see the input actions of each other, allowing keylogging and so on.

However the new wayland protocol does isolate clients from each other. Some applications like evince already have native wayland support.
For others there is Xwayland, which is basically a xorg-server that allows to run x application with wayland.

While testing the wayland implementation weston, which can be run inside X11 as well, I notice each weston instance uses its own xwayland server.

When running xinput, keylogging is possible for X11 applications of the same weston instance, but not for applications in other weston instances or the native Xorg-server (if weston is run within a X11 session). This is probably because X11 applications started inside weston, have their own X11-server (Xwayland :1, Xwayland :2 ... )

I have not yet found a way to effectively run single applications that way without starting the weston window manager, but it should be possible. (xweston provides a small script to run weston without the actual window-manager, allowing other X11 window manager to use Xwayland)

Using wayland/weston and the Xwayland server in this way it might provied an additional way to sandbox X11 applications via the --x11 option.

The tests I have done so far show that using weston is way faster (no noticeable wait time at all) and more reliable then xpra (which takes a couple of seconds to start and has some other issues).

Things like copying between applications using different window server is not possible however.
But the primary goal of --X11 is isolation and that can be archived with this approach.

Originally created by @valoq on GitHub (Dec 23, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/998 Since the X11 protocol does not have any isolation between clients, all client application can e.g. see the input actions of each other, allowing keylogging and so on. However the new wayland protocol does isolate clients from each other. Some applications like evince already have native wayland support. For others there is Xwayland, which is basically a xorg-server that allows to run x application with wayland. While testing the wayland implementation weston, which can be run inside X11 as well, I notice each weston instance uses its own xwayland server. When running xinput, keylogging is possible for X11 applications of the same weston instance, but not for applications in other weston instances or the native Xorg-server (if weston is run within a X11 session). This is probably because X11 applications started inside weston, have their own X11-server (Xwayland :1, Xwayland :2 ... ) I have not yet found a way to effectively run single applications that way without starting the weston window manager, but it should be possible. (xweston provides a small script to run weston without the actual window-manager, allowing other X11 window manager to use Xwayland) Using wayland/weston and the Xwayland server in this way it might provied an additional way to sandbox X11 applications via the --x11 option. The tests I have done so far show that using weston is way faster (no noticeable wait time at all) and more reliable then xpra (which takes a couple of seconds to start and has some other issues). Things like copying between applications using different window server is not possible however. But the primary goal of --X11 is isolation and that can be archived with this approach.

gitea-mirror

2026-05-05 06:26:00 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:26:06 -06:00

Author

Owner

@xahare commented on GitHub (Dec 24, 2016):

had to use 'wayland --modules=xwayland.so' to get it to make different x servers, but thats probably distro dependent.

when wayland has that module loaded, any app can see the clipboard by calling xsel -b even if the data hit that clipboard from a weston app. --x11=none for all weston only apps should fix that. need to try it.

i think wayland needs an x server thats not implemented as a module, but as a normal wayland client so it cant see the clipboard until its given to it like all other clients. then firejail could use this.

@xahare commented on GitHub (Dec 24, 2016): had to use 'wayland --modules=xwayland.so' to get it to make different x servers, but thats probably distro dependent. when wayland has that module loaded, any app can see the clipboard by calling xsel -b even if the data hit that clipboard from a weston app. --x11=none for all weston only apps should fix that. need to try it. i think wayland needs an x server thats not implemented as a module, but as a normal wayland client so it cant see the clipboard until its given to it like all other clients. then firejail could use this.

gitea-mirror commented

2026-05-05 06:26:08 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 27, 2016):

My understanding is wayland will solve all problems by default, so when you run "firejail firefox" under wayland, you should already have all possible x11 protection. I am still to try wayland, we'll see how is going.

@netblue30 commented on GitHub (Dec 27, 2016): My understanding is wayland will solve all problems by default, so when you run "firejail firefox" under wayland, you should already have all possible x11 protection. I am still to try wayland, we'll see how is going.

gitea-mirror commented

2026-05-05 06:26:10 -06:00

Author

Owner

@valoq commented on GitHub (Jan 4, 2017):

when wayland has that module loaded, any app can see the clipboard by calling xsel -b even if the data hit that clipboard from a weston app. --x11=none for all weston only apps should fix that. need to try it.

Thanks for the info.
However in many cases, access to the clipboard is wanted and while it is important to be able to block it, preventing access to the input of other applications seems to be the main concern.

Best case would be to be able to define the access direction of the clipboard.
Meaning that it would be possible to forbid an pdf viewer to read the clipboard but allow it to write to is so that text can be copied from a pdf file.

@valoq commented on GitHub (Jan 4, 2017): > when wayland has that module loaded, any app can see the clipboard by calling xsel -b even if the data hit that clipboard from a weston app. --x11=none for all weston only apps should fix that. need to try it. Thanks for the info. However in many cases, access to the clipboard is wanted and while it is important to be able to block it, preventing access to the input of other applications seems to be the main concern. Best case would be to be able to define the access direction of the clipboard. Meaning that it would be possible to forbid an pdf viewer to read the clipboard but allow it to write to is so that text can be copied from a pdf file.

gitea-mirror commented

2026-05-05 06:26:12 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 4, 2017):

What distro are you running? I've never seen wayland running.

@netblue30 commented on GitHub (Jan 4, 2017): What distro are you running? I've never seen wayland running.

gitea-mirror commented

2026-05-05 06:26:13 -06:00

Author

Owner

@xahare commented on GitHub (Jan 4, 2017):

hiding the clipboard allows for password managers and prevents accidental leaks. one side effect of waylands built in isolation is not being able to type into another application. as far as i know, only the compositor could do this, but i havent read the protocol spec yet. i doubt anyone would want to build their password manager into the compositor. (now that i think about this, starting to like the idea) the other way this could work is by wrapping your stuff into a virtual machine, with your password manager in another vm, which is how im doing it now. kvm and vmware both support wayland.

for wayland, im running fedora 25. its the only distro i know of actively supporting wayland, and most of the apps run through that. the big exception is web browsers. epiphany is the only one, but its not secure enough for the big scary internet (you cant turn off javascript, drive by downloads etc)

have not found a way to disable the xwayland module in mutter, gnomes compositor. as a module it sees all clipboard, but as just a wayland client, i dont think it would have this issue.

pureos, based on debian, has a version in development built on wayland.

@xahare commented on GitHub (Jan 4, 2017): hiding the clipboard allows for password managers and prevents accidental leaks. one side effect of waylands built in isolation is not being able to type into another application. as far as i know, only the compositor could do this, but i havent read the protocol spec yet. i doubt anyone would want to build their password manager into the compositor. (now that i think about this, starting to like the idea) the other way this could work is by wrapping your stuff into a virtual machine, with your password manager in another vm, which is how im doing it now. kvm and vmware both support wayland. for wayland, im running fedora 25. its the only distro i know of actively supporting wayland, and most of the apps run through that. the big exception is web browsers. epiphany is the only one, but its not secure enough for the big scary internet (you cant turn off javascript, drive by downloads etc) have not found a way to disable the xwayland module in mutter, gnomes compositor. as a module it sees all clipboard, but as just a wayland client, i dont think it would have this issue. pureos, based on debian, has a version in development built on wayland.

gitea-mirror commented

2026-05-05 06:26:14 -06:00

Author

Owner

@valoq commented on GitHub (Jan 5, 2017):

What distro are you running? I've never seen wayland running.

The reference implementation of wayland is weston. I believe Ubuntu Gnome 16.10 uses wayland it by default as well.

@valoq commented on GitHub (Jan 5, 2017): > What distro are you running? I've never seen wayland running. The reference implementation of wayland is weston. I believe Ubuntu Gnome 16.10 uses wayland it by default as well.

gitea-mirror commented

2026-05-05 06:26:17 -06:00

Author

Owner

@faern commented on GitHub (Dec 29, 2020):

A long time has passed since this issue was closed. Is it still not possible to isolate X11 programs from each other by making use of XWayland in the jails? I'm trying to run a Wayland native machine with XWayland disabled. So I was hoping to jail the few X11 programs I need until they get native support. --x11=xwayland would be such a nice thing if it did work.

I guess my other solution is a VM + waypipe. But that obviously has a bunch of downsides when I want to share parts of the filesystem with the jail etc.

@faern commented on GitHub (Dec 29, 2020): A long time has passed since this issue was closed. Is it still not possible to isolate X11 programs from each other by making use of XWayland in the jails? I'm trying to run a Wayland native machine with XWayland **disabled**. So I was hoping to jail the few X11 programs I need until they get native support. `--x11=xwayland` would be such a nice thing if it did work. I guess my other solution is a VM + `waypipe`. But that obviously has a bunch of downsides when I want to share parts of the filesystem with the jail etc.

gitea-mirror commented

2026-05-05 06:26:20 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 29, 2020):

No, still no such option. However it looks like you can start Xwayland :2, start a window manager like openbox in it and the run firejail --env=DISPLAY=:2 x11onlyprogram.

@rusty-snake commented on GitHub (Dec 29, 2020): No, still no such option. However it looks like you can start `Xwayland :2`, start a window manager like openbox in it and the run `firejail --env=DISPLAY=:2 x11onlyprogram`.

gitea-mirror commented

2026-05-05 06:26:21 -06:00

Author

Owner

@faern commented on GitHub (Jan 3, 2021):

It sounds like a nice solution. But I can't get it to work. I have tried a few combinations, but basically running this:

$ Xwayland :2 -rootless
glamor: No eglstream capable devices found
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error:   Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
> Internal error:   Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server

$ DISPLAY=:2 openbox

$ firejail --env=DISPLAY=:2 xeyes

Gives me no new window to look at with eyes that follow my cursor. The three processes just sit there in silence. I'm not sure where it fails.

If I don't give -rootless to Xwayland I instead get this:

$ Xwayland :2
glamor: No eglstream capable devices found
missing wl_shell protocol
(EE)
Fatal server error:
(EE) Couldn't add screen
(EE)

@faern commented on GitHub (Jan 3, 2021): It sounds like a nice solution. But I can't get it to work. I have tried a few combinations, but basically running this: ``` $ Xwayland :2 -rootless glamor: No eglstream capable devices found The XKEYBOARD keymap compiler (xkbcomp) reports: > Internal error: Could not resolve keysym XF86FullScreen Errors from xkbcomp are not fatal to the X server The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Unsupported maximum keycode 569, clipping. > X11 cannot support keycodes above 255. > Internal error: Could not resolve keysym XF86FullScreen Errors from xkbcomp are not fatal to the X server ``` ``` $ DISPLAY=:2 openbox ``` ``` $ firejail --env=DISPLAY=:2 xeyes ``` Gives me no new window to look at with eyes that follow my cursor. The three processes just sit there in silence. I'm not sure where it fails. If I don't give `-rootless` to `Xwayland` I instead get this: ``` $ Xwayland :2 glamor: No eglstream capable devices found missing wl_shell protocol (EE) Fatal server error: (EE) Couldn't add screen (EE) ```

gitea-mirror commented

2026-05-05 06:26:23 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 3, 2021):

term1$ Xwayland :2    <---- same output as yours with -rootless
term2$ DISPLAY=:2 openbox   (not firejailed)
term3$ firejail --env=DISPLAY=:2 xeyes

Gives me the funny eyes in the Xwayland-window. (Fedora 32 Workstation)

@rusty-snake commented on GitHub (Jan 3, 2021): ``` term1$ Xwayland :2 <---- same output as yours with -rootless term2$ DISPLAY=:2 openbox (not firejailed) term3$ firejail --env=DISPLAY=:2 xeyes ``` Gives me the funny eyes in the Xwayland-window. (Fedora 32 Workstation)

gitea-mirror commented

2026-05-05 06:26:24 -06:00

Author

Owner

@faern commented on GitHub (Jan 3, 2021):

in the Xwayland-window

Which of the commands even give you this window? I don't have any window at all showing up from any of these commands. I'm running Fedora 33 workstation with Swaywm.

If I add debugging output to openbox I see this:

$ DISPLAY=:2 openbox --debug
Openbox-Debug: Failed to connect to session manager: SESSION_MANAGER environment variable not defined
Openbox-Debug: Monitor 0 @ 0,0 2560x1440

Openbox-Debug: Full desktop @ 0,0 2560x1440

Openbox-Debug: Moving to desktop 1
Openbox-Debug: not managing override redirect window 0x20020b

Openbox-Debug: UPDATE DESKTOP NAMES
Openbox-Debug: Managing window: 0x40000a
Openbox-Debug: client area: 0 0  150 100  bw 1
Openbox-Debug: Normal hints: min size (0 0) max size (2147483647 2147483647)
Openbox-Debug: size inc (1 1) base size (-1 -1)
Openbox-Debug: client desktop set to the current desktop: 0
Openbox-Debug: Setting client xeyes colormap: 0x3e
Openbox-Debug: Window type: 7
Openbox-Debug: Window group: 0x0
Openbox-Debug: Window name: xeyes class: XEyes role:  title: xeyes
Openbox-Debug: Window group name: xeyes group class: XEyes
Openbox-Debug: Going to try activate new window? no
Openbox-Debug: Positioned: no @ 0 0
Openbox-Debug: Sized: program specified @ 150 100
Openbox-Debug: placement choice 0 is monitor 0
Openbox-Debug:   - placement choice
Openbox-Debug:   - primary monitor
Openbox-Debug: setting window size to 152x125
Openbox-Debug: placing window 0x40000a at 1204, 657 with size 150 x 100. some restrictions may apply
Openbox-Debug: placed window 0x40000a at 1204, 657 with size 150 x 100
Openbox-Debug: Sending ConfigureNotify to xeyes for 1204,676 150x100
Openbox-Debug: Managed window 0x40000a plate 0x200261 (XEyes)

@faern commented on GitHub (Jan 3, 2021): > in the Xwayland-window Which of the commands even give you this window? I don't have any window at all showing up from any of these commands. I'm running Fedora 33 workstation with Swaywm. If I add debugging output to openbox I see this: ``` $ DISPLAY=:2 openbox --debug Openbox-Debug: Failed to connect to session manager: SESSION_MANAGER environment variable not defined Openbox-Debug: Monitor 0 @ 0,0 2560x1440 Openbox-Debug: Full desktop @ 0,0 2560x1440 Openbox-Debug: Moving to desktop 1 Openbox-Debug: not managing override redirect window 0x20020b Openbox-Debug: UPDATE DESKTOP NAMES Openbox-Debug: Managing window: 0x40000a Openbox-Debug: client area: 0 0 150 100 bw 1 Openbox-Debug: Normal hints: min size (0 0) max size (2147483647 2147483647) Openbox-Debug: size inc (1 1) base size (-1 -1) Openbox-Debug: client desktop set to the current desktop: 0 Openbox-Debug: Setting client xeyes colormap: 0x3e Openbox-Debug: Window type: 7 Openbox-Debug: Window group: 0x0 Openbox-Debug: Window name: xeyes class: XEyes role: title: xeyes Openbox-Debug: Window group name: xeyes group class: XEyes Openbox-Debug: Going to try activate new window? no Openbox-Debug: Positioned: no @ 0 0 Openbox-Debug: Sized: program specified @ 150 100 Openbox-Debug: placement choice 0 is monitor 0 Openbox-Debug: - placement choice Openbox-Debug: - primary monitor Openbox-Debug: setting window size to 152x125 Openbox-Debug: placing window 0x40000a at 1204, 657 with size 150 x 100. some restrictions may apply Openbox-Debug: placed window 0x40000a at 1204, 657 with size 150 x 100 Openbox-Debug: Sending ConfigureNotify to xeyes for 1204,676 150x100 Openbox-Debug: Managed window 0x40000a plate 0x200261 (XEyes) ```

gitea-mirror commented

2026-05-05 06:26:26 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 3, 2021):

in the Xwayland-window

Which of the commands even give you this window?

Xwayland :2 after around a half second.

If you have already disabled Xwayland in sways config, my guess is that this happens because it's the first Xwayland. Maybe test if a second Xwayland :3 opens up a window. If so, there's hopefully a option in Xwayland for that.

@rusty-snake commented on GitHub (Jan 3, 2021): > > in the Xwayland-window > > Which of the commands even give you this window? `Xwayland :2` after around a half second. If you have already disabled Xwayland in sways config, my guess is that this happens because it's the first Xwayland. Maybe test if a second `Xwayland :3` opens up a window. If so, there's hopefully a option in Xwayland for that.

gitea-mirror commented

2026-05-05 06:26:28 -06:00

Author

Owner

@faern commented on GitHub (Jan 12, 2021):

I never get any window from running Xwayland ... :O I have tried both in Sway and Gnome and both with and without disabling XWayland in Sway. And I have tried starting two instances manually. No dice. I'm on Fedora 33, a pretty standard setup I would say. Reinstalled just a few days ago. The difference I can think of is that I have to give -rootless for it to not just exit with an error instantly.

@faern commented on GitHub (Jan 12, 2021): I never get any window from running `Xwayland ...` :O I have tried both in Sway and Gnome and both with and without disabling XWayland in Sway. And I have tried starting two instances manually. No dice. I'm on Fedora 33, a pretty standard setup I would say. Reinstalled just a few days ago. The difference I can think of is that I have to give `-rootless` for it to not just exit with an error instantly.

gitea-mirror commented

2026-05-05 06:26:30 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 28, 2021):

Using -rootless doesn't open a window for me too.

@rusty-snake commented on GitHub (Jan 28, 2021): Using `-rootless` doesn't open a window for me too.

gitea-mirror commented

2026-05-05 06:26:32 -06:00

Author

Owner

@NobodyXu commented on GitHub (Mar 3, 2021):

Maybe x11docker will help:

x11docker: Run GUI applications in Docker

Avoid X security leaks and enhance container security

Introduction

x11docker allows to run graphical desktop applications (and entire desktops) in Docker Linux containers.

Docker allows to run applications in an isolated container environment.
Containers need much less resources than virtual machines for similar tasks.

Docker does not provide a display server that would allow to run applications with a graphical user interface.

x11docker fills the gap. It runs an X display server on the host system and provides it to Docker containers.

Additionally x11docker does some security setup to enhance container isolation and to avoid X security leaks.
This allows a sandbox environment that fairly well protects the host system from possibly malicious or buggy software.

Software can be installed in a deployable Docker image with a rudimentary Linux system inside.
This can help to run or deploy software that is difficult to install on several systems due to dependency issues. It is possible to run outdated versions or latest development versions side by side.
Files to work on can be shared between host and container.

x11docker wiki provides some how-to's for basic setups without x11docker.

Features

Focus on security:

Avoids X security leaks by running additional X servers.

Restricts container capabilities to bare minimum.

Container user is same as host user to avoid root in container.

Low dependencies:

No obliging dependencies on host beside X and Docker. Recommended: nxagent and Xephyr.

No dependencies inside of Docker images except for some optional features.

Several optional features like GPU, sound, webcam and printer support.

Remote access with SSH, VNC or HTML5 possible.

Easy to use. Examples:

x11docker x11docker/fvwm xterm

x11docker --desktop --size 320x240 x11docker/lxde (needs nested X server Xephyr)

Despite it is designed for docker, you might be able to modify the script in there to support firejail.

@NobodyXu commented on GitHub (Mar 3, 2021): Maybe [x11docker](https://github.com/mviereck/x11docker) will help: > # x11docker: Run GUI applications in Docker > ## Avoid X security leaks and enhance container security > ### Introduction > x11docker allows to run graphical desktop applications (and entire desktops) in Docker Linux containers. > - [Docker](https://en.wikipedia.org/wiki/Docker_(software)) allows to run applications in an isolated [container](https://en.wikipedia.org/wiki/Operating-system-level_virtualization) environment. > Containers need much less resources than [virtual machines](https://en.wikipedia.org/wiki/Virtual_machine) for similar tasks. > - Docker does not provide a [display server](https://en.wikipedia.org/wiki/Display_server) that would allow to run applications with a [graphical user interface](https://en.wikipedia.org/wiki/Graphical_user_interface). > - x11docker fills the gap. It runs an [X display server](https://en.wikipedia.org/wiki/X_Window_System) on the host system and provides it to Docker containers. > - Additionally x11docker does some [security setup](https://github.com/mviereck/x11docker#security) to enhance container isolation and to avoid X security leaks. > This allows a [sandbox](https://github.com/mviereck/x11docker#sandbox) environment that fairly well protects the host system from possibly malicious or buggy software. > > Software can be installed in a deployable Docker image with a rudimentary Linux system inside. > This can help to run or deploy software that is difficult to install on several systems due to dependency issues. It is possible to run outdated versions or latest development versions side by side. > Files to work on can be shared between host and container. > > [x11docker wiki](https://github.com/mviereck/x11docker/wiki) provides some how-to's for basic setups without x11docker. > > ### Features > - Focus on [security](https://github.com/mviereck/x11docker#security): > - Avoids X security leaks by running [additional X servers](https://github.com/mviereck/x11docker#choice-of-x-servers-and-wayland-compositors). > - Restricts container capabilities to bare minimum. > - Container user is same as host user to avoid root in container. > - Low [dependencies](https://github.com/mviereck/x11docker#dependencies): > - No obliging dependencies on host beside X and Docker. Recommended: `nxagent` and `Xephyr`. > - No dependencies inside of Docker images except for some optional features. > - Several [optional features](https://github.com/mviereck/x11docker#options) like [GPU](https://github.com/mviereck/x11docker#gpu-hardware-acceleration), [sound](https://github.com/mviereck/x11docker#sound), [webcam](https://github.com/mviereck/x11docker#webcam) and [printer](https://github.com/mviereck/x11docker#printer) support. > - Remote access with [SSH](https://github.com/mviereck/x11docker/wiki/Remote-access-with-SSH), [VNC](https://github.com/mviereck/x11docker/wiki/VNC) or [HTML5](https://github.com/mviereck/x11docker/wiki/Container-applications-running-in-Browser-with-HTML5) possible. > - Easy to use. [Examples](https://github.com/mviereck/x11docker#examples): > - `x11docker x11docker/fvwm xterm` > - `x11docker --desktop --size 320x240 x11docker/lxde` (needs nested X server `Xephyr`) > > ![retro terminal cathode](https://github.com/mviereck/x11docker/blob/screenshots/screenshot-retroterm.png?raw=true "LXDE desktop in docker")![lxde](https://github.com/mviereck/x11docker/blob/screenshots/screenshot-lxde-small.png?raw=true) Despite it is designed for `docker`, you might be able to modify the script in there to support `firejail`.

Rows
Columns

[GH-ISSUE #998] gui isolation through wayland #680

x11docker: Run GUI applications in Docker

Avoid X security leaks and enhance container security

Introduction

Features