[pulseaudio-discuss] System mode and SHM-memfd

[Ahmed S. Darwish]

Hi!

On Sun, Aug 27, 2017 at 11:15 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
>
> On Wed, 2017-08-23 at 19:38 +0300, Lauren?iu Nicola wrote:
> > Hi,
> >
> > The 9.0 release notes mention memfd as a SHM transport variant that can
> > make Pulseaudio perform better when running in the system mode, but the
> > implementation seems to disallow it [1].
> >
> > I'm wondering if there still are plans to make this work.
>
> There hasn't been any decision to not make it work, but it seems
> unlikely that anyone will actually do the work.
>
> Ahmed Darwish was the one who implemented the memfd transport and he
> was interested in improving the system mode, but he hasn't been active
> lately. I added him to Cc in case he wants to comment.
>

Exactly. The ambitious long-term vision was to make PulseAudio run
in system mode by default. This was for multiple reasons:

  1) Running PA in user login context makes a number of important use
  cases completely unfeasible. Basically the case when you want to
  consider your whole machine as an audio sink over the network, and
  not different _incompatible_ PA instances per users login and exit.
  Check this long discussion on the systemd list for more details
  http://article.gmane.org/gmane.comp.sysutils.systemd.devel/33574

  2) The Linux desktop world is moving to containers anyway, and
  thus PA security needs to be done at the fine-grained level of each
  client connection rather than at the primitive level of users and
  UIDs.

And if we achieve "(2)" above, then it would be secure to use SHM
in system mode, since the same mechanisms used for protecting PA
clients from each other will be re-used as is. It wouldn't matter
if the apps under same or different UIDs :-)

Problem is, unlike what Apple correctly did with its Core Audio
services and APIs, PulseAudio completely ignored the inter-client
security question. Its original design basically said, "the server
and all its clients run under the same UID; cool, security issues
solved".

Ten years later, this design decision proved fatal: there are
inter-client security pain points across the whole PA stack. I've
summarized these problems here:

  https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/AccessControl

Some of these issues were tackled by a proposed (now discontinued)
access control layer to pulse by Wim Taymans, RedHat, for better
Flatpak integration. Like memfds, this was also another "necessary,
but not yet sufficient" part of the intractable PA security puzzle.

Why? Because even if we got the access-layer merged, pulse uses a
global mempool to pass recorded audio from server to clients, and
for other small use-cases. And this global mempool is touched
*almost everywhere* in the code base -- including quite esoteric
and hard to debug modules. There were some plans to fix this, in
an incremental manner, here:

  https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-February/025477.html

And if that was fixed, we still have another thorny issue: due to
pulse "rewinds" design, any PA client, sandboxed or not, and even
after merging access-control, can _reliably_ induce the kernel to
kill the pulse daemon through normal and perfectly legal requests
-- effectivey causing a global denial-of-service attack. I've
written a sample of these legal but malicious clients here:

  https://github.com/a-darwish/malicious-pulseaudio-clients

And that's why the pulse community does not encourage system mode
and especially system-mode SHM to this day; except in very special
cases like Yocto and OpenEmbedded-based devices. If the above
mentioned problems are to be fixed, then activating system-mode
SHM can be done safely.

On having any plans to fix this, as Tanu said, I've been a bit
inactive after getting memfds and its stability fixes merged:
have been in the process of moving to Germany, which includes all
the fun stuff of searching for a new home, job, etc. ;-) And it
seems Wim's approach now is to create a new audio/video server
replacing PulseAudio, which will handle all the security questions
mentioned above from _day zero_, while maintaining compatibility
with pulse APIs:

  https://github.com/PipeWire
  https://blogs.gnome.org/uraeus/2017/09/19/launching-pipewire

IMHO, the above *is the only sane approach now* for solving the
intractable PA security problem.

So, short answer after this long message: no, it seems no one is
going to solve this at the PA level anymore. Wait for pipewire,
or manually enable this in the code base at your own risk.

All the best,

-- 
Darwish
http://darwish.chasingpointers.com