refpolicy-targeted: add Qualcomm-specific PipeWire SELinux support by rchiluka29 · Pull Request #2013 · qualcomm-linux/meta-qcom

rchiluka29 · 2026-04-21T13:04:31Z

Introduce a new SELinux policy module 'pipewire_stack' to confine the
PipeWire multimedia daemon and its associated runtime under a dedicated
least-privilege domain.

Changes include:

pipewire_stack.fc: File context definitions for PipeWire executables,
configuration, shared data, runtime sockets, and persistent state
under /usr/bin, /etc/pipewire, /usr/share/pipewire, /run/pipewire,
and /var/lib/pipewire respectively.
pipewire_stack.if: Interface file stub for the pipewire_stack policy
module, reserved for future cross-module interface definitions.
pipewire_stack.te: Type enforcement policy for the pipewire_t domain
covering:
- Process control: fork, signal handling, and scheduling (sys_nice)
  for low-latency audio operation
- Runtime socket and directory management under /run/pipewire
- ALSA sound device access (sound_device_t)
- DMA device access (dma_device_t) for hardware audio offload
- Shared memory (tmpfs/memfd) for zero-copy audio buffer handling
- PulseAudio runtime compatibility (/run/pulse probing and PID file
  management)
- sysfs and procfs read access for hardware discovery
- System logging via syslog and systemd journal
- Suppressed audit noise for expected /proc scan denials via
  dontaudit rules

Anuj Mittal (anujm1) · 2026-04-22T01:21:07Z

+  - Suppressed audit noise for expected /proc scan denials via
+    dontaudit rules
+
+Upstream-Status: Inappropriate [Qualcomm specific change]


Why/How is it Inappropriate and Qualcomm specific?

This looks quite generic to me.

Updated the commit message and patch.

pipewire_stack.fc contains two Qualcomm-specific device node labels (/dev/aud_pasthru.* and /dev/msm_audio_mem.*) which are AudioReach ADSP communication devices present only on Qualcomm platforms

Dmitry Baryshkov (lumag) · 2026-04-28T12:12:47Z

+/dev/aud_pasthru.* (AudioReach GPR passthrough) and
+/dev/msm_audio_mem.* (AudioReach shared memory allocator) are not
+present on non-Qualcomm platforms and are not suitable for upstream
+refpolicy]


Please split this into logical changes. AudioReach-specific changes should go to meta-audioreach.

I did split the changes. This pr contains the generic changes. shall I raise for audioreach-specific changes in other PR ?

The audtioreach-specific changes should go to meta-audioreach.

