[pulseaudio-discuss] More on the native protocol complexity

[Rafal Wojtczuk]

On Fri, Apr 23, 2010 at 05:35:14PM +0300, Tanu Kaskinen wrote:
> On Fri, 2010-04-23 at 13:36 +0200, Rafal Wojtczuk 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.
> 
> How about getting a cheap or free used computer running pulseaudio that
> you hook the speakers to? Then use that via TCP from VM_USER. 
Yes, almost good (although in the case of Xen/Qubes environment, you would say 
"dedicated driver domain" instead of "a cheap or free used computer").

Readers interested in pulseaudio discussion only are kindly advised to jump
to the 7th line from the bottom of this post.

> That way you don't need to run pulseaudio on a top security machine.
So, you have a third VM_PULSE [virtual] machine, that hosts the sound hardware 
and the pulseaudio daemon. This is definitely better. The problem arises 
when there are VM_USER1 and VM_USER2 machines, that both want to use sound. 
Now, if you accept that 
[*] "talking over native protocol" equals "unacceptable risk of getting 
compromised" 

then it means that you have to consider a scenario when
a) because of [*], rogue VM_USER1 can execute arbitrary code in context of 
pulseaudio daemon on VM_PULSE,
b) rogue pulseaudio daemon can wait for VM_USER2 to connect to it, and again
because of [*] (although now considering an attack against client side of
native protocol conversation) compromise VM_USER2

This is not good, VM_USERx machines should not be able to compromise each
other. 

> That way you don't need to run pulseaudio on a top security machine.
Yes, but the machine running pulseaudio may interact with other machines of
high security status, thus it is important to not make its security too weak.

Again, can I have a simple sound sharing over network protocol, pretty
pretty please ? Raw audio frames + simple synchronization, anyone ?

Regards,
Rafal Wojtczuk
The Qubes OS Project
http://qubes-os.org