Skip to content
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 #118

Open
odomingao opened this issue Aug 6, 2024 · 11 comments
Open

Wayland security context #118

odomingao opened this issue Aug 6, 2024 · 11 comments

Comments

@odomingao
Copy link

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
Copy link
Owner

igo95862 commented Aug 6, 2024

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
Copy link
Contributor

rusty-snake commented Aug 6, 2024

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:

flatpak/flatpak@f0e626a
flatpak/flatpak@b4822e2

FelixPehla / run_with_wayland_security_context_v1:

https://github.com/FelixPehla/run_with_wayland_security_context_v1

@FelixPehla
Copy link

FelixPehla commented Aug 7, 2024

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
Copy link
Author

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
Copy link

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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

@WhyNotHugo
Copy link

@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
Copy link

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
Copy link
Author

odomingao commented Nov 12, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants