[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