camera-app needs access to shared pipe

Bug #1337582 reported by Jim Hodapp
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apparmor-easyprof-ubuntu (Ubuntu)
Fix Released
High
Jamie Strandboge

Bug Description

To be able to send audio data from pulse audio down to the Android side encoder, there is a need for a named pipe that I've put at /android/micshm. The camera-app needs access to be able to write the microphone data to this pipe in the single direction only. This will cross the lxc boundary too, so if there's special considerations for that please take that into account.

Revision history for this message
Jim Hodapp (jhodapp) wrote :

To create the pipe, add this to /etc/init/lxc-android-config.conf:

pre-start script
    mkfifo -m 0777 /android/micshm
end script

It has very liberal permissions on purpose for right now. I'll tighten those up before submitting the feature for review.

tags: added: rtm14
Revision history for this message
Jim Hodapp (jhodapp) wrote :

A simple bash script that can test reading from the pipe

Revision history for this message
Jim Hodapp (jhodapp) wrote :

A simple writer that will write a string to the /android/micshm pipe.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

All that is needed is this (based on these scripts):
 /android/micshm w,

I understand that pulseaudio is on the other end of this pipe, but what is the interface to pulseaudio there? Is this just another way to get at /run/user/*/pulse/native or is this a different interface to pulse? If a different interface, is an app able to (ab)use this interface beyond what is exposed via /run/user/*/pulse/native? Also, if a different interface, trust-store integration (LP: #1224756) will like need to happen at this point as well. Using a well known named pipe also doesn't provide isolation, so in theory two apps would be able to communicate with pulseaudio over this socket and possible interfere with each other. AIUI, pulseaudio is not really designed to provide this level of isolation, but it is an improvement we would like to move towards, so it would be good if we didn't complicate things more here. I'm not sure what the implementation is going to look like, but perhaps there is a way to pass an fd to the app via pulseaudio so that the app doesn't need direct access like this which might simplify the issue of an alternate interface when pulseaudio uses lp:trust-store.

Put another way: if we give unconditional access to /android/micshm to a malicious app (which we would be if adding to the common camera (and possibly audio) policy groups), is that app able to circumvent security by abusing this access to eavesdrop on the user behind the scenes?

tags: added: application-confinement
Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: New → Incomplete
Revision history for this message
Jim Hodapp (jhodapp) wrote :

I think the simple solution here is to add trust store integration to qtubuntu-camera for the recording case and ask the user if they want the app that is making calls to qtubuntu-camera to be able to access the camera and the microphone. We can protect the use of the camera and the mic then from malicious apps and leave it up to the user if an app should have access. Without access to that, the /android/micshm pipe is completely meaningless as the code on the other side won't do anything with any data sent to it without first setting up recording through qtubuntu-camera.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Thanks for your comment, between that and this follow-up discussion on IRC:

13:28 < jdstrand> jhodapp: ok, so, unless there are implementation flaws (which are just bugs that we can fix later on), a malicious app with access to /android/micshm can't do anything to DoS the service or to record in the background, correct?
13:29 < jhodapp> jdstrand: correct, because there technically would be a reader on the Android side always open, but it won't be doing any reads unless triggered by kicking off the recording process

I see no reason to not include /android/micshm in the camera policy group. Trust store integration is being tracked in bug #1230366. Thanks! I'll get this added in apparmor-easyprof-ubuntu 1.2.9 which should be uploaded later today.

Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: Incomplete → In Progress
Changed in apparmor-easyprof-ubuntu (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → High
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor-easyprof-ubuntu - 1.2.9

---------------
apparmor-easyprof-ubuntu (1.2.9) utopic; urgency=medium

  * ubuntu/webview:
    - adjust to allow oxide_render access to WebCore databases (LP: #1339724)
    - adjust for updated path for QML web plugin (LP: #1339777)
  * ubuntu/1.2: add new push-notification-client policy group
  * ubuntu/ubuntu-{sdk,webapp}: adjust for updated path for QML web plugin
  * ubuntu/audio: allow read access for /usr/share/sounds and
    /custom/usr/share/sounds (LP: #1340326)
  * ubuntu/audio: allow write access to /android/micshm (LP: #1337582)
 -- Jamie Strandboge <email address hidden> Thu, 10 Jul 2014 12:28:30 -0500

Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.