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

[Tanu Kaskinen]

On Mon, 2015-02-23 at 16:26 +0100, Wim Taymans wrote:
> 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.

Thanks, this would be a great feature to have! I haven't done any
thorough review of the code (and I don't expect to do that any time
soon, since there are many older patches in the queue), but here are
some comments anyway.

> 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]. 

I haven't given up on the idea of adding the permission checks at a
lower, protocol independent level. However, that will probably require
much more work than adding the checks in the native protocol, so it's
reasonable to concentrate only on the native protocol for now. As far as
I can see, this has no effect on any public APIs, so we can implement
protocol independence later, if someone finds the time for working on
that.

> 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.

No, I don't think it's possible to keep the main thread blocked while
waiting for input from the user.

We discussed this topic a bit in IRC today, and I got the impression
that you and Arun have already experimented a bit with asking the user
whether certain operations should be authorized. Arun told that instead
of having just one asynchronous call to the policy module, it would be
easier to implement one synchronous call for "basic checks" and if the
basic checks fail, then an asynchronous call would be made for "full
checks" (interactive). These patches don't contain either approach (only
synchronous hooks are used), and I have trouble understanding what the
problem is and how does introducing one extra call help in any way.
Could you or Arun clarify?

-- 
Tanu