[Question/Request] Passing custom wayland socket to ego?

[odomingao]

Hello!

Now that my compositor of choice implements the security_context protocol, I'd like to be able to pass the security_context socket that I created to ego so that I can enjoy having that extra layer of security that user separation provides.

Is it possible to do this currently with ego?

If not, please consider implementing an option to maybe pass a custom path to the ego user, when you have the time. Thank you!

[intgr]

Now that my compositor of choice implements the security_context protocol, I'd like to be able to pass the security_context socket that I created to ego so that I can enjoy having that extra layer of security that user separation provides.

Thanks for pointing this out. There's no built in support at the moment.

Seems appropriate for ego: https://wayland.app/protocols/security-context-v1 "This is intended to be used by sandboxes. Sandbox engines attach a security context to all connections coming from inside the sandbox. The compositor can then restrict the features that the sandboxed connections can use."

However, it's not clear from the protocol description, what isolation improvements (if any) this will enable.

If implemented, we should also register a "sandbox engine name" at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/security-context/engines.md

Is it possible to do this currently with ego?

I'm not sure. If you have a Unix socket path created by this mechanism, it should work if you point WAYLAND_DISPLAY= to the socket and ego will simply use it. The directory containing the socket must either source user's $XDG_RUNTIME_DIR or be readable by target user.

[odomingao]

However, it's not clear from the protocol description, what isolation improvements (if any) this will enable.

There are privileged wayland protocols, such as screencopy which allows for taking full desktop screenshots, and a clipboard manager protocol which allows capturing the clipboard even as an inactive client (wayland spec afaik only allows the active window to capture clipboard content). If you create a socket in a security context, these kinds of privileged protocols are not whitelisted

I'm not sure. If you have a Unix socket path created by this mechanism, it should work if you point WAYLAND_DISPLAY= to the socket and ego will simply use it. The directory containing the socket must either source user's $XDG_RUNTIME_DIR or be readable by target user.

Works perfectly, thank you! Not sure why I didn't try this before creating the thread 😅

[intgr]

After quite a bit of experimenting, I now have a PoC that creates a functional Wayland security context (but does not use it yet).

https://github.com/intgr/ego/compare/wayrs-security-context OR https://github.com/intgr/ego/compare/wayland-security-context

Still needs some thinking how to properly integrate it...

• Where to put the socket?
• Can no longer use exec() since we need to keep open the close_fd file descriptor for the lifetime of our subprocess.
• Which library to prefer? wayrs seems simpler impementation wise.
• Any reason to expose --sync-fd option like bwrap does?
• (Future) PipeWire supports a similar security context mechanism: https://docs.pipewire.org/page_man_pw-container_1.html