[pulseaudio-discuss] More on the native protocol complexity

[Rafal Wojtczuk]

On Sun, Apr 25, 2010 at 02:10:49AM +0200, Lennart Poettering wrote:
> 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.
Fair enough.

> Something similar applies to X, as the X protocol is even more complex
> (though probably better known and understood).
Indeed, and in Qubes this is solved (multiple mutually untrusted clients can 
display its windows on a single X server), by inserting a layer of indirection.

>> Anything else I could try ?
> Yes: jail PA in some security framework. Make it drop privs. Use SELinux.
The whole Qubes project is based on assumption that current OS-based 
sandbox solutions (like SELinux) are imperfect, because they can be 
circumvented by a bug in the kernel, and recently it is much more common to
find a bug in the kernel than in reasonable userland. Moreover, even perfectly
sandboxed pulseaudio can still attack its clients, and snoop on your
microphone (spooky, isn't it). So no, this does not fly.

> At RH our approach reagrding audio in VMs is actually to simply use
> virtualized sound cards.
Besides its obvious drawbacks (qemu, that I assume actually emulates the
virtualized sound card, is large and has quite a track of vulnerabilities), 
this naturally does not apply to Xen PV domains

> One of the simplest protocols for audio passing is certainly RTP, and it
> is much better understood than RTMP.  RTP is a very good building block
> for audio systems like the one requested here, and PA in fact has
> support for it in a limited way.
Hmm, I tried loading module-rtp-send in the client and module-rtp-recv in
the server/trusted pulseaudio. The quality of sound was good, for a couple
of seconds; then it deteriorated, with dropouts and high frequencies
dominating. This is repeatable. Nothing relevant in the logs (with 
set-log-level 4), CPU load low; renice -20 on both pulseaudios does not help 
(and it was not needed for perfect sound over the native protocol). Both 
sides pulseaudio-0.9.21-5.fc12.x86_64, connected by Xen vif network. Do I 
miss anything obvious ?

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