[SailfishDevel] [Minutes] Sailfish OS Open Source Community Collaboration Meeting, 5th of September 2016
Andrew Penkrat
penkrat8 at gmail.com
Wed Sep 7 13:12:16 UTC 2016
s/archives/achieves/g
On Wednesday, September 7, 2016 3:56:15 PM MSK, Andrew Penkrat
<penkrat8 at gmail.com> wrote:
> Hi Slava,
>
> On Wednesday, September 7, 2016 3:20:23 PM MSK, Slava Monich
> <slava.monich at jolla.com> wrote:
>> Hi,
>>
>> Access to contacts is actually quite a good example. It may or may not
>> require access to the network, depending on how it's implemented at Qt
>> plugin level. Should every app that needs contacts declare that it needs
>> network access even if the app itself doesn't use the network?
>>
>> Or it could require access to certain parts of the filesystem that by
>> default is disallowed. How is application supposed to figure that out in
>> order to request appropriate privileges?
>>
>> To make matters worse, the plugin requirements may change over time,
>> meaning that a system upgrade may break the app because the app didn't
>> request access to some features required by the updated plugins.
>
> Application shouldn't know/care about how does plugin work. Plugins are
> parts of the system and shouldn't be sandboxed.
>
> I don't know much about implementation, but Ubuntu Touch somehow archives
> this with AppArmor.
>
> Regards,
> Andrew
>
>>
>> The only sure way to protect the app against surprises like that is to
>> request access to pretty much everything. Which is the way it is now.
>> So way bother?
>>
>> Having full source code available (in merproject git repo) and making
>> sure that the app is built from those sources in Mer OBS and signed (by
>> Jolla?) would be a good start, in my opinion. Still it doesn't guarantee
>> that the app has no rogue functionality built in, but the community may
>> help to examine the source code. The more popular the platform is, the
>> more apps we have, the more security conscious people are willing to
>> check the sources - that sounds fairly scalable to me.
>>
>> Cheers,
>> -Slava
>>
>>
>>> Slava,
>>>
>>> Apps would have to declare what they need to function, and then the
>>> sandbox is in place to ensure that they can only use what they declare.
>>>
>>> This doesn't solve apps declaring they need full access to everything,
>>> but at least there are some assurances to the user that if they expect
>>> an app wont need access to the contacts list, that its not poking
>>> around in there. Expecting everyone to check the source code (if
>>> available) is not a very user friendly solution, and asking Jolla to
>>> hand verify all apps in the store isn't very scalable either.
>>>
>>> On Wed, Sep 7, 2016 at 11:23 AM, Slava Monich <slava.monich at jolla.com
>>> <mailto:slava.monich at jolla.com>> wrote:
>>>
>>> I feel a bit sceptical.
>>>
>>> If the system supports plugins, i.e. shared libraries discovered
>>> at runtime and getting loaded into the process context without
>>> executable knowing it in advance (like Qt does), then the
>>> application doesn't even know what kind of resources it actually
>>> needs at runtime to function properly.
>>>
>>> The next thing you do after you introduce sandboxing, you start
>>> adding ways to get around sandbox limitations, which in the end
>>> defies the whole purpose. Or you severely limit the usefulness of
>>> 3rd party apps. Sounds like a lose-lose situation.
>>>
>>> Any 3rd party app is a risk, especially the native ones,
>>> especially those that come unsigned and without the source code.
>>> If you don't want to take the risk, you don't install 3rd party
>>> apps. That works better than any kind of sandboxing.
>>>
>>> Cheers,
>>> -Slava
>>>
>>
>>
>
>
--
Sent using Dekko from my Ubuntu device
More information about the Devel
mailing list