[pulseaudio-discuss] More on the native protocol complexity

[Lennart Poettering]

On Fri, 23.04.10 13:36, Rafal Wojtczuk (rafal at invisiblethingslab.com) wrote:

> Hello,
> On Apr 5, Lennart wrote (about native protocol):
> > Note that the protocol is kinda complex, both because it grew
> > historically and because some parts have to be complex. i.e. the
> > timing/flow control logic is non-trivial. Reimplementing that won't be
> > fun.
> >
> > tbh I don't think the native protocol while it works quite well these
> > days is something that deserves to be reimplemented by other projects.
> 
> The problem is that for some tasks the complexity of the native protocol is
> prohibitive. Consider the following scenario (that I am trying to solve
> now):
> There are two [virtual btw] machines, VM_USER and VM_HOST. We want to allow
> users in VM_USER to play sound on the soundcard attached to VM_HOST. So, the
> obvious method is to run pulseaudio daemon in VM_HOST, and prepare client.conf 
> in VM_USER so that it connects pa clients to VM_HOST over the network. However,
> VM_HOST does not want to trust VM_USER more than necessary. VM_HOST does not
> want to give VM_USER full access to the native protocol capabilities (like
> PA_COMMAND_LOAD_MODULE), nor to give it a chance to exploit a potential bug 
> (logic one, or buffer overflow) in this 150K C-code protocol.

PA does not do any access control on anything beyond on the connections
themselves. (With one exception: for uses in the system-wide stuff you
can switch off module loading after startup with
--disallow-module-loading. In fact that switch is enforced nowadays if
you enable system mode, IIRC).

It's a bit like X in that area: once you are connected you get full
access. And I belive that makes sense, as this is not really software to
be exposed on the internet, and adding a full access control layer would
add a massive and complex code piece I really don't want to
maintain. Especially since I don't want to guarantee that that kind of
access control would be enforced everywhere and properly. Or in other
words: I don't want to make a promise that I cannot really keep and
would mean a lot of work for something unnecessary on most setups.

I have been advocating not to use the system-mode of PA, unless folks
have a very good reason, precisely due to things like this.

So, I said it many times and I say it again: you really want to make
sure that client and server can trust each other. The PA protocol is not
suitable as a security isolation for audio apps.

Note that I don't really say all this lightly. For the record,
avahi-daemon (which I mostly wrote), is still the only software on
modern distributions that is installed by default and by default
chroot()s itself for security reasons. It also uses Linux capabilities
to minimizes its security impact. Avahi is probably still one of the
safest daemons in Linux distro default installations you can find these
days ;-). I have thought doing something similar for PA when running it
in system mode. However, that really doesn't work, because PA is
highly extensible and uses a lot of libraries that are hard to
oversee. The number of holes one would have to punch in a security jail
such as chroot() would make the whole story moot. Systems like SELinux are
probably better way to secure things here.

> A solution acceptable from VM_HOST's point of view on security is:
> 1) Load module-simple-protocol-tcp in VM_HOST
> 2) Run pulseaudio daemon in VM_USER (and make users connect to it, instead
> to VM_HOST). Load module-pipe-sink, and pass the pipe output over the network 
> to port 4711 in VM_HOST (to module-simple-protocol-tcp code).

That is not workable, as this provides no timing info at all. Video will
be jumpy, and with uncontrolled latencies.

> Anything else I could try ?

Yes: jail PA in some security framework. Make it drop privs. Use SELinux.

> > timing/flow control logic is non-trivial. Reimplementing that won't be
> > fun.
> Yeah.
> But in this particular example (particular e.g. because we can assume near 0
> network latency), can someone figure out some better configuration, based on
> module-simple-protocol-tcp+module-pipe-sink or anything else that does not
> involve a complex protocol, but achieves good synchronization ? 

Well, what I usually suggest to thin client people is to use some
security framework to limit the impact what PA could do if some rogue
user manages to exploit it. At the very least disable module loading and
make it drop privs, as the system mode will do for you. And then, each
time a different user connects make sure to restart PA and erase its
state files in the FS.

Something similar applies to X, as the X protocol is even more complex
(though probably better known and understood).

> Alternatively, is it possible to quickly estimate how many of 90 PA_COMMAND_* 
> functions in protocol-native.c are required to be implemented to allow 
> simple playback only ? Maybe it would be possible to implement
> simplified-native-protocol.c, or sanitize incoming packets before passing
> them to pulseaudio.

Probably not too many of those commands are necessary of basic
clients. The majority is used exclusively by software like pavucontrol.  

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4