Wayland security context support

[WhyNotHugo]

Is your feature request related to a problem? Please describe.

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.

[emersion]

FWIW, the Flatpak impl: flatpak/flatpak#4920

[FelixPehla]

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?

[FelixPehla]

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 ?

[glitsj16]

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

[rusty-snake]

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

[emersion]

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