igo95862 / bubblejail

Bubblewrap based sandboxing for desktop applications
261 stars 17 forks source link

Wayland security context #118

Open odomingao opened 3 months ago

odomingao commented 3 months ago

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.

igo95862 commented 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.

rusty-snake commented 3 months ago

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

FelixPehla commented 3 months ago

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.

odomingao commented 3 months ago

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?

FelixPehla commented 3 months ago

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.

rusty-snake commented 3 months ago

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.

odomingao commented 1 month ago

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
rusty-snake commented 1 month ago

It's not from me, it's from @WhyNotHugo. Tickets/Mailing/Chat on the sourcehut repo seem to be disabled.

WhyNotHugo commented 1 month ago

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

WhyNotHugo commented 1 month ago

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.

odomingao commented 2 weeks ago

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.