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

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1224756

Title:
  Pulseaudio should integrate with trust-store

Status in “pulseaudio” package in Ubuntu:
  Triaged
Status in “pulseaudio” source package in Saucy:
  Won't Fix
Status in “pulseaudio” source package in Trusty:
  Won't Fix
Status in “pulseaudio” source package in Utopic:
  Triaged

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1224756/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to