Pulseaudio should integrate with trust-store

[Jamie Strandboge]

Currently the 'audio' policy group allows access to pulseaudio which allows apps to use the microphone and eavesdrop on the user. Pulseaudio needs to be modified to use trust-store, like location-service does. Integrating with trust-store means that when an app tries use the microphone via pulseaudio, pulseaudio will contact trust-store, the trust-store will prompt the user ("Foo wants to use the microphone. Is this ok? Yes|No"), optionally cache the result and return the result to pulseaudio. In this manner the user is given a contextual prompt at the time of access by the app. Using caching this decision can be remembered the next time. If caching is used, there should be a method to change the decision in settings.

Targeting to T-Series for now, since the trust-store is not in a reusable form yet.

Original description:
David and the security team (inspired by an observation from Rick) discussed that when recording, pulseaudio should somehow unobtrusively show the user that it is recording. The easiest thing to do would be for pulseaudio to alert indicator-sound which would then turn its icon red (similar to indicator-message turning blue with new messages). Marking 'high' because apps with access to pulseaudio can currently eavedrop on users. If the app is allowed to do networking (the default for apps), then it can ship that information off to a server somewhere.

Note 1, the alert to indicator-sound must happen via the out of process pulseaudio server and not the confined app itself to be effective.

Note 2, we should consider how to enforce this for foreground apps only. Application lifecycle should probably handle this for 13.10 (apps are suspended if not in foreground or if the screensaver is on), but we don't want an app on the converged device to record in the background when the user isn't paying attention. Example eavesdropping attack: start recording only when the screensaver is on (perhaps inhibiting the screensaver during recording would be enough).

<https://wiki.ubuntu.com/AccountPrivileges#Phone>: "On the phone, if an app tries to access your ... microphone ... or video recording, this should be subject to permission. “Video recording” should be separate from “Camera” so that an app does not need two permissions when recording video, one for the camera and one for the microphone. If an app has permission to record video, it should have access to the microphone whenever it is recording video..."

[Jamie Strandboge (jdstrand)]

Adding an indicator-sound task in case there is work to do there to support this. If the API is there already, please mark 'Invalid'.

[Lars Karlitski (larsu)]