But, in meta-audioreach (https://github.com/Audioreach/meta-audioreach), we don't have selinux related things right ?

Right. But nothing stops you from adding the dynamic layer there.

Dmitry Baryshkov (lumag) · 2026-04-28T12:14:06Z

+/run/pipewire(/.*)?                     gen_context(system_u:object_r:pipewire_run_t,s0)
+
+# --- Persistent state ---
+/var/lib/pipewire(/.*)?                 gen_context(system_u:object_r:pipewire_var_lib_t,s0)


Nothing up to this line is Qualcomm-specific. Should those definitions go to the main repo instead?

Raised PR on main repo: SELinuxProject/refpolicy#1109

Dmitry Baryshkov (lumag) · 2026-05-12T17:06:19Z

No stray merges,

Dmitry Baryshkov (lumag) · 2026-05-18T17:41:06Z

+    with unconfined_t rules wrapped in optional_policy to handle
+    builds where the unconfined module is absent
+
+Upstream-Status: Pending [to be submitted to SELinuxProject/refpolicy]


Please come back when it's at least Submitted (or better, Backport).

Hi Dmitry Baryshkov (@lumag), the upstream refpolicy PR has been submitted and is actively under review here:
SELinuxProject/refpolicy#1109

A note on the evolution of that PR: the initial version was written as a system service using init_daemon_domain, since that matched our deployment model on the Qualcomm platform. The upstream maintainer (pebenito) pointed out that the common case for PipeWire is as a user service, not a system service. I reworked the policy accordingly and the module was moved from policy/modules/services/ to policy/modules/apps/, init_daemon_domain was replaced with userdom_user_application_domain, and all other review feedback has been addressed. Please let me know if you'd like any further changes here.

Please use tunable to support both modes (in the upstream commit). We definitely don't want a separate implementation inside our layer.

Understood. I'll add a pipewire_system_service tunable to the upstream PR so both modes are covered in a single implementation. The tunable will default to false (user service, as requested by pebenito) and when set to true will switch to init_daemon_domain, system runtime paths (/run/pipewire), and system state paths (/var/lib/pipewire). Once that's merged upstream, the Upstream-Status here can be updated to Backport.

Please confirm on this once.

rchiluka29 · 2026-06-04T11:08:13Z

Hi Dmitry Baryshkov (@lumag), the PipeWire SELinux policy PR (SELinuxProject/refpolicy#1109 (SELinuxProject/refpolicy#1109)) is progressing upstream but blocked on user-service validation, which we can't test on our Qualcomm embedded platform. System-service mode is fully tested and working. Since PipeWire is a GA blocker for audio, can we merge the system-service policy internally into meta-qcom while we continue working on user-service validation for upstream?

Dmitry Baryshkov (lumag) · 2026-06-05T13:20:48Z

while we continue working on user-service validation for upstream?

The ETA for such validation? How would you do it? Can't you just validate it on your normal latop, which I assume has PipeWire running as a user service.

rchiluka29 · 2026-07-01T12:27:14Z

Hi Dmitry Baryshkov (@lumag) , upstream Pr #1109 has now been merged into refpolicy main on 2026-06-26. Both user-service and system-service modes have been supported.

This PR has been updated to remove the out-of-tree policy patch and replaced it with only the Qualcomm-specific downstream additions: POLICY_CUSTOM_BUILDOPT for system-service mode and the ADB shell support rules.

And this PR meta-audioreach also updated to label /dev/aud_pasthru.* and /dev/msm_audio_mem.* as sound_device_t.

rchiluka29 · 2026-07-01T12:28:20Z

while we continue working on user-service validation for upstream?

The ETA for such validation? How would you do it? Can't you just validate it on your normal latop, which I assume has PipeWire running as a user service.

validated user-service mode on fedora vm (aarch64) on upstream refpolicy.

Dmitry Baryshkov (lumag) · 2026-07-01T12:35:05Z

+	init_rw_script_stream_sockets(pipewire_t)
+
+	# Allow ADB shell to launch PipeWire client utilities in pipewire_client_t.
+	domtrans_pattern(initrc_t, pipewire_client_exec_t, pipewire_client_t)


I think this means that ADB has wrong context. In the end, ADB shell is the remote shell, logically the same as SSH.

Agreed. But as of now adb is running as initrc_t. This patch is temporary workaround. The upstream maintainer also asked to keep it downstream till proper adb policy done in upstream.

So, you can proceed with the ADB policy, then there would be no need for temporal workarounds.

Dmitry Baryshkov (lumag) · 2026-07-01T12:36:25Z

+PipeWire client utilities (pw-play, pw-record etc.) to transition into
+their dedicated pipewire_client_t domain when launched from ADB shell.
+
+On standard Linux desktops ADB shell is not used, but on Qualcomm


This is not true, ADBd is available e.g. in Debian.

yes, description updated.

Dmitry Baryshkov (lumag) · 2026-07-01T12:40:38Z

-    ${@bb.utils.contains('MACHINE_FEATURES', 'optee', '', 'file://0002-Enable-the-tunable-flag-tee_supplicant_qtee.patch', d)} \
 "
+
+POLICY_CUSTOM_BUILDOPT:qcom = "pipewire_system_service"


Separate commit.

This looks like a decision that should be made by the distro instead (meta-qcom-distro).

Agreed. Raised PR in meta-qcom-distro:
qualcomm-linux/meta-qcom-distro#383

Please have a look at it.

Dmitry Baryshkov (lumag) · 2026-07-01T13:58:12Z

This branch has conflicts that must be resolved

The upstream PipeWire SELinux policy has been merged into refpolicy (SELinuxProject/refpolicy#1109). Set POLICY_CUSTOM_BUILDOPT to pipewire_system_service so that PipeWire runs as a system-wide daemon on Qualcomm embedded targets. Signed-off-by: Chiluka Rohith <rchiluka@qti.qualcomm.com>

rchiluka29 · 2026-07-01T15:37:22Z

Done. Dropped the ADB shell commit. Will raise a proper ADB domain policy upstream as a follow-up.

rchiluka29 · 2026-07-01T15:37:53Z

This branch has conflicts that must be resolved

Rebased on latest commit and cleared merged conflicts.

Ricardo Salveti (ricardosalveti) · 2026-07-02T15:09:21Z

Closing in favor of qualcomm-linux/meta-qcom-distro#383.

rchiluka29 requested review from Anuj Mittal (anujm1), Koen Kooi (koenkooi), Dmitry Baryshkov (lumag), Nicolas Dechesne (ndechesne), Ricardo Salveti (ricardosalveti), sbanerjeeqc and Viswanath Kraleti (vkraleti) as code owners April 21, 2026 13:04

Anuj Mittal (anujm1) reviewed Apr 22, 2026

View reviewed changes

rchiluka29 force-pushed the pipe_policy branch 2 times, most recently from ad3f627 to db231f1 Compare April 28, 2026 11:58

Dmitry Baryshkov (lumag) requested changes Apr 28, 2026

View reviewed changes

rchiluka29 force-pushed the pipe_policy branch from db231f1 to daf6e8e Compare April 30, 2026 14:56

rchiluka29 force-pushed the pipe_policy branch from c146b0c to 9a2c1a3 Compare May 12, 2026 17:30

rchiluka29 requested a review from Dmitry Baryshkov (lumag) May 18, 2026 15:57

Dmitry Baryshkov (lumag) requested changes May 18, 2026

View reviewed changes

rchiluka29 force-pushed the pipe_policy branch from 9a2c1a3 to 3556d5b Compare July 1, 2026 12:10

Dmitry Baryshkov (lumag) requested changes Jul 1, 2026

View reviewed changes

rchiluka29 force-pushed the pipe_policy branch 3 times, most recently from 73e8cc8 to 6e6acae Compare July 1, 2026 13:25

rchiluka29 mentioned this pull request Jul 1, 2026

refpolicy-targeted: Add AudioReach device labels for pipewire_stack AudioReach/meta-audioreach#123

Open

rchiluka29 changed the title ~~refpolicy-targeted: Add SELinux policy for pipewire_stack~~ refpolicy-targeted: add Qualcomm-specific PipeWire SELinux support Jul 1, 2026

rchiluka29 force-pushed the pipe_policy branch from 6e6acae to 843be6e Compare July 1, 2026 15:36

Ricardo Salveti (ricardosalveti) closed this Jul 2, 2026

Uh oh!

Conversation

rchiluka29 commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Dmitry Baryshkov (lumag) commented May 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rchiluka29 commented Jun 4, 2026

Uh oh!

Dmitry Baryshkov (lumag) commented Jun 5, 2026

Uh oh!

rchiluka29 commented Jul 1, 2026

Uh oh!

rchiluka29 commented Jul 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Dmitry Baryshkov (lumag) commented Jul 1, 2026

Uh oh!

rchiluka29 commented Jul 1, 2026

Uh oh!

rchiluka29 commented Jul 1, 2026

Uh oh!

Ricardo Salveti (ricardosalveti) commented Jul 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

rchiluka29 commented Apr 21, 2026 •

edited

Loading