diff options
Diffstat (limited to 'hst/config.go')
| -rw-r--r-- | hst/config.go | 36 |
1 files changed, 35 insertions, 1 deletions
diff --git a/hst/config.go b/hst/config.go index 5032471b..0c66c274 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. |