-
Notifications
You must be signed in to change notification settings - Fork 561
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wayland security context support #5883
Comments
FWIW, the Flatpak impl: flatpak/flatpak#4920 |
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:
Do you have any preferences for this or other things I should keep in mind? |
One more point I thought of: much like the What are your thoughts on this @glitsj16 @kmk3 @rusty-snake ? |
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.
Personally I like this proposal.
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.
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 All in all a generous offer to work on this :-) Regards |
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. Some features do hard-fail, but only when requested on command-line not when requested by a profile.
I do not like the include cluttering, we need snippets. Nevermind, how about
|
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). |
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. |
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 |
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. |
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:
Plus the following wlroots protocols:
|
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. |
Correct, it is.
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 Nevertheless, no compositor does this (or has any plans to do this, AFAIK), so can we agree that it is out-of-scope here?
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.
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. |
Note that mutter implements e.g. the global keyboard shortcut inhibitor and this one is more privileged as well. |
I believe Weston and Kwin create a new socket with access to a subset of privileged protocols and pass them to an application using This should also (optionally) be allowed here I think, maybe with something like |
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. |
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
.The text was updated successfully, but these errors were encountered: