ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-06-06 12:36 PM, Loïc Minier wrote:
> On Thu, Jun 06, 2013, Marc Deslauriers wrote:
>>>   This topic is mostly about guaranteeing authenticity of the package,
>>> to deliver it securely so that it can be trusted by the client.
>> There are actually two different things here:
>> - Guaranteeing that the app actually came from the developer
>> - Guaranteeing that the app actually came from the trusted app store
> 
> Thanks for being more rigorous than me in defining these; I tried to
> capture things we had discussed yesterday, but we need to agree on what
> we're trying to protect exactly.

Oh, sorry, I don't believe I was in that meeting.

> 
> Maybe we can even go one step further from the above two things and try
> to list stakeholders and use cases; we have 3 stakeholders (users,
> appstore owners and developers).
> 
> Users typically use devices with initially a single trusted appstore
> configured; they don't want to get any malware but:
>  * it might make sense to allow them to add trusted appstores; perhaps
>    this is blocked in the default config, but it might make sense in an
>    OEM scenario, or we could decide that we don't want to support this
>    at all

This sounds like a business decision, not a technical one. But yes, it's
relatively trivial to do once the logic for the first store is in place.

> 
>  * they might want to install apps manually instead of visiting an
>    appstore; for instance this could be the way developers test their
>    own apps before submitting them or when developing updates, this
>    could be a way to get some beta-testing from developers directly to
>    the users, or a way for users to install apps that have been removed
>    from the appstore
>    - depending on the implementation, we might be able to verify
>      signatures of manually installed packages or not
>    - we obviously must reject any unsigned or untrusted package by
>      default

If we allow a user to enter an "insecure" mode where they can install
arbitrary packages, what is the value in requiring them to be signed? A
user is definitely not in a position to verify signature fingerprints
and make security-conscious decisions based on the package signature.

For developers, they could either enter "insecure" mode, or perhaps they
could side load applications via the host's debugging tools.

> 
>>> There are generally two ways to approach this:
>>> 1. package is always transported securely: developer uploads package
>>>    to appstore over https, appstore serves it over some secure channel
>>>    (could be https too) to clients
>>>
>>> or
>>>
>>> 2. signature is embedded in the package at build time (developer
>>>    workstation) and verified on the client[1]
>>
>> I think you're missing the most important scenario:
>>
>> 3. signature is on a package list which contains a crypto hash of each
>> individual package.
> 
> I actually considered this approach part of 1., typically what we're
> doing today for .debs: signed Packages indices are a mean to deliver an
> unsigned .deb securely to end-users.  But fair enough, you could make
> this a separate category as "transported securely" is indeed confusing
> here as we use http for .debs today.  The main split I wanted to
> emphasise was on building the signature at build-time in the payload
> (2.) or on transporting the payload securely from one place to the next
> (1.).
> 
>> Mobile devices typically have the application author sign his package,
>> which is then hosted in the official app store using approach #3.
>>
>> On iOS, you can't load packages that don't come from the trusted store
>> (with a few exceptions, for example, if you obtain an enterprise cert
>> from apple for homemade apps)
> 
> You can also install them from iTunes; I think you can install old
> versions from their .ipa files in this way.

I believe the apps installed in this way need to have been available in
the app store for that to work. In the case of a developer, I believe
XCode adds the developer signature (signed by apple) to the device when
installing the app.

> 
> Similary on Android you can update an installed package with an .apk;
> I've noticed that it checks that the key used to sign the package is the
> same as the one that was used to sign the currently installed package,
> but I'm not sure what other checks are in place.

Hrm, not quite sure about that one. That would allow application
developers to bypass the app store restrictions, wouldn't it?

> 
>> On Android, you can't load packages that don't come from the trusted
>> store _unless_ you go into the settings and specifically check the box
>> to enable installing untrusted apps after clicking through a warning.
>> Many carriers disable this option.
> 
> I think we typcally want something similar, it's not clear to me whether
> we want to allow carriers to disable installation of untrusted apps
> entirely nor whether we want to allow them to add extra appstores, but I
> guess these are relatively trivial settings.  It's more of a product
> question, whether we allow the ecosystem to be bent in dangerous ways
> and then still calling this Ubuntu.

