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

[Lewis Rockliffe]

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>
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
>
>
>
> Hello,
>>
>> During the discussion, we never hard-committed to SELinux. Instead, we
>> wanted to experiment a bit with it, and see if it suits our needs.
>>
>> SELinux was the first choice to consider because of Android using it.
>>
>> My goal is to just evaluate how it can be used in the context of SFOS, as
>> a sandboxing layer for applications, and to protect personnal user data. If
>> it is too hard to deploy, we will probably need to reconsider this choice.
>>
>> Thanks,
>> Lucien
>>
>> ----- Mail original -----
>>
>> De: "Tone Kastlunger" <users.giulietta at gmail.com>
>>> À: "Sailfish OS Developers" <devel at lists.sailfishos.org>
>>> Envoyé: Mercredi 7 Septembre 2016 09:21:06
>>> Objet: Re: [SailfishDevel] [Minutes] Sailfish OS Open Source
>>> Community Collaboration Meeting, 5th of September 2016
>>> Yeah, the main issue of SELinux for me is the necessity of compiliing
>>> the policy in the first place;
>>> in turn for doing that, you need to pull in all the SELinux toolkit
>>> (which is huuge).
>>> On Wed, Sep 7, 2016 at 9:50 AM, Michal Hrusecky < michal at hrusecky.net
>>>
>>>> wrote:
>>>> James Noori - 12:21 5.09.16 wrote:
>>>>
>>>>> Hi everyone!
>>>>> Thank you for attending today's meeting.
>>>>> Meeting minutes can be found here in variety of formats:
>>>>> Minutes:
>>>>> http://merproject.org/meetings/mer-meeting/2016/mer-meeting.
>>>>> 2016-09-05-09.00.html
>>>>> Minutes (text):
>>>>> http://merproject.org/meetings/mer-meeting/2016/mer-meeting.
>>>>> 2016-09-05-09.00.txt
>>>>> Log:
>>>>> http://merproject.org/meetings/mer-meeting/2016/mer-meeting.
>>>>> 2016-09-05-09.00.log.html
>>>>>
>>>> Hi, just read a minutes, SELinux was mention and that it would be
>>>> hard to get
>>>> profiles and support work correctly. What about using Apparmor
>>>> instead? Much
>>>> simpler and easier to create profiles for and can be probably
>>>> hacked
>>>> together
>>>> quite fast. And applications could probably come with profile
>>>> inside
>>>> rpm
>>>> specifying what do they need.
>>>> _______________________________________________
>>>> SailfishOS.org Devel mailing list
>>>> To unsubscribe, please send a mail to
>>>> devel-unsubscribe at lists.sailfishos.org
>>>>
>>> _______________________________________________
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to
>>> devel-unsubscribe at lists.sailfishos.org
>>>
>> _______________________________________________
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfi
>> shos.org
>>
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfi
> shos.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20160907/9a60eabf/attachment-0001.html>