ubuntu-phone team mailing list archive

[Ondrej Kubik <ondrej.kubik@xxxxxxxxxxxxx>]

On Fri, Jun 13, 2014 at 6:29 PM, Martin Albisetti <argentina@xxxxxxxxx>
wrote:

> 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.
>
Yeah, but then this is not solving problem I have described in initial
 email here.
Idea is to protect from using side load to update existing application with
intruder's version to gain access to application private data or phone's
resources.
If developer mode is something easy to enable, which should be given the
spirit of Ubuntu, it'd easy way in.
We can elaborate on user data wipe as part of the side-loading enablement,
but that seems like harsh measure.
Also I believe even phone with enabled side loading should still be secure,
which won't be the case.

>
>
> >> > 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
>