ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #08617
Re: Plugging the holes in /dev/binder and audio/video playback/recording
On 06/13/2014 02:55 PM, Jamie Strandboge wrote:
...> 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:
>
...
> * Please integrate mediaplayback binder service with apparmor[5]
...
> 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.
>
So, tvoss and jhodapp looked at the media playback service and it turns out this
is not an issue. The media playback service implements a very small API that
does not include opening files. As such, an app would have to open the file
itself for the media playback binder service to do anything with it, and open is
mediated by application isolation. In other words, the media playback binder
service is not an issue.
> 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.
>
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. We can take further discussions to the bug[4].
...
> [4]https://launchpad.net/bugs/1230366
> [5]https://launchpad.net/bugs/1329913
--
Jamie Strandboge http://www.ubuntu.com/
Attachment:
signature.asc
Description: OpenPGP digital signature
Follow ups
References