Open odomingao opened 3 months ago
Hello @odomingao
Yes, I looked in to in that in the past but it is not very simple to implement as it requires connecting to the wayland socket talking with the compositor using the wayland protocol. I am not aware if there is any simple CLI tool to create new wayland sockets with a given security context.
From the corresponding firejail issues:
Shameless plug: I wrote a tiny cli client that creates a new socket at given path: https://git.sr.ht/~whynothugo/way-secure
Relevant commits from recent integration into flatpak:
https://github.com/flatpak/flatpak/commit/f0e626a4b60439f211f06d35df74b675a9ef42f4 https://github.com/flatpak/flatpak/commit/b4822e2230c62dc890f0392677fa4a5f98f10450
FelixPehla / run_with_wayland_security_context_v1:
https://github.com/FelixPehla/run_with_wayland_security_context_v1
and therefore certain privileged protocols should be disabled inside of it, such as screencopy
Keep in mind that screencapturing/-sharing specifically is often implemented via pipewire or portals, so only limiting permissions on the wayland socket is not enough in this case.
Currently, this is implemented by sway
Kwin/KDE supports it too.
Feel free to copy any parts of run_with_security_context_v1
you need. I think it's generally fairly straightforward, but you need to figure out how you want to set the app_id
and instance_id
of the associated security context. These should allow a wayland compositor to identify an application securely and race-free and allow giving programs permissions during its runtime, although no one uses these features yet AFAIK.
Thanks!
Keep in mind that screencapturing/-sharing specifically is often implemented via pipewire or portals, so only limiting permissions on the wayland socket is not enough in this case.
Are current portal implementations not secure, then? Can an app bypass the screensharing prompt and capture the screen anyway if it wants to?
Are current portal implementations not secure, then? Can an app bypass the screensharing prompt and capture the screen anyway if it wants to?
If the program is sandboxed by flatpak it can only access the portal interfaces it has permissions for. If access to portal (through DBus) is not restricted then it has access to everything, assuming the wayland compositor implements the functionality and makes it accessible to all clients.
Highlighting the important part:
If access to portal (through DBus) is not restricted then it has access to everything, assuming the wayland compositor implements the functionality and makes it accessible to all clients.
Shameless plug: I wrote a tiny cli client that creates a new socket at given path: https://git.sr.ht/~whynothugo/way-secure
Hello. @rusty-snake, could you provide some guidance on how to get your project working on Hyprland, as they implemented the protocol in the most recent update? I apologize that this thread isn't the most suitable place to discuss this, but I couldn't find any way to reach you and I don't know how to create an issue on sr.ht if that's even possible.
I get:
Error: creating secure context
Caused by:
global with interface "wp_security_context_manager_v1" not found
It's not from me, it's from @WhyNotHugo. Tickets/Mailing/Chat on the sourcehut repo seem to be disabled.
@odomingao That error indicates that the compositor isn't exposing the wp_security_context_manager_v1
global. E.g.: the compositor doesn't implement the security context protocol extension.
Tickets/Mailing/Chat on the sourcehut repo seem to be disabled.
Nothing is "disabled"; I'd just forgotten to put links in the README. Updated now.
Thanks everyone.
Just to give a quick update, I've been able to get this working quite easily now that Hyprland implements the protocol in a tagged release, using Hugo's way-secure.
Step 1 create the socket (on compositor login)
s6-ipcserver-socketbinder $XDG_RUNTIME_DIR/way-secure way-secure --socket-fd 0
Step 2 put in raw bwrap args:
"--bind",
"/run/user/1000/way-secure",
"/run/user/1000/wayland-0",
Step 3 ensure that [wayland] is not enabled
Will take sometime for me to fix all of my profiles accordingly, but so far it has worked perfectly for me. Will edit this postt if/when something breaks.
Description
I learned that there's a wayland protocol that sandbox managers can implement to tell the compositor that the application being launched is sandboxed and therefore certain privileged protocols should be disabled inside of it, such as screencopy. Currently, this is implemented by sway and maybe (hopefully) Hyprland will decide to implement it as well.
Could this be supported by bubblejail in the future?
Thank you.