[GH-ISSUE #5883] Wayland security context support

gitea-mirror commented

2026-05-05 09:45:30 -06:00

Owner

Originally created by @WhyNotHugo on GitHub (Jul 4, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5883

security-context is a wayland protocol that can be used by clients to create a new wayland socket. The same compositor instance will listen for connections on this sockets, but clients that connect to it cannot perform privileged operations.

Describe the solution you'd like

Firejail should use this protocol to further sandbox clients and prevent them from screenscrapping, creating transparent fullscreen overlays and permanent keyboard hijacking, other attacks. All these attack rely on "priviledged" protocols and are unavailable on sockets created via security-context.

Describe alternatives you've considered

So far there hasn't been a way to do this. This protocol was introduced in wayland-protocols 1.32 which was released yesterday.

sway already has a patch with a working server implementations. I expect other wlroots compositors to follow suit.

Additional context

Shameless plug: I wrote a tiny cli client that creates a new socket at given path: https://git.sr.ht/~whynothugo/way-secure

This could be called on the host to create a socket inside the sandbox's $XDG_RUNTIME_DIR.

Originally created by @WhyNotHugo on GitHub (Jul 4, 2023). Original GitHub issue: https://github.com/netblue30/firejail/issues/5883 ### Is your feature request related to a problem? Please describe. [security-context](https://wayland.app/protocols/security-context-v1) is a wayland protocol that can be used by clients to create a new wayland socket. The same compositor instance will listen for connections on this sockets, but clients that connect to it cannot perform privileged operations. ### Describe the solution you'd like Firejail should use this protocol to further sandbox clients and prevent them from screenscrapping, creating transparent fullscreen overlays and permanent keyboard hijacking, other attacks. All these attack rely on "priviledged" protocols and are unavailable on sockets created via `security-context`. ### Describe alternatives you've considered So far there hasn't been a way to do this. This protocol was introduced in wayland-protocols 1.32 which was released yesterday. sway already has [a patch with a working server implementations](https://github.com/swaywm/sway/pull/7648). I expect other wlroots compositors to follow suit. ### Additional context Shameless plug: I wrote a tiny cli client that creates a new socket at given path: https://git.sr.ht/~whynothugo/way-secure This could be called on the host to create a socket inside the sandbox's `$XDG_RUNTIME_DIR`.

gitea-mirror added the

enhancement

label 2026-05-05 09:45:30 -06:00

gitea-mirror commented

2026-05-05 09:45:32 -06:00

Author

Owner

@emersion commented on GitHub (Jul 11, 2023):

FWIW, the Flatpak impl: https://github.com/flatpak/flatpak/pull/4920

@emersion commented on GitHub (Jul 11, 2023): FWIW, the Flatpak impl: https://github.com/flatpak/flatpak/pull/4920

gitea-mirror commented

2026-05-05 09:45:33 -06:00

Author

Owner

@qwertviop commented on GitHub (Aug 1, 2024):

This protocol is already implemented by Kwin and sway.

I am interested in trying to implement this but before I start I would like to ask some general questions about how this should be implemented and configured.

By looking at how some mechanisms for x11 are implemented:

Profiles can explicitly disable access to x11 by including disable-x11.inc, which disallows access to various Xorg related files and unsets the DISPLAY and XAUTHORITY environmental variables. This can easily be done for Wayland too: create a disable-wayland.inc that disallows some IPC sockets in ${RUNUSER}, unsets WAYLAND_DISPLAY and WAYLAND_SOCKET, etc. This should probably be done regardless, as grep -E '^blacklist.*wayland' ./profile-*/* | wc -l gives me the output 52, and I don't think it's reasonable that a profile that wants to disable wayland has to manually blacklist sockets.
There exists an x11 filter to enable x11 sandboxing, a wayland filter could be used to only allow access to unprivileged protocols.
There is a HAVE_X11 flag for compilation with or without x11 support. The same could be done to compile with or without wayland security context support.
If the wayland compositor in use does not implement the protocol, despite wayland-filtering being enabled, should firejail only emit a warning or refuse to start? In the latter case, there should probably exist a conditional or global configuration setting for enabling/disabling wayland filtering.

Do you have any preferences for this or other things I should keep in mind?

@qwertviop commented on GitHub (Aug 1, 2024): This protocol is already implemented by Kwin and sway. I am interested in trying to implement this but before I start I would like to ask some general questions about how this should be implemented and configured. By looking at how some mechanisms for x11 are implemented: - Profiles can explicitly disable access to x11 by including `disable-x11.inc`, which disallows access to various Xorg related files and unsets the `DISPLAY` and `XAUTHORITY` environmental variables. This can easily be done for Wayland too: create a `disable-wayland.inc` that disallows some IPC sockets in `${RUNUSER}`, unsets `WAYLAND_DISPLAY` and `WAYLAND_SOCKET`, etc. This should probably be done regardless, as `grep -E '^blacklist.*wayland' ./profile-*/* | wc -l` gives me the output 52, and I don't think it's reasonable that a profile that wants to disable wayland has to manually blacklist sockets. - There exists an `x11` filter to enable x11 sandboxing, a `wayland` filter could be used to only allow access to unprivileged protocols. - There is a `HAVE_X11` flag for compilation with or without x11 support. The same could be done to compile with or without wayland security context support. - If the wayland compositor in use does not implement the protocol, despite wayland-filtering being enabled, should firejail only emit a warning or refuse to start? In the latter case, there should probably exist a conditional or global configuration setting for enabling/disabling wayland filtering. Do you have any preferences for this or other things I should keep in mind?

gitea-mirror commented

2026-05-05 09:45:34 -06:00

Author

Owner

@qwertviop commented on GitHub (Aug 1, 2024):

One more point I thought of: much like the @x11 group including not just x11 files but also stuff related to GTK, Qt, vulkan, etc. there should probably be a group like @wayland that includes those too. Or alternatively you separate the common graphics stack from x11 and have something like @gui.

What are your thoughts on this @glitsj16 @kmk3 @rusty-snake ?

@qwertviop commented on GitHub (Aug 1, 2024): One more point I thought of: much like the `@x11` group including not just x11 files but also stuff related to GTK, Qt, vulkan, etc. there should probably be a group like `@wayland` that includes those too. Or alternatively you separate the common graphics stack from x11 and have something like `@gui`. What are your thoughts on this @glitsj16 @kmk3 @rusty-snake ?

gitea-mirror commented

2026-05-05 09:45:36 -06:00

Author

Owner

@ghost commented on GitHub (Aug 2, 2024):

create a disable-wayland.inc

This seems very doable indeed. I don't think there's anything special here besides implementing and editing the affected profiles and the profile template.

There exists an x11 filter to enable x11 sandboxing, a wayland filter could be used to only allow access to unprivileged protocols.

Personally I like this proposal.

There is a HAVE_X11 flag for compilation with or without x11 support. The same could be done to compile with or without wayland security context support.

Yes, I wouldn't expect anything unusual here. But @kmk3 is much better placed to advise on the particulars involved/potential implementation details to follow etcetera.

If the wayland compositor in use does not implement the protocol, despite wayland-filtering being enabled, should firejail only emit a warning or refuse to start?

This is probably the trickier part of your proposal. I mean, there are pro's and con's here to consider for both suggestions and that's always very difficult to judge. No personal preference.

On the topic of private-etc groups I'll need a bit more time to go over the suggested @wayland or @gui groups. But I can see the importance/gains of adding/improving support for it.

All in all a generous offer to work on this :-)

Regards

@ghost commented on GitHub (Aug 2, 2024): > create a `disable-wayland.inc` This seems very doable indeed. I don't think there's anything special here besides implementing and editing the affected profiles and the profile template. > There exists an x11 filter to enable x11 sandboxing, a `wayland` filter could be used to only allow access to unprivileged protocols. Personally I like this proposal. > There is a HAVE_X11 flag for compilation with or without x11 support. The same could be done to compile with or without wayland security context support. Yes, I wouldn't expect anything unusual here. But @kmk3 is much better placed to advise on the particulars involved/potential implementation details to follow etcetera. > If the wayland compositor in use does not implement the protocol, despite wayland-filtering being enabled, should firejail only emit a warning or refuse to start? This is probably the trickier part of your proposal. I mean, there are pro's and con's here to consider for both suggestions and that's always very difficult to judge. No personal preference. On the topic of `private-etc` groups I'll need a bit more time to go over the suggested `@wayland` or `@gui` groups. But I can see the importance/gains of adding/improving support for it. All in all a generous offer to work on this :-) Regards

gitea-mirror commented

2026-05-05 09:45:36 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 2, 2024):

If the wayland compositor in use does not implement the protocol, despite wayland-filtering being enabled, should firejail only emit a warning or refuse to start?

This is probably the trickier part of your proposal. I mean, there are pro's and con's here to consider for both suggestions and that's always very difficult to judge. No personal preference.

Consequences of fail is that we can not add it to any profile, hence "normal" users will not benefit from it, only power users who create .locals or add it to globals.local.

If we go with warning/info (I prefer) we can add it to profiles upstream as long as someone tested it with a supporting compositor and normal users can benefit.

For the most features we don't do a hard-fail if the platform requirements are not satisfied.
And the feature that have a hard-fail (x11 none) had caused problems and ugly workarounds like disable-X11.inc.

Some features do hard-fail, but only when requested on command-line not when requested by a profile.

disable-wayland.inc

I do not like the include cluttering, we need snippets.

Nevermind, how about

wayland none: blacklist wayland socket and unset env (can be implemented with profile_add)
wayland: use security context
wayland xxx: future extension possible

@rusty-snake commented on GitHub (Aug 2, 2024): > > If the wayland compositor in use does not implement the protocol, despite wayland-filtering being enabled, should firejail only emit a warning or refuse to start? > > This is probably the trickier part of your proposal. I mean, there are pro's and con's here to consider for both suggestions and that's always very difficult to judge. No personal preference. Consequences of fail is that we can not add it to any profile, hence "normal" users will not benefit from it, only power users who create .locals or add it to globals.local. If we go with warning/info (I prefer) we can add it to profiles upstream as long as someone tested it with a supporting compositor and normal users can benefit. For the most features we don't do a hard-fail if the platform requirements are not satisfied. And the feature that have a hard-fail (`x11 none`) had caused problems and ugly workarounds like `disable-X11.inc`. Some features do hard-fail, but only when requested on command-line not when requested by a profile. > `disable-wayland.inc` I do not like the include cluttering, we need snippets. Nevermind, how about - `wayland none`: blacklist wayland socket and unset env (can be implemented with profile_add) - `wayland`: use security context - `wayland xxx`: future extension possible

gitea-mirror commented

2026-05-05 09:45:37 -06:00

Author

Owner

@emersion commented on GitHub (Aug 2, 2024):

If the wayland compositor in use does not implement the protocol, despite wayland-filtering being enabled, should firejail only emit a warning or refuse to start?

FWIW, Flatpak just carries on without the protocol if the compositor doesn't support it. Do note that Flatpak makes the difference between missing compositor support (global not advertised) and all other kind of errors when setting up the Wayland security context (these are hard failures).

@emersion commented on GitHub (Aug 2, 2024): > If the wayland compositor in use does not implement the protocol, despite wayland-filtering being enabled, should firejail only emit a warning or refuse to start? FWIW, Flatpak just carries on without the protocol if the compositor doesn't support it. Do note that Flatpak makes the difference between missing compositor support (global not advertised) and all other kind of errors when setting up the Wayland security context (these are hard failures).

gitea-mirror commented

2026-05-05 09:45:37 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 15, 2024):

Just FTR: GNOME/Mutter does not implement this because it is secure by default. The Wayland security context idea comes from the Kwin and sway edges where security is opt-in.

@rusty-snake commented on GitHub (Aug 15, 2024): Just FTR: GNOME/Mutter does not implement this because it is secure by default. The Wayland security context idea comes from the Kwin and sway edges where security is opt-in.

gitea-mirror commented

2026-05-05 09:45:38 -06:00

Author

Owner

@emersion commented on GitHub (Aug 15, 2024):

Not exactly sure what this comment is about tbh. The security-context protocol allows authenticating clients, and GNOME also needs to do so. Support for the protocol is still WIP in mutter: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3107

@emersion commented on GitHub (Aug 15, 2024): Not exactly sure what this comment is about tbh. The security-context protocol allows authenticating clients, and GNOME also needs to do so. Support for the protocol is still WIP in mutter: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3107

gitea-mirror commented

2026-05-05 09:45:38 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 16, 2024):

Authentication alone is boring, you need to do something with it. Usually you will do authorisation.

In the context of wl-security-context everybody talks about screen capturing, which can then be deny/allow listed for some clients. However GNOME does not allow you to screen capture with third-party tools.

@rusty-snake commented on GitHub (Aug 16, 2024): Authentication alone is boring, you need to do something with it. Usually you will do authorisation. In the context of wl-security-context everybody talks about screen capturing, which can then be deny/allow listed for some clients. However GNOME does not allow you to screen capture with third-party tools.

gitea-mirror commented

2026-05-05 09:45:38 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Aug 16, 2024):

Authentication alone is boring, you need to do something with it. Usually you will do authorisation.

wl-security-context isn't just about authentication. On sway (and likely other compositors too), clients in a security context don't have access to any privileged protocol by default.

If firejail puts its sandboxed clients in a security context, they won't have access to any privileged protocols on compositors that expose them.

While screen capture is the typical example, the following are also considered privileged and not suitable for sandboxed clients:

ext-session-lock-v1
ext-foreign-toplevel-list-v1
ext-layer-shell (not yet stable)

Plus the following wlroots protocols:

wlr-data-control-unstable-v1
wlr-foreign-toplevel-management-unstable-v1
wlr-layer-shell-unstable-v1
wlr-output-management-unstable-v1
wlr-output-power-management-unstable-v1
wlr-virtual-pointer-unstable-v1

@WhyNotHugo commented on GitHub (Aug 16, 2024): > Authentication alone is boring, you need to do something with it. Usually you will do authorisation. `wl-security-context` isn't _just_ about authentication. On sway (and likely other compositors too), clients in a security context don't have access to any privileged protocol by default. If firejail puts its sandboxed clients in a security context, they won't have access to any privileged protocols on compositors that expose them. While screen capture is the typical example, the following are also considered privileged and not suitable for sandboxed clients: - ext-session-lock-v1 - ext-foreign-toplevel-list-v1 - ext-layer-shell ([not yet stable](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28)) Plus the following wlroots protocols: - wlr-data-control-unstable-v1 - wlr-foreign-toplevel-management-unstable-v1 - wlr-layer-shell-unstable-v1 - wlr-output-management-unstable-v1 - wlr-output-power-management-unstable-v1 - wlr-virtual-pointer-unstable-v1

gitea-mirror commented

2026-05-05 09:45:39 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 16, 2024):

wl-security-context isn't just about authentication. On sway (and likely other compositors too), clients in a security context don't have access to any privileged protocol by default.

Authentication alone is boring, you need to do something with it. Usually you will do authorisation.
is_privileged() ? deny : allow is authorisation.
However instead of this hardcoded(?) policy a compositor could also open a pop-up that asks the user "MyProgram tries to capture your screen. [ALLOW] [DENY]", use polkit for configurable policies. The specification says only "This is intended to be used by sandboxes. Sandbox engines attach a security context to all connections coming from inside the sandbox. The compositor can then restrict the features that the sandboxed connections can use."
1. Security context is about sandboxing.
2. For sandboxing you need to authenticate a client/connection. This is what security contexts are used for.
3. You should then restrict features.
4. It does not say what and how should be restricted.

While screen capture is the typical example, the following are also considered privileged and not suitable for sandboxed clients

Non of the is implemented by mutter according to https://wayland.app/.

Going back to my comment above. Kwin/sway implement privileged protocols. Hence they need security contexts for sandboxed clients. Mutter does not implement privileged protocol, security contexts are less important.

@rusty-snake commented on GitHub (Aug 16, 2024): > wl-security-context isn't just about authentication. On sway (and likely other compositors too), clients in a security context don't have access to any privileged protocol by default. - > Authentication alone is boring, you need to do something with it. Usually you will ***do authorisation.*** - `is_privileged() ? deny : allow` is authorisation. - However instead of this hardcoded(?) policy a compositor could also open a pop-up that asks the user "MyProgram tries to capture your screen. [ALLOW] [DENY]", use polkit for configurable policies. The specification says only "This is intended to be used by sandboxes. Sandbox engines attach a security context to all connections coming from inside the sandbox. The compositor can then restrict the features that the sandboxed connections can use." 1. Security context is about sandboxing. 2. For sandboxing you need to authenticate a client/connection. This is what security contexts are used for. 3. You should then restrict features. 4. It does *not* say what and how should be restricted. > While screen capture is the typical example, the following are also considered privileged and not suitable for sandboxed clients Non of the is implemented by mutter according to https://wayland.app/. Going back to my comment above. Kwin/sway implement privileged protocols. Hence they need security contexts for sandboxed clients. Mutter does not implement privileged protocol, security contexts are less important.

gitea-mirror commented

2026-05-05 09:45:39 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Aug 16, 2024):

is_privileged() ? deny : allow is authorisation.

Correct, it is.

However instead of this hardcoded(?) policy a compositor could also open a pop-up that asks the user "MyProgram tries to capture your screen. [ALLOW] [DENY]", use polkit for configurable policies.

A compositor could choose to do any of the above if they wanted to. I'm not sure if polkit is the right tool though; it is a system service configured by root. It is usually used to authorise users to run system-wide privileged operations, not for sandboxes to run user-wide privileged operations.

Nevertheless, no compositor does this (or has any plans to do this, AFAIK), so can we agree that it is out-of-scope here?

The specification says only "This is intended to be used by sandboxes. Sandbox engines attach a security context to all connections coming from inside the sandbox. The compositor can then restrict the features that the sandboxed connections can use."

You make a good point here: the protocol specification itself doesn't state "compositors will restrict access to all privileged protocols". In reality, current implementation do restrict them.

There is currently no mechanism to allow a client to access some privileged protocols. AFAIK, there is an intent of implementing one such protocol, but there seems to be no consensus on what it will look like.

Going back to my comment above. Kwin/sway implement privileged protocols. Hence they need security contexts for sandboxed clients. Mutter does not implement privileged protocol, security contexts are less important.

I think it's fair to say "almost every compositor except Mutter", rather than "Kwin/sway".

Mutter handles this out-of-band via D-Bus, so instead of having to sandbox the Wayland connection, you need to sandbox D-Bus instead. This is already implemented in firejail, so you don't need to worry about Mutter.

@WhyNotHugo commented on GitHub (Aug 16, 2024): > is_privileged() ? deny : allow is authorisation. Correct, it is. > However instead of this hardcoded(?) policy a compositor could also open a pop-up that asks the user "MyProgram tries to capture your screen. [ALLOW] [DENY]", use polkit for configurable policies. A compositor _could_ choose to do any of the above if they wanted to. I'm not sure if polkit is the right tool though; it is a system service configured by `root`. It is usually used to authorise users to run system-wide privileged operations, not for sandboxes to run user-wide privileged operations. Nevertheless, no compositor does this (or has any plans to do this, AFAIK), so can we agree that it is out-of-scope here? > The specification says only "This is intended to be used by sandboxes. Sandbox engines attach a security context to all connections coming from inside the sandbox. The compositor can then restrict the features that the sandboxed connections can use." You make a good point here: the protocol specification itself doesn't state "compositors will restrict access to all privileged protocols". In reality, current implementation do restrict them. There is currently no mechanism to allow a client to access _some_ privileged protocols. AFAIK, there is an intent of implementing one such protocol, but there seems to be no consensus on what it will look like. > Going back to my comment above. Kwin/sway implement privileged protocols. Hence they need security contexts for sandboxed clients. Mutter does not implement privileged protocol, security contexts are less important. I think it's fair to say "almost every compositor except Mutter", rather than "Kwin/sway". Mutter handles this out-of-band via D-Bus, so instead of having to sandbox the Wayland connection, you need to sandbox D-Bus instead. This is already implemented in firejail, so you don't need to worry about Mutter.

gitea-mirror commented

2026-05-05 09:45:40 -06:00

Author

Owner

@emersion commented on GitHub (Aug 16, 2024):

Note that mutter implements e.g. the global keyboard shortcut inhibitor and this one is more privileged as well.

@emersion commented on GitHub (Aug 16, 2024): Note that mutter implements e.g. the global keyboard shortcut inhibitor and this one is more privileged as well.

gitea-mirror commented

2026-05-05 09:45:40 -06:00

Author

Owner

@qwertviop commented on GitHub (Aug 16, 2024):

There is currently no mechanism to allow a client to access some privileged protocols. AFAIK, there is an intent of implementing one such protocol, but there seems to be no consensus on what it will look like.

I believe Weston and Kwin create a new socket with access to a subset of privileged protocols and pass them to an application using $WAYLAND_SOCKET, as per the discussion here.

This should also (optionally) be allowed here I think, maybe with something like wayland socket? I'm not sure about the argument, but that can be hashed out later.

@qwertviop commented on GitHub (Aug 16, 2024): > There is currently no mechanism to allow a client to access some privileged protocols. AFAIK, there is an intent of implementing one such protocol, but there seems to be no consensus on what it will look like. I believe Weston and Kwin create a new socket with access to a subset of privileged protocols and pass them to an application using `$WAYLAND_SOCKET`, as per the discussion [here](https://github.com/flatpak/flatpak/issues/5614). This should also (optionally) be allowed here I think, maybe with something like `wayland socket`? I'm not sure about the argument, but that can be hashed out later.

gitea-mirror commented

2026-05-05 09:45:40 -06:00

Author

Owner

@qwertviop commented on GitHub (Aug 18, 2024):

I didn't want to discuss the implementation details in an issue, so I've created a new draft here. Feel free to drop by.

@qwertviop commented on GitHub (Aug 18, 2024): I didn't want to discuss the implementation details in an issue, so I've created a new draft [here](https://github.com/netblue30/firejail/pull/6436). Feel free to drop by.

gitea-mirror commented

2026-05-05 09:45:41 -06:00

Author

Owner

@fira959 commented on GitHub (Oct 28, 2024):

Could someone explain the implications of not using this security-context to the casual reader coming across this issue please?

I used to be under the impression that X11 = bad for sandboxing because any process of the same user could access the x11 sockets and use it to read all other applications input. Is the same true for new sway implementations now, given the option for any normal client to use the screen capture feature of wayland? Does using any form of sandboxing on wayland/sway imply the same or similar issues as with X11?

@fira959 commented on GitHub (Oct 28, 2024): Could someone explain the implications of not using this security-context to the casual reader coming across this issue please? I used to be under the impression that X11 = bad for sandboxing because any process of the same user could access the x11 sockets and use it to read all other applications input. Is the same true for new sway implementations now, given the option for any normal client to use the screen capture feature of wayland? Does using any form of sandboxing on wayland/sway imply the same or similar issues as with X11?

gitea-mirror commented

2026-05-05 09:45:41 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 28, 2024):

Moved to #6522

@rusty-snake commented on GitHub (Oct 28, 2024): Moved to #6522

gitea-mirror referenced this issue

2026-05-05 10:24:02 -06:00

[PR #3123] [MERGED] Update i2prouter profile, and remove from firecfg #4650