In prioritizing and preparing for RTM, an irc discussion happened today surrounding audio/video playback/recording and I was asked to send something to the list so everyone is on the same page.
Background: App store apps are considered untrusted and it is our mission to
make sure that Ubuntu phone is safe and secure. Our trust model for app store
apps can be defined as[1]:
"Untrusted by the OS: AppStore apps run in a restricted sandbox as defined in
Application Confinement. Reviews of apps can be shallow, but as a result
AppStore apps are considered untrusted. Untrusted applications:
can freely access their own data
cannot access other applications’ data
cannot access user data
cannot access privileged portions of the OS
cannot access privileged APIs, such as Telephony
may access sensitive APIs with user permission, such as Location or Online
Accounts.
are not typically supported by Ubuntu or Canonical
"
Wrt audio/video playback/recording, there are open issues that we must fix so
that we properly honor our trust model:
1. an app being able to spy/eavesdrop on the user behind the scenes
2. an app being able to data mine the device
This boils down to these 4 bugs:
* All SDK applications require access to /dev/binder[2]
* Pulseaudio should integrate with trust-store[3]
* Please provide Ubuntu camera service that integrates with trust-store[4]
* Please integrate mediaplayback binder service with apparmor[5]
Pulseaudio is relatively straightforward since it is a regular Ubuntu service
and so to solve '1', we need to have trust store integration in pulseaudio[3]
for when an app tries to record audio[6]. For '2', pulseaudio needs to use the
libapparmor API to verify the connecting process' apparmor policy allows access
to the specified file[7] (note, need to verify apps can (ab)use pulseaudio in
this manner). The libapparmor calls are small and trust store integration is
understood (once trust session support lands in Mir).
Unlike pulseaudio which runs on Ubuntu and is accessed via standard IPC
mechanisms (and therefore mediated by AppArmor), there are several binder
services that are accessed in process via libhybris. AppArmor does not mediate
binder and apps that use libhybris end up requiring read/write access to
/dev/binder[2] to run at all, which means that a malicious app is in a position
to make raw binder calls on /dev/binder to access any binder services that are
listening. Specifically, these binder services are currently used by Ubuntu
Touch:
* sensors
* media playback
* camera
* (are there any other binder services running that can be accessed via raw
binder calls on /dev/binder?)
The sensors service will be moving out of binder into an Ubuntu service
(great!), but that work is not yet completed. However, the sensors service is
expected to be available to all apps and access to it doesn't break our trust
model.
For the media playback service, we don't have to worry about eavesdropping, but
we do need to be careful about data mining by direct calls through /dev/binder.
I think the best way to solve this is to only allow the media-hub to talk to the
media playback binder service (this is discussed in the bug)[5]. This would
require writing a little bit of the libapparmor API in bionic and a few lines of
code in the media playback binder service to restrict access, but is not
difficult.
For the camera service, to solve the spying problem, we need to have trust store
integration in the camera service[4] for when an app tries to record video.
Because there is no Ubuntu camera service, the trust store integration must
happen in the binder camera service. This would require writing a little bit of
the apparmor API and the trust-store in bionic and then updating the camera
service to use both. Alternatively, an out of process Ubuntu camera shim service
could be written such that the app would talk to the shim service and then the
camera binder service would only allow communications from this shim service
(akin to media-hub and the media playback binder service). This requires a
little bit of the apparmor API in bionic, a few lines of code in the camera
service to restrict access and writing the small shim service.
Going forward past RTM, if we can have Ubuntu-only helpers such that no apps
require access to /dev/binder, then we can simply remove access to /dev/binder
from the policy. If this can't be done or we add new binder services, those
binder services either need to be safe for all to use (ie, like the sensors
service), they should integrate with the trust-store (like may happen with the
camera service) or we restrict access to the Ubuntu service that uses the binder
service (like we propose for the media playback service). It is perhaps possible
to be smarter and use an out of process gateway service that libhybris would
connect to that could act as a trusted helper for any binder services (to work,
this out of process gateway would have to be the one making the calls over
/dev/binder such that the app itself would be denied access to /dev/binder).
Another option is to add AppArmor mediation for binder, but this is a lot of
(unscheduled) work and probably not worth the time when considering when we ship
pure Ubuntu on phones.
[1]http://developer.ubuntu.com/publish/apps/security-policy-for-click-packages/
[2]https://launchpad.net/bugs/1197134
[3]https://launchpad.net/bugs/1224756
[4]https://launchpad.net/bugs/1230366
[5]https://launchpad.net/bugs/1329913
[6]https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1224756/comments/18
[7]https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1224756/comments/19
--
Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