I assume by "recording" you mean reading from an microphone source? (I can't imagine any other way to figure out if an application is recording.)

Also, I'm not sure whether turning the icon red is enough to convey "an application is using the microphone". Maybe we can get some design input before implementing this?

By the way, this will most likely be implemented in indicator-sound, not pulseaudio.

[Matthew Paul Thomas (mpt)]

My initial thought is that it would result in a red icon (or whatever) appearing in every Ubuntu screencast that included real-time audio. That seems like a bad idea. If it's okay for a screencast app to record the screen without befouling it first, why shouldn't it be okay for it to record audio too?

[Jamie Strandboge (jdstrand)]

I think the pulseaudio task is valid-- it will certainly need to alert indicator-sound that it is recording, no?

[David Henningsson (diwic)]

There is already possibilities for indicator-sound to get notification when a recording starts/stops.

[Jamie Strandboge (jdstrand)]

David, can you explain? Are you saying pulseaudio already has all the code to alert indicator-sound that it is recording, is using it, but indicator-sound is not responding to it?

[David Henningsson (diwic)]

I don't think there is a need to change PulseAudio, because the required API is already available.

I think indicator-sound is currently using the API to monitor playback, but not to monitor recording.

[David Henningsson (diwic)]

Hmm, maybe indicator-sound is already using that API for recording too, because I remember at some point that the drop-down menu would show the recording gain only when recording was active. If so, it's just a matter of transforming that information to an icon, too.

[Jamie Strandboge (jdstrand)]

I see-- I thought pulseaudio would tell indicator-sound it was recording, but instead indicator-sound is monitoring pulseaudio.

Mathew, this bug is marked 'Incomplete'-- can someone not just turn the indicator red for the time being and then the full design can be fleshed out later? As it stands now, apps can eavesdrop on users without them knowing because of this bug.

[Matthew Paul Thomas (mpt)]

I marked it as Incomplete because nobody has answered my question. Complexity of design is not the issue; I imagine the design would take about 20 minutes.

[Jamie Strandboge (jdstrand)]

Lars, yes the microphone source. Another use case that may be worth considering is video recording-- most of the time it will accompany audio recording, but it is conceivable it video-only recording is possible too.

My initial thought is that it would result in a red icon (or whatever) appearing in every Ubuntu screencast that included real-time audio. That seems like a bad idea. If it's okay for a screencast app to record the screen without befouling it first, why shouldn't it be okay for it to record audio too?

Matthew, screencast (I guess you mean screen capture?) apps are a special case and not supported by Mir or application confinement at this time (ie, no app can perform a screen capture right now on Touch). I'm not sure why it actually is bad that the icon be read in the screen capture (but maybe it is). Looking towards converged, my understanding is that screen capture apps will be trusted, not confined and not available in the app store. IMHO, I think for now we just always adjust the icon (or whatever) to close this bug and then file a wishlist feature request bug to add an inhibit API for the visual cue (or something) that would only be available to trusted and/or unconfined apps. (I can imagine a DBus call in indicator-sound: InhibitRecordingVisualCue and UninhibityRecordingVisualCue-- screen capture apps can use this all they want and appstore apps are blocked from using it). In concrete terms-- for 13.10 implement the visual cue and for 14.04 implement the feature to inhibity the visual cue.

[Matthew Paul Thomas (mpt)]

I meant screencasts as in <http://screencasts.ubuntu.com/>. I posit that having a red icon in every audio+video screencast of Ubuntu Touch would be cringeworthy in exactly the same way as having a screencast utility icon in the panel or menu bar in most 2007~2012-era Ubuntu screencasts was cringeworthy. Because audio recording and screen recording often go together, it is important that both of them be invisible during the recording.

I suggest instead that access to the microphone be something that the system requires run-time confirmation of, in the same way that it requires confirmation of access to location or contacts. That wouldn't require any new APIs *or* any work in indicator-sound.

[Matthew Paul Thomas (mpt)]

Specification updated. <https://wiki.ubuntu.com/AccountPrivileges?action=diff&rev2=13&rev1=12>

[Matthew Paul Thomas (mpt)]

I think this is an accurate summary of the discussion on IRC:

1. There should be a run-time prompt the first time an app tries to use the microphone, just as there is for other sensitive properties. In future there should be a similar prompt for the camera (bug 1230366).

2. In addition, there should be a reminder whenever a background app is using the mic, e.g. a Voip client when you've switched to your calendar to discuss an event, so that you don't forget the mic is live. Again, the same is true for the camera. (Trusted screencast utilities might be granted exceptions.)

3. Because both of these apply to just as much to the camera as the mic, and they will often happen together, they should share UI. In the prompt case, that means the prompts for both should be aggregated. In the reminder case, it means the sound indicator isn't an appropriate home for it.

4. Much the same issue is already faced by the phone app: when you switch to another app during a call, you need both a reminder that you're on a call, and a way of switching back to it. Other apps using the mic (and/or camera) should use the same UI mechanism as the phone app does, not least because they will often be Voip clients doing the same job as the phone app. Unfortunately the design for that reminder is not yet finalized. The current draft is a temporary separate indicator.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ricardo Salveti (rsalveti)]

David, while I don't see the need to change Pulse in order to be able to notify the user that a recording is in place, how should we proceed on the trusted helper side (the user prompt, such as "Foo wants to use the microphone. Is this ok? Yes|No")?

[David Henningsson (diwic)]

For the broader concept of PulseAudio and security, the native protocol of PulseAudio was not built with security in mind, if you by security mean that some connected clients should be able to do some things, and other connected clients should be able to do other things. Right now, as soon as you have a connection to the server, you can do everything from recording audio to mute other applications.

Implementing a limited client in PulseAudio is of course possible, but needs quite a bit of work, and lots of careful thought not to leave anything open security wise.

I haven't been following the discussions around the Touch security stuff much, and I don't know what trust-store is. So maybe I would need some introduction, and then we need to brainstorm a bit on the topic and see what we come up with?

[Jamie Strandboge (jdstrand)]

I think implementing a limited client is a good midterm goal, but not something for rtm. For rtm I think the most important workflow is achieving mpt's point '1' in comment #14. Ie:
 * app tries to record audio
 * at that point, pulseaudio uses lp:trust-store to see if the user said this app can record audio. If user said 'no' in the past, then don't allow, if user said 'yes', then allow, if user never specified, then prompt using trusted session

Complete isolation between apps is a great goal. I think we can live with an app abusing muting other applications (though it would be good if the dialer could never be muted by another app to make sure emergency calls aren't blocked...). The most important thing in my mind from a security POV is an app silently being able to eavesdrop/spy on the user, which is the case now. With trust-store support, the user will know the app can/will record audio. Ideally we would also have mpt's point '2' in place too so the user is aware that recording is happening.

As for '3', the new camera service will do the same thing as pulseaudio for '1' and ideally '2'.

[Jamie Strandboge (jdstrand)]

There is one other adjustment for pulseaudio that came up today. If an app is able to handle a file name to pulseaudio (ie, the app process doesn't have to open it first but instead tells pulseaudio to open and play a file), then pulseaudio should also have apparmor integration for playback in addition to trust-store integration for recording. Fortunately, libapparmor makes this easy-- pulseaudio just needs to get the connecting process' apparmor label (profile name) via libapparmor, then make another libapparmor call to ask if a process running under this apparmor label is allowed to access the file that the app process specified.

[Jamie Strandboge (jdstrand)]

Something that occurred to me-- for devices that ship LEDs, maybe pulseaudio could turn on the 'record' LED (ie, the red one) when performing audio recording?

[David Henningsson (diwic)]

So, I guess one could insert a check in the call to command_create_record_stream (src/pulsecore/protocol-native.c), that would deny access if trust-store says so.
However, there is still a way around that. Any app that can access the shm file can potentially look at audio data currently streaming to *another* app, i e, malicious app Eve can see what PulseAlice sends to the legitmate app Bob.
I'm not sure how much this SHM file is cleaned up (zeroed out) either, so there is a possibility the shm file contains old recorded data too.

As for PulseAudio clients telling PulseAudio to access random files on the file system, I don't think that's true, but I could have missed something. Could you be more specific about where this functionality lies and I'll have a closer look?

As for the LED, any app with access to both the LED and PulseAudio should be able to do this.

[Jamie Strandboge (jdstrand)]

"So, I guess one could insert a check in the call to command_create_record_stream (src/pulsecore/protocol-native.c), that would deny access if trust-store says so."

Yes. I'm told that the latest in the lp:trust-store API turns this into ~10 lines of code (location-service will have the first example that can be looked at).

"However, there is still a way around that. Any app that can access the shm file can potentially look at audio data currently streaming to *another* app, i e, malicious app Eve can see what PulseAlice sends to the legitmate app Bob.
I'm not sure how much this SHM file is cleaned up (zeroed out) either, so there is a possibility the shm file contains old recorded data too."

Yes, but lets leave that to bug #1224751. We definitely want to clean up the SHM files, but I'm guessing this will be a longer term goal and I think this is mostly mitigated by application lifecycle on the phone since only the foreground app is allowed to run. It would be good for someone to look at the SHM file to make sure it didn't have previously recorded data.

"As for PulseAudio clients telling PulseAudio to access random files on the file system, I don't think that's true, but I could have missed something. Could you be more specific about where this functionality lies and I'll have a closer look?"

Ah, I was told this *may* be true and so I was stating in the bug that *if* it is true, then we need the additional apparmor integration. If it is not, then we don't. Based on your assessment, it sounds like it is not true.

"As for the LED, any app with access to both the LED and PulseAudio should be able to do this."

I think I wasn't clear-- apps currently don't have access to the LEDs, so I was thinking pulseaudio could potentially add this itself so the user had a visual cue that recording was happening (and said cue is outside of the app's control). This comment was intended for the design team-- I think we need design input before anyone implements this (not to mention, something in platform api that things like pulseaudio could use-- AFAIK, right now it is manipulating values in /sys. We would want to have a proper library for pulseaudio to use).

[Raymond (superquad-vortex2)]

as pulseaudio allows two or more client perform capturing/playback at same time , you need same mechanism as pulseaudo allow application which play digital passthrough with spdif device exclusively

[Olli Ries (ories)]

this bug needs to be targeted after RTM, via ota

[Jamie Strandboge (jdstrand)]

I understand the desire to push this to ota and also understand that people are busy, but I want to restate how important this bug fix is-- users need to know if an application is able to record them, otherwise it is all to easy to end up with eavesdropping applications in the store.

I am not saying that we should change Olli's assessment for ota-1, but I am saying it really, *really* needs to happen then and not slip past ota-1.

[Pat McGowan (pat-mcgowan)]

moved to ww03

[Jim Hodapp (jhodapp)]

I would go one step further with the proposed indicator method of letting the user know when an app is recording audio. I would have the indicator-sound icon change to an image of a microphone (or even pop up a new icon) and set the color as red. This would be much more self-evident that recording is taking place than just a red speaker (the first thing that I would think if I saw that without knowing what it meant was that something was broken with my audio).

[Ricardo Salveti (rsalveti)]

Please move this to ww21.

[Jamie Strandboge (jdstrand)]

Can this be prioritized higher than it currently is? It keeps getting pushed back and it was supposed to land before any phones were shipped. The lack of this feature leaves us open to privacy issues since apps can record audio without the user knowing.

[John McAleely (john.mcaleely)]

This has clearly been around a while. Some way up, a '10-liner' was suggested as an option. Two questions:

 - is there a good example of this somewhere else to look at (ie, how-to use lp:trust-store)?
 - is the 10 liner (check if record is permitted) still an incremental improvement?

[Ricardo Salveti (rsalveti)]

Basically we need to change pulseaudio in a way it can ask trusty store for the right permission when starting the recording process. Please ping tvoss to know more about how that can be done at the trust-store level, since there are some examples in the trust-store project.

[John McAleely (john.mcaleely)]

diwic will take a look at this in a couple of weeks, when he returns from vacation.

[John McAleely (john.mcaleely)]

This is in silo 30 as I type, blocked by bug #1483752

[Jamie Strandboge (jdstrand)]

Should bug #1230391 be revisited now that this is landing (show a visual cue if background recording)?

[John McAleely (john.mcaleely)]

certainly. is there actually any way to *do* background recording, in the
current app lifecycle?

On 14 August 2015 at 19:23, Jamie Strandboge <email address hidden> wrote:

> Should bug #1230391 be revisited now that this is landing (show a visual
> cue if background recording)?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1224756
>
> Title:
> Pulseaudio should integrate with trust-store
>
> Status in Canonical System Image:
> In Progress
> Status in pulseaudio package in Ubuntu:
> In Progress
>
> Bug description:
> Currently the 'audio' policy group allows access to pulseaudio which
> allows apps to use the microphone and eavesdrop on the user.
> Pulseaudio needs to be modified to use trust-store, like location-
> service does. Integrating with trust-store means that when an app
> tries use the microphone via pulseaudio, pulseaudio will contact
> trust-store, the trust-store will prompt the user ("Foo wants to use
> the microphone. Is this ok? Yes|No"), optionally cache the result and
> return the result to pulseaudio. In this manner the user is given a
> contextual prompt at the time of access by the app. Using caching this
> decision can be remembered the next time. If caching is used, there
> should be a method to change the decision in settings.
>
> Targeting to T-Series for now, since the trust-store is not in a
> reusable form yet.
>
> Original description:
> David and the security team (inspired by an observation from Rick)
> discussed that when recording, pulseaudio should somehow unobtrusively show
> the user that it is recording. The easiest thing to do would be for
> pulseaudio to alert indicator-sound which would then turn its icon red
> (similar to indicator-message turning blue with new messages). Marking
> 'high' because apps with access to pulseaudio can currently eavedrop on
> users. If the app is allowed to do networking (the default for apps), then
> it can ship that information off to a server somewhere.
>
> Note 1, the alert to indicator-sound must happen via the out of
> process pulseaudio server and not the confined app itself to be
> effective.
>
> Note 2, we should consider how to enforce this for foreground apps
> only. Application lifecycle should probably handle this for 13.10
> (apps are suspended if not in foreground or if the screensaver is on),
> but we don't want an app on the converged device to record in the
> background when the user isn't paying attention. Example eavesdropping
> attack: start recording only when the screensaver is on (perhaps
> inhibiting the screensaver during recording would be enough).
>
> <https://wiki.ubuntu.com/AccountPrivileges#Phone>: "On the phone, if
> an app tries to access your ... microphone ... or video recording,
> this should be subject to permission. “Video recording” should be
> separate from “Camera” so that an app does not need two permissions
> when recording video, one for the camera and one for the microphone.
> If an app has permission to record video, it should have access to the
> microphone whenever it is recording ...

[Jamie Strandboge (jdstrand)]

Both pulseaudio and the camera service processes are out-of-process from the app and therefore not themselves governed by app lifecycle. If app lifecycle made sure to stop recording of audio and/or video when the app is backgrounded, then a visual cue is arguably not required (see my note below). If recording is not stopping when the app is backgrounded, we need to let the user know (eg, like what we do with the dialer now). Either route is fine from a security perspective, however, allowing the continuation of recording in the background with a visual cue might provide more utility.

Note: I personally feel we should be giving a visual cue (even if its temporary (consider full screen app)) when any recording is happening-- this is subject for debate and needs design input.

[John McAleely (john.mcaleely)]

Responded to #36 on bug #1230391

[Andrey Skvortsov (skv)]

Hi, I see the bug is closed and bugfix is released. There was bounty for fixing this bug.
Person who fixed the issue, can claim to bountysource.com to get money. The amount is small, but still.

https://www.bountysource.com/issues/3820281-pulseaudio-should-integrate-with-trust-store