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

[Tone Kastlunger]

s/project/process heh

On Thu, Sep 8, 2016 at 9:23 AM, Tone Kastlunger 
wrote:

> QML plugins in a separate project - something is amiss here; but anyways.
> It is fairly easy to evaluate a technology for a certain use in my
> opinion; especially if that technology is not new and has been used
> (SELinux has),
> and ESPECIALLY if it has been used in the same context already (i.e.
> Android).
> Slava, you mention about ABI compatibility; how does Android solve this?
> Is this a problem for Android as well?
> Applications on android request access on install already; i.e. they
> provide a manifest to do so, not during runtime.
> It is a plus for SELinux, that having it would remove some entries from
> the porting from android task list (potentially).
>
> Think about this from different angles;
>
> what do developers want?
> what do developers *need*?
> what consequences will the choice that is made have? how will they
> influence development?
> how will this tech be used? By whom?
>
>
>
>
>
>
> On Wed, Sep 7, 2016 at 4:47 PM, Andrew Penkrat  wrote:
>
>> On Wednesday, September 7, 2016 4:20:04 PM MSK, Slava Monich <
>> slava.mon...@jolla.com> wrote:
>>
>>> Hi Andrew,
>>>
>>> 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.

>>>
>>>
>>> How to you sandbox a native app without affecting plugins? They all live
>>> within the same process, the same virtual address space. I don't think it's
>>> possible to reliably track a system call back to the executable/shared
>>> library it originated from, even with DEP (data execution prevention)
>>> enabled. Without DEP it's plain impossible.
>>>
>>> With the interpreted code like Java it's certainly doable. With the
>>> native code, I very much doubt it.
>>>
>>> Cheers,
>>> Slava
>>>
>>>
>>>
>> That's why I wrote this:
>>
>>>
 I don't know much about implementation, but Ubuntu Touch somehow
 achieves this with AppArmor.


>> AFAIK, at least for QML plugins it runs them in separate processes and
>> application communicates with them via DBus. All seamlessly for developer.
>>
>> Regards,
>> Andrew
>>
>>
>>
>> --
>> Sent using Dekko from my Ubuntu device
>> ___
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
>> shos.org
>>
>
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Tone Kastlunger]

QML plugins in a separate project - something is amiss here; but anyways.
It is fairly easy to evaluate a technology for a certain use in my opinion;
especially if that technology is not new and has been used (SELinux has),
and ESPECIALLY if it has been used in the same context already (i.e.
Android).
Slava, you mention about ABI compatibility; how does Android solve this? Is
this a problem for Android as well?
Applications on android request access on install already; i.e. they
provide a manifest to do so, not during runtime.
It is a plus for SELinux, that having it would remove some entries from the
porting from android task list (potentially).

Think about this from different angles;

what do developers want?
what do developers *need*?
what consequences will the choice that is made have? how will they
influence development?
how will this tech be used? By whom?






On Wed, Sep 7, 2016 at 4:47 PM, Andrew Penkrat  wrote:

> On Wednesday, September 7, 2016 4:20:04 PM MSK, Slava Monich <
> slava.mon...@jolla.com> wrote:
>
>> Hi Andrew,
>>
>> 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.
>>>
>>
>>
>> How to you sandbox a native app without affecting plugins? They all live
>> within the same process, the same virtual address space. I don't think it's
>> possible to reliably track a system call back to the executable/shared
>> library it originated from, even with DEP (data execution prevention)
>> enabled. Without DEP it's plain impossible.
>>
>> With the interpreted code like Java it's certainly doable. With the
>> native code, I very much doubt it.
>>
>> Cheers,
>> Slava
>>
>>
>>
> That's why I wrote this:
>
>>
>>> I don't know much about implementation, but Ubuntu Touch somehow
>>> achieves this with AppArmor.
>>>
>>>
> AFAIK, at least for QML plugins it runs them in separate processes and
> application communicates with them via DBus. All seamlessly for developer.
>
> Regards,
> Andrew
>
>
>
> --
> Sent using Dekko from my Ubuntu device
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
> shos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Andrew Penkrat]

On Wednesday, September 7, 2016 4:20:04 PM MSK, Slava Monich 
 wrote:

Hi Andrew,

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.



How to you sandbox a native app without affecting plugins? They all live 
within the same process, the same virtual address space. I don't think 
it's possible to reliably track a system call back to the 
executable/shared library it originated from, even with DEP (data 
execution prevention) enabled. Without DEP it's plain impossible.


With the interpreted code like Java it's certainly doable. With the 
native code, I very much doubt it.


Cheers,
Slava




That's why I wrote this:


I don't know much about implementation, but Ubuntu Touch somehow 
achieves this with AppArmor.




AFAIK, at least for QML plugins it runs them in separate processes and 
application communicates with them via DBus. All seamlessly for developer.


Regards,
Andrew



--
Sent using Dekko from my Ubuntu device
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Slava Monich]

Hi Andrew,

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.



How to you sandbox a native app without affecting plugins? They all live 
within the same process, the same virtual address space. I don't think 
it's possible to reliably track a system call back to the 
executable/shared library it originated from, even with DEP (data 
execution prevention) enabled. Without DEP it's plain impossible.


With the interpreted code like Java it's certainly doable. With the 
native code, I very much doubt it.


Cheers,
Slava




I don't know much about implementation, but Ubuntu Touch somehow 
archives this with AppArmor.


Regards,
Andrew


___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Andrew Penkrat]

s/archives/achieves/g

On Wednesday, September 7, 2016 3:56:15 PM MSK, Andrew Penkrat 
 wrote:

Hi Slava,

On Wednesday, September 7, 2016 3:20:23 PM MSK, Slava Monich 
 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 > 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
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Andrew Penkrat]

Hi Slava,

On Wednesday, September 7, 2016 3:20:23 PM MSK, Slava Monich 
 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 > 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
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Slava Monich]

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.


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 > 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



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [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 
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" 
>>> À: "Sailfish OS Developers" 
>>> 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 < mic...@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-unsubscr...@lists.sailfishos.org
>>>>
>>> ___
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to
>>> devel-unsubscr...@lists.sailfishos.org
>>>
>> ___
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
>> shos.org
>>
>
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfi
> shos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Slava Monich]

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" 
À: "Sailfish OS Developers" 
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 < mic...@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-unsubscr...@lists.sailfishos.org

___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org

___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org


___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Lucien Xu]

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" 
> À: "Sailfish OS Developers" 
> 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 < mic...@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-unsubscr...@lists.sailfishos.org
> 

> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Tone Kastlunger]

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  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@lists.
> sailfishos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

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

[Michal Hrusecky]

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-unsubscr...@lists.sailfishos.org

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

[James Noori]

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


If you wish to propose a new topic for the next meeting, please do so here:
https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/


Next meeting is going to be held on Monday, 3rd of October 2016 at 09:00UTC
Check your local time here: http://bit.ly/2bQy022


Thanks and best regards,
James Noori (Jaymzz)
Community Manager
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org