[SailfishDevel] [Minutes] Sailfish OS Open Source Community Collaboration Meeting, 5th of September 2016

Andrew Penkrat penkrat8 at gmail.com
Wed Sep 7 12:56:15 UTC 2016


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