From 0c0e3d6fc2bf37eef703e9295fc56ef2a2fc5808 Mon Sep 17 00:00:00 2001 From: Ophestra Date: Mon, 15 Dec 2025 12:29:32 +0900 Subject: [PATCH] hst: add direct hardware option This is unfortunately the only possible setup to securely expose PipeWire to the container. Further explanation explained in the doc comment and #29. This will be implemented in a future commit. Signed-off-by: Ophestra --- hst/config.go | 36 +++++++++++++++++++++++++++++++++++- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/hst/config.go b/hst/config.go index 5032471..0c66c27 100644 --- a/hst/config.go +++ b/hst/config.go @@ -30,12 +30,46 @@ type Config struct { // This option is unsupported and most likely enables full control over the Wayland // session. Do not set this to true unless you are sure you know what you are doing. DirectWayland bool `json:"direct_wayland,omitempty"` + // Direct access to the PipeWire socket established via SecurityContext::Create, no + // attempt is made to start the pipewire-pulse server. + // + // The SecurityContext machinery is fatally flawed, it blindly sets read and execute + // bits on all objects for clients with the lowest achievable privilege level (by + // setting PW_KEY_ACCESS to "restricted"). This enables them to call any method + // targeting any object, and since Registry::Destroy checks for the read and execute bit, + // allows the destruction of any object other than PW_ID_CORE as well. This behaviour + // is implemented separately in media-session and wireplumber, with the wireplumber + // implementation in Lua via an embedded Lua vm. In all known setups, wireplumber is + // in use, and there is no known way to change its behaviour and set permissions + // differently without replacing the Lua script. Also, since PipeWire relies on these + // permissions to work, reducing them is not possible. + // + // Currently, the only other sandboxed use case is flatpak, which is not aware of + // PipeWire and blindly exposes the bare PulseAudio socket to the container (behaves + // like DirectPulse). This socket is backed by the pipewire-pulse compatibility daemon, + // which obtains client pid via the SO_PEERCRED option. The PipeWire daemon, pipewire-pulse + // daemon and the session manager daemon then separately performs the /.flatpak-info hack + // described in https://git.gensokyo.uk/security/hakurei/issues/21. Under such use case, + // since the client has no direct access to PipeWire, insecure parts of the protocol are + // obscured by pipewire-pulse simply not implementing them, and thus hiding the flaws + // described above. + // + // Hakurei does not rely on the /.flatpak-info hack. Instead, a socket is sets up via + // SecurityContext. A pipewire-pulse server connected through it achieves the same + // permissions as flatpak does via the /.flatpak-info hack and is maintained for the + // life of the container. + // + // This option is unsupported and enables a denial-of-service attack as the sandboxed + // client is able to destroy any client object and thus disconnecting them from PipeWire, + // or destroy the SecurityContext object preventing any further container creation. + // Do not set this to true, it is insecure under any configuration. + DirectPipeWire bool `json:"direct_pipewire,omitempty"` // Direct access to PulseAudio socket, no attempt is made to establish pipewire-pulse // server via a PipeWire socket with a SecurityContext attached and the bare socket // is made available to the container. // // This option is unsupported and enables arbitrary code execution as the PulseAudio - // server. Do not set this to true, this is insecure under any configuration. + // server. Do not set this to true, it is insecure under any configuration. DirectPulse bool `json:"direct_pulse,omitempty"` // Extra acl updates to perform before setuid.