ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 10/15/2013 11:08 AM, Michael Zanetti wrote:
> On Tuesday 15 October 2013 10:33:39 Jamie Strandboge wrote:
>> On 10/15/2013 09:24 AM, Florian Felgenhauer wrote:
>>> Hey *,
>>>
>>> for all the paranoids (like me) out there, who guaranties me what Permy
>>> shows me is correct.
>>
>> Nothing really-- it happens to have a project page and the project is open
>> source so you have access to the source, but the source is built by the
>> developer so of course it could be replaced to conceal certain accesses, to
>> misreport or just have legitimate bugs. Because it is open source, you are
>> in a position to build it yourself and install it on your device. This is
>> no different than any other free software-- because you have a hackable
>> device like Ubuntu Touch and the source to this app, you can examine it and
>> build/fork it yourself. Or you can trust the developer.
>>
>>> I like the idea of a server building the
>>> source. But again, what do we need to
>>> do to trust that server system. Can we
>>> build up a system where it is hard to
>>> "steal" or manipulate source code, and if you can manage this,
>>> it is at least known who did it.
>>
>> The server is an interesting idea, and maybe it'll happen, but maybe not. If
>> it does, it doesn't actually solve the concern being expressed here because
>> non-opensource applications/binary blobs need to be supported by the
>> appstore otherwise certain types of non-free applications that many people
>> would find useful couldn't be added to the store. If there is a requirement
>> that all apps that come with source have to be built be a trusted server,
>> the bad guy will just ship a binary blob.
> 
> Yep, which is why I try to stay away from binary only phone apps as far as 
> possible. Especially free ones. Anyways, that's just me being part of the 
> paranoid group as well. I fully realize that most people want a malware store.
> 
>>
>> Apps run under application confinement[1] and application confinement has
>> been carefully designed to prevent stealing user data, running arbitrary
>> code, etc. An app can't steal another app's data (including system data).
>> An app can't see your facebook history or tweet as you. The trust model[2]
>> is such that click appstore apps are untrusted by the OS and that
>> permission to access sensitive data by AppStore apps is typically granted
>> or denied at the time of access[3]. When a user installs an app, the user
>> trusts the OS to make sure that the app is confined and can't access
>> anything outside of confinement, but the OS also provides context for
>> certain accesses. Eg, while some click game may have access to the internet
>> to post high scores, it is not allowed to steal your SSO credential, to
>> upload your music to a remote server or to sniff your keyboard. Application
>> confinement blocks *direct* access to things like that, but APIs exist for
>> access to some things so if an app wants to, for example, upload a picture,
>> it can do so-- but in using the API, the OS provides context for the access
>> so that the user discovers what the app is doing-- maybe via a confirmation
>> prompt, maybe via the gallery or a file picker (it all depends on the API
>> and what is appropriate in terms of usability, etc). So, if a game tries to
>> get a token to use twitter or obtain the pictures from your camera roll,
>> then the user sees a prompt and can act accordingly. The user can now
>> explicitly grant access to the sensitive data and therefore explicitly
>> trusts the application for this access. If it doesn't make sense for the
>> app to have access to twitter, then the user can deny the access and write
>> a user review (eg, "1 star-- this app wants to access twitter for seemingly
>> no good reason"). Of course a malicious application can throw up a phishing
>> page in a webview or upload the picture to instagram while also uploading
>> it to a remote server but that is possible in any app store and that is
>> where user reviews, terms of use (for the developers) and app removals come
>> into play. Policies are in place to handle reported malicious apps and
>> developers.
> 
> I do like the way our AppArmor confinement is coming along a lot. It really 
> seems to be here to protect the user instead of keeping the user from owning 
> the device like other major manufacturers tend to do.
> 
Thanks! Yes-- application confinement isn't about locking down the device; it is
about protecting the user and the system.

> One question on the roadmap: Right now it's either all or nothing. If an app 
> for example requests location, contacts, network and music (just making up 
> stuff here) and I install it, it means that I grant all of those permissions. 
> Is it planned to allow the user to still install this app, but not granting 
> any of the permissions? For example accessing the addressbook would return an 
> empty list, the location service would pretend to never get a GPS lock etc.
> 
So this gets into the area of what we call trusted helpers. Networking is all or
nothing currently. location and contacts are considered 'sensitive' therefore
direct access is blocked, but APIs are provided for apps to use to access them,
but when used will provide the prompting I mentioned before. Specifically, an
AppArmor policy group might allow access to the DBus API for the location or
address-book service. Then, if an app contacts this out of process service, this
service is what provides the prompt. If the user grants the access, the service
then allows it, if not, the service disallows it (ie the service is trusted to
enforce the user's decision). music depends-- apps aren't allowed to access the
music files directly-- but a future file picker content provider could provide
the access via content-hub, but there is also going to be a media service in the
future that should allow playback, import, etc to any app without the app having
direct access to the files.

To specifically answer your question-- it is up to the trusted helper on what to
return and that would depend on the helper. Maybe for location the answer is
"sorry, don't have a location device" and the QML/Qt api gracefully handles
that. Maybe for the addressbook, it is simply an empty list like you suggested.
I'm not sure what the first cuts will be, but the implementors of these APIs
should definitely return something that at least makes it possible for the app
to gracefully recover.

> If that will happen, this is going to be the best security model I could think 
> of (assuming the build server will happen at some point :D )
> 
We're certainly trying. :)

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature