ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 06/14/2013 01:02 PM, Martin Albisetti wrote:
> 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?
> 
Well, Marc's point isn't to make it difficult-- we should allow for it
and it should be easy for a developer to opt into; it's just that we we
can't control if OEMs disable it or if movie providers will require us
to disable DRM when in insecure mode.

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

Attachment: signature.asc
Description: OpenPGP digital signature