ubuntu-appstore-developers team mailing list archive

[Martin Albisetti <martin.albisetti@xxxxxxxxxxxxx>]

On Wed, Jun 12, 2013 at 6:58 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
> On 06/12/2013 04:25 PM, Martin Albisetti wrote:
>> On Wed, Jun 12, 2013 at 4:57 PM, Marc Deslauriers
>> <marc.deslauriers@xxxxxxxxxxxxx> wrote:
>>>
>>> I'm pretty sure some carriers will force us to remove option #3, and
>>> some movie providers will force us to disable DRM when #3 is used.
>>
>> Why?
>> On Android that's only the case if you root the device, where apps can
>> go beyond their confinement. Installing unrestricted confined apps
>> shouldn't affect DRM, right?
>
> This is actually an interesting question. Consider that:
>
>  * click packages must have a manifest file to successfully
>    install
>  * the manifest file must define valid security accesses to
>    successfully install
>
> I think Martin's point (and one I've heard echoed elsewhere) is that if
> both of the above work correctly, the worst an unsigned app can do is be
> installed with the widest permission set that we allow. The argument
> goes that those permissions won't include access to ~/.gnupg or direct
> access to ~/Videos, so the app can't attack the whole system or upload
> one's movie collection.
>
> In a lot of ways, this is a valid argument because we will define our
> policy for the APIs we expose around SDK-apps such that the app review
> process can likely be highly-automated. This will work well enough in
> the short term since click packages will initially only use these APIs.
>
> The problem comes when we are trying to ship click packages for things
> not developed with the Ubuntu SDK. Eg, thinking about the converged
> device, if we ever try to ship LibreOffice as a click package, it is
> likely going to need different types of access than our pre-defined
> policy will provide. The security accesses in the manifest file may need
> to be extended in such a way as to provide wider access (eg, read/write
> access to large portions of $HOME). On upload to our appstore, we can
> flag packages with these extended access permissions for manual review
> before making them available in our trusted appstore just fine. The
> problem comes in that if the security manifest file allows for this
> flexibility and the user disables hash verification it necessarily means
> that when the user installs a click package from outside the trusted
> appstore, the security manifest could specify very lenient permissions
> such that the application effectually runs unconfined (ie, it is able to
> upload the user's entire movie collection to some server).

This makes a lot of sense.
Thanks for the explanation.

I worry that we'll be making it harder to sideload apps on the ubuntu
phone than on android, but, I guess, people will still be able to
install debs and provide the root password?


--
Martin