Please provide Ubuntu camera service that integrates with trust-store

Bug #1230366 reported by Jamie Strandboge
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Fix Released
Critical
John McAleely
android (Ubuntu)
Fix Released
Undecided
Unassigned
qtubuntu-camera (Ubuntu)
Invalid
Critical
Unassigned
qtubuntu-camera (Ubuntu RTM)
Invalid
Critical
Unassigned

Bug Description

Currently Ubuntu Touch is using the android camera-service and that is the plan for 13.10.

Going forward in 14.04, the android camera-service will no longer be used and camera access is going to move to the Ubuntu side. There was discussion of either using HAL directly (direct access to devices) or using a camera-service type thing in Ubuntu.

Using devices directly causes at least a few problems:
 * can't prevent more than one user from accessing the device at a time
 * enumerating camera devices for apparmor policy is extra maintenance for porters
 * can't provide a contextual runtime prompt for access (like we (will) do with online accounts, location, microphone). This is particularly important for application confinement.

Instead of direct hardware access, an out of process helper (in relation to the app) can be used to address all of these problems, similar to what pulseaudio does for audio. This service can ensure only one user can access the device at a time and since the service accesses the the device files on the app's behalf, we don't need to enumerate devices in /dev in policy. Furthermore, when an app accesses the service (ideally over DBus), the service can contact trust-store, the trust-store will prompt the user ("Foo wants to access the camera. Is this ok? Yes|No"), then optionally cache the result and return the result to the service. In this manner the user is given a contextual prompt at the time of access by the app. By using caching this decision can be remembered the next time. If caching is used, there should be a method to change the decision in system settings.

If direct hardware access is needed for performance reasons, it is possible to use fd delegation in AppArmor and have the service open the device and pass the fd to the app without having to enumerate the /dev devices. Please talk to jjohansen if pursuing this option.

Lastly, bug #1230391 discusses providing a visual cue during background recording for audio. We will need to do the same for video recording. Feel free to add a task to bug #1230391 if there is work to integrate this new service with that visual cuing.

This should be implemented in time for shippable devices to address the application confinement concern.

<https://wiki.ubuntu.com/AccountPrivileges#permission-prompt>: "On the phone, if an app tries to access your ... camera ... or video recording, this should be subject to permission..."

Changed in touch-preview-images:
assignee: nobody → Ricardo Salveti (rsalveti)
tags: added: application-confinement
Revision history for this message
Matthew Paul Thomas (mpt) wrote :
description: updated
Jim Hodapp (jhodapp)
Changed in touch-preview-images:
assignee: Ricardo Salveti (rsalveti) → Jim Hodapp (jhodapp)
importance: Undecided → High
status: New → Triaged
Changed in qtubuntu-camera (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Jim Hodapp (jhodapp)
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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

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

Per meeting today, integration with lp:trust-store will be needed for RTM. https://lists.launchpad.net/ubuntu-phone/msg08582.html discusses two options. tvoss will follow-up in thread on how to proceed after discussions with jhodapp, etc.

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

From the ubuntu-phone@ thread:
"Based on conversations with tvoss and jjohansen, it sounds like the best course of action is to implement option #2 here: write a shim on the Ubuntu side that apps talk to the binder camera service and have the binder camera service verify the apparmor label (profile name) of the connecting process to limit access to it to only the shim."

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

Sigh, this was not clear. Option #2 is: write a shim on the Ubuntu side that apps talk to. The shim talks to the binder camera service. The binder camera service verifies the apparmor label of the connecting process and rejects all connections not from the shim.

Bill Filler (bfiller)
no longer affects: touch-preview-images
Changed in qtubuntu-camera (Ubuntu):
importance: High → Critical
Jim Hodapp (jhodapp)
tags: added: ota-1 touch-2014-10-23
removed: rtm14
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

I've tweaked the design to solve a problem with video+microphone access. <https://wiki.ubuntu.com/AccountPrivileges?action=diff&rev2=20&rev1=19>

I was trying to solve the problem that an app trying to record video and nothing else (Vine, for example) shouldn't result in two prompts in quick succession, one for camera access and one for microphone access.

The way I originally solved it was to say that if an app tries to access anything while the the permission prompt for something is up, the two prompts should be combined. But that was over-broad: it could have resulted in riders, for example an app that really needed your location trying to access your contacts at the same time, resulting in a single prompt for both. This would be exactly the all-or-nothing choice that the prompt model aims to prevent.

Instead I've special-cased video recording: if you give an app permission to record video, it should automatically have access to the microphone when -- and only when -- it is recording video. If you just give the app access to your camera for still photos, then accessing your microphone should require a separate prompt.

description: updated
tags: added: lorcha
Changed in qtubuntu-camera (Ubuntu):
assignee: Jim Hodapp (jhodapp) → nobody
Changed in canonical-devices-system-image:
assignee: nobody → John McAleely (john.mcaleely)
milestone: none → ww34-2015
Jim Hodapp (jhodapp)
Changed in qtubuntu-camera (Ubuntu RTM):
status: New → Triaged
importance: Undecided → Critical
Changed in canonical-devices-system-image:
status: New → Confirmed
Changed in canonical-devices-system-image:
importance: Undecided → High
status: Confirmed → Triaged
Changed in qtubuntu-camera (Ubuntu RTM):
status: Triaged → Invalid
Changed in canonical-devices-system-image:
assignee: John McAleely (john.mcaleely) → Manuel de la Peña (mandel)
Changed in qtubuntu-camera (Ubuntu):
assignee: nobody → Manuel de la Peña (mandel)
Changed in qtubuntu-camera (Ubuntu RTM):
assignee: nobody → Manuel de la Peña (mandel)
Changed in canonical-devices-system-image:
assignee: Manuel de la Peña (mandel) → John McAleely (john.mcaleely)
Revision history for this message
John McAleely (john.mcaleely) wrote :

This is in silo 30 as I type

Changed in canonical-devices-system-image:
status: Triaged → In Progress
Changed in canonical-devices-system-image:
importance: High → Critical
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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

Revision history for this message
John McAleely (john.mcaleely) wrote :

This is now just waiting for bug #1483752 to land before closing as done.

Changed in android (Ubuntu):
status: New → Fix Released
Changed in qtubuntu-camera (Ubuntu):
status: Triaged → Invalid
assignee: Manuel de la Peña (mandel) → nobody
Changed in qtubuntu-camera (Ubuntu RTM):
assignee: Manuel de la Peña (mandel) → nobody
Revision history for this message
John McAleely (john.mcaleely) wrote :

(#8 has been followed up on the bug mentioned. In short: yes)

Revision history for this message
John McAleely (john.mcaleely) wrote :

(silo 30 landed in the image)

Bill Filler (bfiller)
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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