ubuntu-phone team mailing list archive

[Martin Albisetti <argentina@xxxxxxxxx>]

On Fri, Jun 13, 2014 at 12:54 PM, Ondrej Kubik
<ondrej.kubik@xxxxxxxxxxxxx> wrote:
>>
>> All the client cares about is that our signature is valid. It doesn't
>> matter what the developer does. Devices will not check developer's
>> signatures. We can make sure our servers are aware of the transition
>> and handle it appropriately.
>
>
> I believe idea is to make signature check on device side before installing
> click, otherwise if we leave check only on server and device installs
> anything what comes form server we still have some problem, and it will not
> resolve side loading issue.
> So I think there is still problem. If we sign all the "unattended"
> applications with default key, and then developer decides to update such an
> application and sign it with own key, this should be refused by the device,
> otherwise there is hole in the security model. Or am I missing something?

Yes, it will check signatures before installing. What I think you're
not understanding is that it's the server signature, not the developer
signature.
There are 3 actors in this scenario, Developer, Store and Device.
1) The Developer creates a package, signs it and uploads it to the Store.
2) The Store validates that signature, and signs the signature (plus
other metadata).
3) The device gets the file, validates the server signature, ignores
the Developer signature.

The Device only trusts and validates the Store. The Store validates
the Developer. This model lets us change how we validate Developers
over time.
So in the current scenario -and this is speculation until we actually
start doing any of the work- we'd one day sign all current packages,
that we have no developer signature, grandfathering existing binaries
as validated.
At some point in time (which doesn't have to match up with this first
step) we start requiring developers to sign their packages. This will
increase the Store's confidence that the binary it has came from the
developer and was not tampered with in the middle. We currently fully
rely on SSL and OpenID authentication, which is ok but could be
better, which is why we'd add signing.

The developer can change their keys 3 times a day if they want,
devices don't care because they don't validate them. The server does.

For side loading, all bets are off. If you sideload, you need to know
exactly what you're doing. You either turn off validation all
together, or you add another key to validate and are responsible for
the whole chain not being tampered with.


>> > Are we planning to have policy in places allowing apps to share package
>> > only
>> > if they have same signature?
>> >
>> > If two different apps are coming from same developer and share same
>> > package
>> > name ( and same signature) will they share same sandbox or will they be
>> > able
>> > to peak into each other's sandbox, at least data wise?
>>
>> We don't have anything in mind yet, and I don't think we'd do it based
>> on signatures, but I'll defer that to the security team when the time
>> comes.
>> Developers get a namespace when they sign up, I'd expect that
>> namespace to determine this relationship, rather than signatures.
>
> Sorry for term confusion.
> Multiple application with same namespace on one device could come only
> signed with one same signature.
> Yes sandbox boundaries should be determined by namespace. Ideally two apps
> in same namespace should be able to share private data.

Well, no. As explained above, multiple applications under the same
namespace can have different Developer signatures.
For clarity, a namespace is "ar.com.beuno", I own that, nobody can
publish under that except me (enforced by the Store). I can have 2
apps, "ar.com.beuno.app1" and "ar.com.beuno.app2", which have their
own unique identifier within the same namespace.
As Rodney points out, our current security model would stop any
sharing of data, we can revise this in the future but nothing
currently indicates that we should (and instead have everything go
through "trusted helpers").

Hope this makes more sense!


-- 
Martin