Again, I believe this is a business decision. As long as there is an
"unlocked" developer mode available for hobbyists, I have no issue with
it being restricted by default. :P

> 
>> This is only to ensure that the package comes from a particular
>> developer, not to indicate if a package is from a trusted app store.
> 
> This is a very good point that I think we've missed yesterday; I guess
> the approach I was indirectly describing as a possible implementation
> assumed that developers created keys, uploaded them to the appstore, and
> we distributed the trusted keys to the devices.  But that would allow
> developers to distribute apps we haven't reviewed through other
> channels, which I think is not ok.

Also, distributing a whole slew of arbitrary keys gets messy real quick.
You now need to revoke keys, etc.

> 
> So you have a point that we'd need some *appstore* trust path on top of
> the developer signature in the package, but this goes against one of the
> fundamental assumptions we were taking until now: that the package is
> untouched from the developer.

I don't think the appstore trust path should touch the package. When you
install an app from the appstore, the appstore gives you the package,
plus a hash of the package signed with the appstore key.

> 
> Still, we would at least want to allow developers to deploy apps to
> their own device for testing, preferably without disabling security
> entirely.
> 
> Would it work to combine signed indices with developer keys?  e.g.:
>  * by default, users can only install apps which are listed in the
>    official appstore (signed) index
>  * when they do, this gets the developer key from the appstore and
>    verifies the package against the index hash and the developer
>    signature

Why check the developer signature? As long as the app store signature
matches, and the hash matches, it's fine.

We _could_ have a fallback if we want where if the package doesn't have
a matching hash in the app store directory, we check the package
signature with a cert in a well-known system location that can be only
put there by the developer tools.


>  * users may install updates of installed packages /signed with the same
>    developer key/ by other means

This allows a malicious developer to publish an harmless fart app in the
store, which auto-updates itself with a malicious version.

This could also be used by developers to get around restrictions we may
have in our app store.

I don't think we should allow this. All packages that can be installed
on the device in "safe" mode should go through the store.

>  * developers might turn on developer mode and push their developer key
>    and apps signed with this key to local devices

Sure, that sounds reasonable.

> 
>  * don't think we want this: users may turn off any verification and
>    install untrusted packages

Although this sounds bad, I don't think there's a difference between
untrusted and package with arbitrary signature. I think once you enable
the "insecure" mode, you can do as you wish.

> 
>   * trusting extra appstores can only be done with custom builds of
>     Ubuntu Touch
> 
>> I hope we're talking about an android-type option targeted mainly at
>> developers. I definitely wouldn't want regular users to be able to
>> install untrusted packages from a web page by default. There is no way
>> for us to maintain a device with a level of security comparable to iOS
>> or default Android if we allow doing that.
> 
> (Yup)
> 
>> We shouldn't require devices to validate developer signatures. There's
>> no easy way of knowing which developer is trusted, and no easy way of
>> updating those keys. Devices should simply validate the signature on the
>> hash given by the official app store.
> 
> It's kind of weak to only check appstore hashes when you consider apps
> not distributed via the appstore.

Do we really want that? (except for developers, or "insecure" mode)?

> 
> Something related we had discussed yesterday is how do we namespace apps
> and prevent squatting names (e.g. how do you prevent someone to take
> "myapp" as appname, or if you are the one owning com.ubuntu.phone, how
> do you prevent someone from using the same app name or naming things
> under your realm).
>   I mention this because I think that even if we allow local
> installation of apps for e.g. developers, we would want to prevent
> replacing an official app with a locally built app with the same name.
> (We excluded GUIDs because these are ugly in the filesystem for the
> convergence case.)
> 

Oh? Why? Don't you want a developer to be able to test his new version?
Don't you want a hobbyist to be able to build a custom version of the
media player?


OK, so basically:

1- Default Secure Mode: By default, device only installs packages which
match hash provided by app store signature.

2- Developer Mode: Developer can add his key to device using tethered
developer tool. If package doesn't match app store hash, the signature
on the package itself is checked against local developer key. (Perhaps
the number of developer keys on device is limited to prevent this being
used by third-party app stores, etc.)

3- Untrusted Mode: as on Android. User/Developer checks a box which
disables any hash/signature verification.


Now, the question is if #2 is really worth doing, or if developers are
ok with #3.

Marc.