[pulseaudio-discuss] [PATCH 0/2] access-control prototype

[Wim Taymans]

Hi all,

I've been experimenting with adding access control to pulseaudio and I would 
like to start the discussion and propose some ideas with the attached patch
set.

With the current pulseaudio policy, once the app has made a connection with the
daemon, it can perform any action it wants. This includes inspecting the state
of the various objects but more problematically, the client is allowed to
change the volume of any stream or sink/source or even kill any stream in the
daemon. Any client is also allowed to start capturing from any of the sources
or even the monitor sources of other streams. This is not something we want to
allow in all cases without explicitly asking the user first.

The primary use case for access control is sandboxed apps where we want to
restrict the actions that the sandboxed app can perform on pulseaudio. We
currently bind mount the pulseaudio socket in the sandbox and let the clients
use that to communicate over the native protocol with the pulseaudio daemon 
[1]. This is the only way to communicate with pulseaudio, so the cli protocol
and other protocols are disabled and excluded from this discussion.

Pulseaudio was not designed and built with access control in mind from the
start. Adding full control at the lowest level is probably not feasable at this
stage, and I believe it is not really needed. Instead, I've experimented with
blocking access at the protocol-native level [2]. 

With the native protocol, there are about 39 interesting actions that a client
can perform. These roughly map to the pa_context, introspection, sample cache
and pa_stream API. The idea is to fire a hook for each of these commands to
check if the object being operated on can be seen/modified by the requesting
client. The implementation of these checks happens in modules that can
implement whatever policy is needed by connecting to the various hooks. This
makes for some simple extra additions in protocol-native.c

For the subscribed events, we need to be carefull that we don't send events to
clients about objects that the client is not allowed to see, like an
input_stream of some other client, if the policy does not allow that. It's a
little tricky because with the REMOVE event, we can't get to the original
object anymore (to check who the owner was, for example). This can be solved by
keeping a list of all the events sent to a client about what objects, as is
implemented in [2].

There are more actions in the pa_stream object but I believe it is not very
useful to control access to those. Those actions are about configuring the
stream attributes and get status information about the streams. I believe it is
sufficient to allow or deny the creation of the pa_stream and after that, you
are free to use all pa_stream actions on that stream. again, moving the stream
to another sink is something that can be blocked, if needed because it is not
an action on the pa_stream.

What we eventually might want to do is ask the user for permission before a
potentially dangerous action is done (record from a source, switch
sinks/source,...). The idea is to let the access module call into a dbus api
that will handle the user interaction and tells us what to do next. We would
then also need to store those results in a database so that we don't have to
ask for permission every time. I'm not sure we can block those protocol-native
calls while waiting for the user or if we have to make them async on the server.

[2] contains a simple example access module that has some hardcoded checks on
input/output sink/source to see if the streams belong to the client that
created them. This essentially makes each client only see its own streams and
disallows any action on a stream that's not from the client. The idea is to do
different checks based on the user/cgroup/... a process is executed under,
possibly configured with a config file somehow.

What do you think? I would love to hear your ideas.

[1] https://wiki.gnome.org/action/info/Projects/SandboxedApps/Sandbox
[2] http://cgit.freedesktop.org/~wtay/pulseaudio/log/?h=access-hooks

Wim Taymans (2):
  access: add access control hooks
  module-access: make policy object containing rules

 src/Makefile.am                 |   8 +
 src/modules/module-access.c     | 354 ++++++++++++++++++++++++++++++++++++++++
 src/pulsecore/access.h          |  98 +++++++++++
 src/pulsecore/core-subscribe.c  |   2 +-
 src/pulsecore/core.c            |   5 +
 src/pulsecore/core.h            |   3 +
 src/pulsecore/protocol-native.c | 152 +++++++++++++++++
 7 files changed, 621 insertions(+), 1 deletion(-)
 create mode 100644 src/modules/module-access.c
 create mode 100644 src/pulsecore/access.h

-- 
2.1.0