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 <cat@gensokyo.uk>

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.