What is more secure, apulse or PipeWire?

[adrelanos]

For attack surface reduction, security hardening... What is more secure, apulse or PipeWire?

[paulmenzel]

I think, you need to be more specific about the threat model.

[adrelanos]

Thank you for asking!

A) The "simple" "threat model": Applications processing untrusted input (such as web browser, media players) getting exploited due to some specifically crafted audio with the intent to accomplish remote code execution. For example -> web browser -> video -> remote code execution. Or another example: download video -> vlc -> local code execution.

B) The "advanced" "threat model": Local privilege escalation. Already locally running malware attacking apulse / PipeWire to gain additional privileges, most interestingly root rights.

[keithbowes]

Hm. I just hope apulse doesn't blow up speakers like PipeWire does. The distro I use claims it's going to switch to PipeWire in the next version (I tried it in the current version (in which it's available but not the default) just to get ahead in the game, but that apparently was a mistake; it never occurred to me that PipeWire would do that), so I'm proactively working to get everything that can use ALSA directly to do so and things that can't to use apulse, because I don't want my headphones to blow up too, especially when I'm wearing them. That's the biggest threat I can think of.

Now about your ideas of threats, they seem a bit like paranoid fantasies. Who's going to take the time make malicious audio streams for various sound setups? B sounds especially unlikely, as neither apulse nor PipeWire runs as root (in fact, part of my preparation for the switch to PipeWire has been to make the PipeWire/WirePlumber symlinks in ~/.config/systemd/user (from my aforementioned attempt to use PipeWire) point to /dev/null; I hope that's enough to disable it when the distro I use makes the switch; yes, I know I could switch to a distro that doesn't use it, which might indeed be an option come upgrade time); it would most likely be ALSA that would be the attack vector, regardless of which sound server (or emulation thereof) you're using.

[i-rinat]

I'm not sure about PipeWire's client libraries, but since the server can pretend to be a PulseAudio server, applications can still use PulseAudio's client libraries. And those are in theory easier to sandbox. All communications with a sound server happens over sockets, so an app may just forbid any other unrelated syscalls. While if an app uses ALSA directly, it has to be able to do ioctls on device files. It's still possible to filter specific parameters of ioctls. But as far as I know, ALSA's APIs are specified in terms of its library interface, not ioctl parameters. So figuring out how to write a sane filter will involve a lot of research and engineering.

As for apulse, it doesn't provide additional access to anything, so it should not increase attack surface in that sense. However since the library is loaded into the address space of an application, it may introduce exploitable bugs like buffer overflows. There is also a possibility of users manually turning off security features of applications to make them work with apulse.