docker: Allow dockerd to connect to pulseaudio and wayland sockets

[kemalrasimsh]

Add optional policy support to allow the Docker daemon (dockerd_t) to connect to user session services over UNIX stream sockets.

This introduces:

• pulseaudio_stream_connect(dockerd_t)
• wayland_stream_connect(dockerd_t)

These interfaces enable dockerd to communicate with PulseAudio and Wayland compositor sockets located under /run/user/$UID, which is required for certain container workloads that need access to the host audio or graphical display.

Both permissions are wrapped in optional_policy blocks to ensure they are only enabled when the corresponding PulseAudio and Wayland policy modules are present.

This change improves compatibility with containerized desktop applications while preserving modular policy design.

[thesamesam]

I think these may be a tunable candidate.

[ievlogie]

Why tunable? qimsdk docker always needs access to these 2 sockets

[thesamesam]

I don't know what qimsdk docker is. I suggested a tunable because I don't think it's a given that people will want containers to be able to access these.

Please revisit your internal policy as to whether changes like this get upstreamed automatically if only your internal tooling needs it or with some very specific configuration. If it requires some specific use of Docker you rely on, please say that, and we can discuss it.

[kemalrasimsh]

I’ve made this both optional and tunable.

[pebenito]

The wayland interface doesn't exist.

[pebenito]

This should move after the init_systemd block below

[kemalrasimsh]

Done.

[kemalrasimsh]

The Wayland interface is available in the following pull request:
#1166
I'm unsure how to declare a dependency on this PR.

[pebenito]

The Wayland interface is available in the following pull request: #1166 I'm unsure how to declare a dependency on this PR.

You'll need to rebase this PR.

For future reference, the wayland interface commit could have been included in this PR.

[aerusso]

Just saw this---I'm not sure why we would want to use wayland_access_runtime_sock over wayland_client_domain. Generically, I would think that we should get wayland_client working better if for some reason it's inadequate and/or narrow its permissions if they are too broad.

[kemalrasimsh]

You're right that wayland_client_domain() should be the primary mechanism, and I'm not trying to replace it.

The issue I ran into is that wayland_client_domain() only assigns the wayland_client attribute, but it doesn't grant access to the Wayland runtime socket (wayland_runtime_t:sock_file). That seems intentional, since the policy assumes clients interact with Wayland over already-established FDs rather than directly touching the socket inode.

In the container/CDI case, though, we're bind-mounting /run/wayland-0 into the container, so the runtime (runc under dockerd_t) ends up needing filesystem-level access to the socket. That results in AVCs like { ioctl } on wayland_runtime_t:sock_file, which aren't covered by the existing client attribute rules.

So instead of broadening wayland_client_domain() (which would affect all clients), this keeps the extra permissions explicit and opt-in for domains that actually need to interact with the socket at the file level (like container runtimes).

If the preference is to improve upstream policy instead, another option would be:

• either extend wayland_client_domain() to optionally cover socket file access
• or introduce a more narrowly scoped upstream interface for runtime socket access

but given the Wayland model, I thought keeping this separate was safer and more precise.

[pebenito]

kemalrasimsh commented:

You're right that wayland_client_domain() should be the primary mechanism, and I'm not trying to replace it.

The issue I ran into is that wayland_client_domain() only assigns the wayland_client attribute, but it doesn't grant access to the Wayland runtime socket (wayland_runtime_t:sock_file). That seems intentional, since the policy assumes clients interact with Wayland over already-established FDs rather than directly touching the socket inode.

In the container/CDI case, though, we're bind-mounting /run/wayland-0 into the container, so the runtime (runc under dockerd_t) ends up needing filesystem-level access to the socket. That results in AVCs like { ioctl } on wayland_runtime_t:sock_file, which aren't covered by the existing client attribute rules.

So instead of broadening wayland_client_domain() (which would affect all clients), this keeps the extra permissions explicit and opt-in for domains that actually need to interact with the socket at the file level (like container runtimes).

If the preference is to improve upstream policy instead, another option would be:

• either extend wayland_client_domain() to optionally cover socket file access
• or introduce a more narrowly scoped upstream interface for runtime socket access

but given the Wayland model, I thought keeping this separate was safer and more precise.

@aerusso any further response to this?

[aerusso]

@pebenito I need to look at this more closely. I had not originally appreciated the already open distinction (and I want to look at what is going on in my own policies). My first thought is we may want to have an "open new connections" and wayland_client_domain interface. I do feel like everything that's a client should at least be wayland_client_domain, but again I need to think about this more carefully.

@kemalrasimsh Thanks for clarifying!