This patchset aims to ensure user data confidentiality by curbing on
userdomain file read and/or write permissions for all applications and
daemons that potentially deal with such files and directories.
Several modules would greatly benefit from further testing.
Where possible a boolean has been introduced to revert the less
restrictive and more risky behavior (by setting it to "true").
Regards,
Guido
I forgot to add: the Download directory is always writable and can be used as a shared "parking" area for all sort of files (not necessarily only those that are downloaded from the network).
Files that are considered "safe" after inspection can be picked from the shared parking area and moved elsewhere within the home directory (or outside of it).
Applications that do not have a corresponding policy module run as "user_u" and therefore always have full read/write access to the whole home directory, that's why it is important to confine as much applications as possible.
A couple of patches in this set (the 22nd and the 25th) wrongly bring "/34" in the email subject: this is a mistake, please read "/33".
I hope you find the patchset an useful step towards assuring user data confidentiality.
Regards,
Guido
> On the 20th of April 2017 at 2.59 Guido Trentalancia via refpolicy <[email protected]> wrote:
>
>
> This patchset aims to ensure user data confidentiality by curbing on
> userdomain file read and/or write permissions for all applications and
> daemons that potentially deal with such files and directories.
>
> Several modules would greatly benefit from further testing.
>
> Where possible a boolean has been introduced to revert the less
> restrictive and more risky behavior (by setting it to "true").
>
> Regards,
>
> Guido
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
Whoa whoa. this is a huuuuge patchset. If we're gonna take something
like this upstream can we instead take the gentoo stuff? we've had a
cleaner version of this for ages and its well tested so i'd rather
upstream that instead first then apply any remaining things on top of
it?
-- Jason
On Thu, Apr 20, 2017 at 02:13:43PM +0200, Guido Trentalancia via refpolicy wrote:
> I forgot to add: the Download directory is always writable and can be used as a shared "parking" area for all sort of files (not necessarily only those that are downloaded from the network).
>
> Files that are considered "safe" after inspection can be picked from the shared parking area and moved elsewhere within the home directory (or outside of it).
>
> Applications that do not have a corresponding policy module run as "user_u" and therefore always have full read/write access to the whole home directory, that's why it is important to confine as much applications as possible.
>
> A couple of patches in this set (the 22nd and the 25th) wrongly bring "/34" in the email subject: this is a mistake, please read "/33".
>
> I hope you find the patchset an useful step towards assuring user data confidentiality.
>
> Regards,
>
> Guido
>
> > On the 20th of April 2017 at 2.59 Guido Trentalancia via refpolicy <[email protected]> wrote:
> >
> >
> > This patchset aims to ensure user data confidentiality by curbing on
> > userdomain file read and/or write permissions for all applications and
> > daemons that potentially deal with such files and directories.
> >
> > Several modules would greatly benefit from further testing.
> >
> > Where possible a boolean has been introduced to revert the less
> > restrictive and more risky behavior (by setting it to "true").
> >
> > Regards,
> >
> > Guido
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
At the very least, what you suggest doesn't seem correct !
> On the 20th of April 2017 at 16.10 Jason Zaman <[email protected]> wrote:
>
>
> Whoa whoa. this is a huuuuge patchset. If we're gonna take something
> like this upstream can we instead take the gentoo stuff? we've had a
> cleaner version of this for ages and its well tested so i'd rather
> upstream that instead first then apply any remaining things on top of
> it?
>
> -- Jason
>
> On Thu, Apr 20, 2017 at 02:13:43PM +0200, Guido Trentalancia via refpolicy wrote:
> > I forgot to add: the Download directory is always writable and can be used as a shared "parking" area for all sort of files (not necessarily only those that are downloaded from the network).
> >
> > Files that are considered "safe" after inspection can be picked from the shared parking area and moved elsewhere within the home directory (or outside of it).
> >
> > Applications that do not have a corresponding policy module run as "user_u" and therefore always have full read/write access to the whole home directory, that's why it is important to confine as much applications as possible.
> >
> > A couple of patches in this set (the 22nd and the 25th) wrongly bring "/34" in the email subject: this is a mistake, please read "/33".
> >
> > I hope you find the patchset an useful step towards assuring user data confidentiality.
> >
> > Regards,
> >
> > Guido
> >
> > > On the 20th of April 2017 at 2.59 Guido Trentalancia via refpolicy <[email protected]> wrote:
> > >
> > >
> > > This patchset aims to ensure user data confidentiality by curbing on
> > > userdomain file read and/or write permissions for all applications and
> > > daemons that potentially deal with such files and directories.
> > >
> > > Several modules would greatly benefit from further testing.
> > >
> > > Where possible a boolean has been introduced to revert the less
> > > restrictive and more risky behavior (by setting it to "true").
> > >
> > > Regards,
> > >
> > > Guido
> > > _______________________________________________
> > > refpolicy mailing list
> > > refpolicy at oss.tresys.com
> > > http://oss.tresys.com/mailman/listinfo/refpolicy
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
On 04/20/2017 10:17 AM, Guido Trentalancia via refpolicy wrote:
> At the very least, what you suggest doesn't seem correct !
>
>> On the 20th of April 2017 at 16.10 Jason Zaman <[email protected]> wrote:
>>
>>
>> Whoa whoa. this is a huuuuge patchset. If we're gonna take something
>> like this upstream can we instead take the gentoo stuff? we've had a
>> cleaner version of this for ages and its well tested so i'd rather
>> upstream that instead first then apply any remaining things on top of
>> it?
>>
>> -- Jason
I'm afraid I have to agree with Jason on this. The Gentoo guys have
been working this for quite some time.
>> On Thu, Apr 20, 2017 at 02:13:43PM +0200, Guido Trentalancia via refpolicy wrote:
>>> I forgot to add: the Download directory is always writable and can be used as a shared "parking" area for all sort of files (not necessarily only those that are downloaded from the network).
>>>
>>> Files that are considered "safe" after inspection can be picked from the shared parking area and moved elsewhere within the home directory (or outside of it).
>>>
>>> Applications that do not have a corresponding policy module run as "user_u" and therefore always have full read/write access to the whole home directory, that's why it is important to confine as much applications as possible.
>>>
>>> A couple of patches in this set (the 22nd and the 25th) wrongly bring "/34" in the email subject: this is a mistake, please read "/33".
>>>
>>> I hope you find the patchset an useful step towards assuring user data confidentiality.
>>>
>>> Regards,
>>>
>>> Guido
>>>
>>>> On the 20th of April 2017 at 2.59 Guido Trentalancia via refpolicy <[email protected]> wrote:
>>>>
>>>>
>>>> This patchset aims to ensure user data confidentiality by curbing on
>>>> userdomain file read and/or write permissions for all applications and
>>>> daemons that potentially deal with such files and directories.
>>>>
>>>> Several modules would greatly benefit from further testing.
>>>>
>>>> Where possible a boolean has been introduced to revert the less
>>>> restrictive and more risky behavior (by setting it to "true").
--
Chris PeBenito
Hello.
I have just browsed the following website:
https://gitweb.gentoo.org/proj/hardened-refpolicy.git/log/
which should belong to the Gentoo distribution, but I couldn't find any reference to a similar patch...
I am not sure we are talking about the same kind of patch !
Guido
> On the 21st of April 2017 at 0.20 Chris PeBenito <[email protected]> wrote:
>
>
> On 04/20/2017 10:17 AM, Guido Trentalancia via refpolicy wrote:
> > At the very least, what you suggest doesn't seem correct !
> >
> >> On the 20th of April 2017 at 16.10 Jason Zaman <[email protected]> wrote:
> >>
> >>
> >> Whoa whoa. this is a huuuuge patchset. If we're gonna take something
> >> like this upstream can we instead take the gentoo stuff? we've had a
> >> cleaner version of this for ages and its well tested so i'd rather
> >> upstream that instead first then apply any remaining things on top of
> >> it?
> >>
> >> -- Jason
>
> I'm afraid I have to agree with Jason on this. The Gentoo guys have
> been working this for quite some time.
>
>
> >> On Thu, Apr 20, 2017 at 02:13:43PM +0200, Guido Trentalancia via refpolicy wrote:
> >>> I forgot to add: the Download directory is always writable and can be used as a shared "parking" area for all sort of files (not necessarily only those that are downloaded from the network).
> >>>
> >>> Files that are considered "safe" after inspection can be picked from the shared parking area and moved elsewhere within the home directory (or outside of it).
> >>>
> >>> Applications that do not have a corresponding policy module run as "user_u" and therefore always have full read/write access to the whole home directory, that's why it is important to confine as much applications as possible.
> >>>
> >>> A couple of patches in this set (the 22nd and the 25th) wrongly bring "/34" in the email subject: this is a mistake, please read "/33".
> >>>
> >>> I hope you find the patchset an useful step towards assuring user data confidentiality.
> >>>
> >>> Regards,
> >>>
> >>> Guido
> >>>
> >>>> On the 20th of April 2017 at 2.59 Guido Trentalancia via refpolicy <[email protected]> wrote:
> >>>>
> >>>>
> >>>> This patchset aims to ensure user data confidentiality by curbing on
> >>>> userdomain file read and/or write permissions for all applications and
> >>>> daemons that potentially deal with such files and directories.
> >>>>
> >>>> Several modules would greatly benefit from further testing.
> >>>>
> >>>> Where possible a boolean has been introduced to revert the less
> >>>> restrictive and more risky behavior (by setting it to "true").
>
>
> --
> Chris PeBenito
We've bundled those in the xdg policy module, as a reference to the
XDG Base Directory Specification which is somewhat a descriptive
document on the various locations included in the patch.
https://gitweb.gentoo.org/proj/hardened-refpolicy.git/tree/policy/modules/contrib/xdg.if
We make a distinction between the "generic" directories (like
~/.local/share = xdg_data_home_t) versus application-specific ones
(like ~/.local/share/xorg = xserver_xdg_data_home_t). In the
interfaces (as mentioned above) applications can then get either
rights on the generic ones, or all (xdg_read_data_home_files() vs
xdg_read_all_data_home_files() as examples).
The idea is the same as you had - not all applications need access to
generic user content. Especially the browsers, as those are a main
attack vector nowadays, but it of course extends to others as well.
As each user has a different approach or use case, we then make it
often optional (through booleans) if an application domain can or
can't access user home directories. This is handled through the
userdom_user_content_access_template() which generates, for
application domains, the *_read_generic_user_content,
*_read_all_user_content, *_manage_generic_user_content and
*_manage_all_user_content booleans.
To accomplish that, we introduced attributes that are assigned to user
content (user_home_content_type) to toggle access to either the
user_home_t type or the wider set.
Hope that helps a bit.
Wkr,
Sven Vermeulen
On Fri, Apr 21, 2017 at 12:50 AM, Guido Trentalancia via refpolicy
<[email protected]> wrote:
> Hello.
>
> I have just browsed the following website:
>
> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/log/
>
> which should belong to the Gentoo distribution, but I couldn't find any reference to a similar patch...
>
> I am not sure we are talking about the same kind of patch !
>
> Guido
>
>> On the 21st of April 2017 at 0.20 Chris PeBenito <[email protected]> wrote:
>>
>>
>> On 04/20/2017 10:17 AM, Guido Trentalancia via refpolicy wrote:
>> > At the very least, what you suggest doesn't seem correct !
>> >
>> >> On the 20th of April 2017 at 16.10 Jason Zaman <[email protected]> wrote:
>> >>
>> >>
>> >> Whoa whoa. this is a huuuuge patchset. If we're gonna take something
>> >> like this upstream can we instead take the gentoo stuff? we've had a
>> >> cleaner version of this for ages and its well tested so i'd rather
>> >> upstream that instead first then apply any remaining things on top of
>> >> it?
>> >>
>> >> -- Jason
>>
>> I'm afraid I have to agree with Jason on this. The Gentoo guys have
>> been working this for quite some time.
>>
>>
>> >> On Thu, Apr 20, 2017 at 02:13:43PM +0200, Guido Trentalancia via refpolicy wrote:
>> >>> I forgot to add: the Download directory is always writable and can be used as a shared "parking" area for all sort of files (not necessarily only those that are downloaded from the network).
>> >>>
>> >>> Files that are considered "safe" after inspection can be picked from the shared parking area and moved elsewhere within the home directory (or outside of it).
>> >>>
>> >>> Applications that do not have a corresponding policy module run as "user_u" and therefore always have full read/write access to the whole home directory, that's why it is important to confine as much applications as possible.
>> >>>
>> >>> A couple of patches in this set (the 22nd and the 25th) wrongly bring "/34" in the email subject: this is a mistake, please read "/33".
>> >>>
>> >>> I hope you find the patchset an useful step towards assuring user data confidentiality.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Guido
>> >>>
>> >>>> On the 20th of April 2017 at 2.59 Guido Trentalancia via refpolicy <[email protected]> wrote:
>> >>>>
>> >>>>
>> >>>> This patchset aims to ensure user data confidentiality by curbing on
>> >>>> userdomain file read and/or write permissions for all applications and
>> >>>> daemons that potentially deal with such files and directories.
>> >>>>
>> >>>> Several modules would greatly benefit from further testing.
>> >>>>
>> >>>> Where possible a boolean has been introduced to revert the less
>> >>>> restrictive and more risky behavior (by setting it to "true").
>>
>>
>> --
>> Chris PeBenito
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
Hello.
The patchset that I have posted the other day is ready to use, now.
How comes these other changes, that you say are equivalent, have not been merged yet?
Christopher has already decided to apply the patch that you mentioned, I hope there will be the same functionality implemented at least before next release...
Regards,
Guido
On the 22nd April 2017 11:13:53 CEST, Sven Vermeulen via refpolicy <[email protected]> wrote:
>We've bundled those in the xdg policy module, as a reference to the
>XDG Base Directory Specification which is somewhat a descriptive
>document on the various locations included in the patch.
>
>https://gitweb.gentoo.org/proj/hardened-refpolicy.git/tree/policy/modules/contrib/xdg.if
>
>We make a distinction between the "generic" directories (like
>~/.local/share = xdg_data_home_t) versus application-specific ones
>(like ~/.local/share/xorg = xserver_xdg_data_home_t). In the
>interfaces (as mentioned above) applications can then get either
>rights on the generic ones, or all (xdg_read_data_home_files() vs
>xdg_read_all_data_home_files() as examples).
>
>The idea is the same as you had - not all applications need access to
>generic user content. Especially the browsers, as those are a main
>attack vector nowadays, but it of course extends to others as well.
>
>As each user has a different approach or use case, we then make it
>often optional (through booleans) if an application domain can or
>can't access user home directories. This is handled through the
>userdom_user_content_access_template() which generates, for
>application domains, the *_read_generic_user_content,
>*_read_all_user_content, *_manage_generic_user_content and
>*_manage_all_user_content booleans.
>
>To accomplish that, we introduced attributes that are assigned to user
>content (user_home_content_type) to toggle access to either the
>user_home_t type or the wider set.
>
>Hope that helps a bit.
>
>Wkr,
> Sven Vermeulen
>
>On Fri, Apr 21, 2017 at 12:50 AM, Guido Trentalancia via refpolicy
><[email protected]> wrote:
>> Hello.
>>
>> I have just browsed the following website:
>>
>> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/log/
>>
>> which should belong to the Gentoo distribution, but I couldn't find
>any reference to a similar patch...
>>
>> I am not sure we are talking about the same kind of patch !
>>
>> Guido
>>
>>> On the 21st of April 2017 at 0.20 Chris PeBenito <[email protected]>
>wrote:
>>>
>>>
>>> On 04/20/2017 10:17 AM, Guido Trentalancia via refpolicy wrote:
>>> > At the very least, what you suggest doesn't seem correct !
>>> >
>>> >> On the 20th of April 2017 at 16.10 Jason Zaman
><[email protected]> wrote:
>>> >>
>>> >>
>>> >> Whoa whoa. this is a huuuuge patchset. If we're gonna take
>something
>>> >> like this upstream can we instead take the gentoo stuff? we've
>had a
>>> >> cleaner version of this for ages and its well tested so i'd
>rather
>>> >> upstream that instead first then apply any remaining things on
>top of
>>> >> it?
>>> >>
>>> >> -- Jason
>>>
>>> I'm afraid I have to agree with Jason on this. The Gentoo guys have
>>> been working this for quite some time.
>>>
>>>
>>> >> On Thu, Apr 20, 2017 at 02:13:43PM +0200, Guido Trentalancia via
>refpolicy wrote:
>>> >>> I forgot to add: the Download directory is always writable and
>can be used as a shared "parking" area for all sort of files (not
>necessarily only those that are downloaded from the network).
>>> >>>
>>> >>> Files that are considered "safe" after inspection can be picked
>from the shared parking area and moved elsewhere within the home
>directory (or outside of it).
>>> >>>
>>> >>> Applications that do not have a corresponding policy module run
>as "user_u" and therefore always have full read/write access to the
>whole home directory, that's why it is important to confine as much
>applications as possible.
>>> >>>
>>> >>> A couple of patches in this set (the 22nd and the 25th) wrongly
>bring "/34" in the email subject: this is a mistake, please read "/33".
>>> >>>
>>> >>> I hope you find the patchset an useful step towards assuring
>user data confidentiality.
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> Guido
>>> >>>
>>> >>>> On the 20th of April 2017 at 2.59 Guido Trentalancia via
>refpolicy <[email protected]> wrote:
>>> >>>>
>>> >>>>
>>> >>>> This patchset aims to ensure user data confidentiality by
>curbing on
>>> >>>> userdomain file read and/or write permissions for all
>applications and
>>> >>>> daemons that potentially deal with such files and directories.
>>> >>>>
>>> >>>> Several modules would greatly benefit from further testing.
>>> >>>>
>>> >>>> Where possible a boolean has been introduced to revert the less
>>> >>>> restrictive and more risky behavior (by setting it to "true").
>>>
>>>
>>> --
>>> Chris PeBenito
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>_______________________________________________
>refpolicy mailing list
>refpolicy at oss.tresys.com
>http://oss.tresys.com/mailman/listinfo/refpolicy
On 04/22/2017 07:50 AM, Guido Trentalancia via refpolicy wrote:
> Hello.
>
> The patchset that I have posted the other day is ready to use, now.
>
> How comes these other changes, that you say are equivalent, have not been merged yet?
>
> Christopher has already decided to apply the patch that you mentioned, I hope there will be the same functionality implemented at least before next release...
I've given feedback several times. I'm not sure what happened, and I
can't remember if we couldn't come to a conclusion or if it simply fell
off my plate.
> On the 22nd April 2017 11:13:53 CEST, Sven Vermeulen via refpolicy <[email protected]> wrote:
>> We've bundled those in the xdg policy module, as a reference to the
>> XDG Base Directory Specification which is somewhat a descriptive
>> document on the various locations included in the patch.
>>
>> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/tree/policy/modules/contrib/xdg.if
>>
>> We make a distinction between the "generic" directories (like
>> ~/.local/share = xdg_data_home_t) versus application-specific ones
>> (like ~/.local/share/xorg = xserver_xdg_data_home_t). In the
>> interfaces (as mentioned above) applications can then get either
>> rights on the generic ones, or all (xdg_read_data_home_files() vs
>> xdg_read_all_data_home_files() as examples).
>>
>> The idea is the same as you had - not all applications need access to
>> generic user content. Especially the browsers, as those are a main
>> attack vector nowadays, but it of course extends to others as well.
>>
>> As each user has a different approach or use case, we then make it
>> often optional (through booleans) if an application domain can or
>> can't access user home directories. This is handled through the
>> userdom_user_content_access_template() which generates, for
>> application domains, the *_read_generic_user_content,
>> *_read_all_user_content, *_manage_generic_user_content and
>> *_manage_all_user_content booleans.
>>
>> To accomplish that, we introduced attributes that are assigned to user
>> content (user_home_content_type) to toggle access to either the
>> user_home_t type or the wider set.
>>
>> Hope that helps a bit.
>>
>> Wkr,
>> Sven Vermeulen
>>
>> On Fri, Apr 21, 2017 at 12:50 AM, Guido Trentalancia via refpolicy
>> <[email protected]> wrote:
>>> Hello.
>>>
>>> I have just browsed the following website:
>>>
>>> https://gitweb.gentoo.org/proj/hardened-refpolicy.git/log/
>>>
>>> which should belong to the Gentoo distribution, but I couldn't find
>> any reference to a similar patch...
>>>
>>> I am not sure we are talking about the same kind of patch !
>>>
>>> Guido
>>>
>>>> On the 21st of April 2017 at 0.20 Chris PeBenito <[email protected]>
>> wrote:
>>>>
>>>>
>>>> On 04/20/2017 10:17 AM, Guido Trentalancia via refpolicy wrote:
>>>>> At the very least, what you suggest doesn't seem correct !
>>>>>
>>>>>> On the 20th of April 2017 at 16.10 Jason Zaman
>> <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>> Whoa whoa. this is a huuuuge patchset. If we're gonna take
>> something
>>>>>> like this upstream can we instead take the gentoo stuff? we've
>> had a
>>>>>> cleaner version of this for ages and its well tested so i'd
>> rather
>>>>>> upstream that instead first then apply any remaining things on
>> top of
>>>>>> it?
>>>>>>
>>>>>> -- Jason
>>>>
>>>> I'm afraid I have to agree with Jason on this. The Gentoo guys have
>>>> been working this for quite some time.
>>>>
>>>>
>>>>>> On Thu, Apr 20, 2017 at 02:13:43PM +0200, Guido Trentalancia via
>> refpolicy wrote:
>>>>>>> I forgot to add: the Download directory is always writable and
>> can be used as a shared "parking" area for all sort of files (not
>> necessarily only those that are downloaded from the network).
>>>>>>>
>>>>>>> Files that are considered "safe" after inspection can be picked
>>from the shared parking area and moved elsewhere within the home
>> directory (or outside of it).
>>>>>>>
>>>>>>> Applications that do not have a corresponding policy module run
>> as "user_u" and therefore always have full read/write access to the
>> whole home directory, that's why it is important to confine as much
>> applications as possible.
>>>>>>>
>>>>>>> A couple of patches in this set (the 22nd and the 25th) wrongly
>> bring "/34" in the email subject: this is a mistake, please read "/33".
>>>>>>>
>>>>>>> I hope you find the patchset an useful step towards assuring
>> user data confidentiality.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Guido
>>>>>>>
>>>>>>>> On the 20th of April 2017 at 2.59 Guido Trentalancia via
>> refpolicy <[email protected]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> This patchset aims to ensure user data confidentiality by
>> curbing on
>>>>>>>> userdomain file read and/or write permissions for all
>> applications and
>>>>>>>> daemons that potentially deal with such files and directories.
>>>>>>>>
>>>>>>>> Several modules would greatly benefit from further testing.
>>>>>>>>
>>>>>>>> Where possible a boolean has been introduced to revert the less
>>>>>>>> restrictive and more risky behavior (by setting it to "true").
--
Chris PeBenito
On Sun, Apr 23, 2017 at 3:14 PM, Chris PeBenito via refpolicy
<[email protected]> wrote:
> On 04/22/2017 07:50 AM, Guido Trentalancia via refpolicy wrote:
>> The patchset that I have posted the other day is ready to use, now.
>>
>> How comes these other changes, that you say are equivalent, have not been merged yet?
>>
>> Christopher has already decided to apply the patch that you mentioned, I hope there will be the same functionality implemented at least before next release...
>
> I've given feedback several times. I'm not sure what happened, and I
> can't remember if we couldn't come to a conclusion or if it simply fell
> off my plate.
I think that's my fault. The last feedback was that you weren't sure
that the approach needs its own module or not. Remember, Gentoo has
moved those definitions inside its own module (xdg.*) to refer to the
base specification where those locations have been defined. This is
for a couple of reasons: to not make userdomain larger than it is
already, to make use of the modularity that refpolicy provides, and to
facilitate some compatibility (no xdg module, then the locations
remain user_home_t for instance).
A year or two later, a separate xdg module was suggested by Dominick
as well (with similar concept as Gentoo has), but it fell through the
cracks too (no discussion on it [1]).
[1] http://oss.tresys.com/pipermail/refpolicy/2013-November/006621.html
So one of the decisions we need to take is if a separate module is
warranted or not. This can go either way, and if you or the community
at large prefers to put it in the userdomain, then I can agree to
follow it - I might not fully stand behind it, but this is a community
effort after all, and I too prefer to get things forward (so,
apologies that I didn't follow up then).
My suggestion would be as follows:
I'll go through Guido's patch and see if there are any *conceptual*
differences between his patch and Gentoo's approach. If there are,
we'll discuss them here to see what is the best way forward. If
Gentoo's conceptual design is more preferred then we'll probably base
it on Gentoo's current policy code base. If Guido's is preferential
then we start off with Guido's.
Once the conceptual differences have been resolved (or there weren't
to begin with), then the next step would be to publish the patch round
again (whatever based upon) with the merged changes from both sets (be
it Gentoo's or Guido's). As Jason already mentioned - yes, this is a
big patch, so it also makes sense to do this in a step-wise approach
rather than one big patch set.
Is that feasible for you guys? I know I haven't been around/active for
a long time but that's about to change ;-)
Wkr,
Sven Vermeulen
On 05/06/2017 07:59 AM, Sven Vermeulen via refpolicy wrote:
> On Sun, Apr 23, 2017 at 3:14 PM, Chris PeBenito via refpolicy
> <[email protected]> wrote:
>> On 04/22/2017 07:50 AM, Guido Trentalancia via refpolicy wrote:
>>> The patchset that I have posted the other day is ready to use, now.
>>>
>>> How comes these other changes, that you say are equivalent, have not been merged yet?
>>>
>>> Christopher has already decided to apply the patch that you mentioned, I hope there will be the same functionality implemented at least before next release...
>>
>> I've given feedback several times. I'm not sure what happened, and I
>> can't remember if we couldn't come to a conclusion or if it simply fell
>> off my plate.
>
> I think that's my fault. The last feedback was that you weren't sure
> that the approach needs its own module or not. Remember, Gentoo has
> moved those definitions inside its own module (xdg.*) to refer to the
> base specification where those locations have been defined. This is
> for a couple of reasons: to not make userdomain larger than it is
> already, to make use of the modularity that refpolicy provides, and to
> facilitate some compatibility (no xdg module, then the locations
> remain user_home_t for instance).
>
> A year or two later, a separate xdg module was suggested by Dominick
> as well (with similar concept as Gentoo has), but it fell through the
> cracks too (no discussion on it [1]).
>
> [1] http://oss.tresys.com/pipermail/refpolicy/2013-November/006621.html
>
> So one of the decisions we need to take is if a separate module is
> warranted or not. This can go either way, and if you or the community
> at large prefers to put it in the userdomain, then I can agree to
> follow it - I might not fully stand behind it, but this is a community
> effort after all, and I too prefer to get things forward (so,
> apologies that I didn't follow up then).
>
> My suggestion would be as follows:
>
> I'll go through Guido's patch and see if there are any *conceptual*
> differences between his patch and Gentoo's approach. If there are,
> we'll discuss them here to see what is the best way forward. If
> Gentoo's conceptual design is more preferred then we'll probably base
> it on Gentoo's current policy code base. If Guido's is preferential
> then we start off with Guido's.
>
> Once the conceptual differences have been resolved (or there weren't
> to begin with), then the next step would be to publish the patch round
> again (whatever based upon) with the merged changes from both sets (be
> it Gentoo's or Guido's). As Jason already mentioned - yes, this is a
> big patch, so it also makes sense to do this in a step-wise approach
> rather than one big patch set.
>
> Is that feasible for you guys? I know I haven't been around/active for
> a long time but that's about to change ;-)
Makes sense to me.
--
Chris PeBenito
Hello.
Conceptually the patch that I submitted can be synthesised as follows:
- never allow any domain to read or write user home directories' content unless a specific "enable_homedir" boolean is set to true (default value is false, for all daemons and applications);
- always allow all domains that were previously allowed to read and/or write user home directories' content to read and/or write the "Download" subdirectory *only* (this is treated as a shared parking area);
- the only exception to the first above rule is when a domain *absolutely* needs to read or write the user home directories' content for working properly (most notably, gnome-shell needs to manage and execute temporary files in the user home directory; I don't think there are other exceptions, apart from user management applications that need to create user home directories NOT content).
I hope this helps.
Regards,
Guido
On the 6th of May 2017 18:36:08 CEST, Chris PeBenito via refpolicy <[email protected]> wrote:
>On 05/06/2017 07:59 AM, Sven Vermeulen via refpolicy wrote:
>> On Sun, Apr 23, 2017 at 3:14 PM, Chris PeBenito via refpolicy
>> <[email protected]> wrote:
>>> On 04/22/2017 07:50 AM, Guido Trentalancia via refpolicy wrote:
>>>> The patchset that I have posted the other day is ready to use, now.
>>>>
>>>> How comes these other changes, that you say are equivalent, have
>not been merged yet?
>>>>
>>>> Christopher has already decided to apply the patch that you
>mentioned, I hope there will be the same functionality implemented at
>least before next release...
>>>
>>> I've given feedback several times. I'm not sure what happened, and
>I
>>> can't remember if we couldn't come to a conclusion or if it simply
>fell
>>> off my plate.
>>
>> I think that's my fault. The last feedback was that you weren't sure
>> that the approach needs its own module or not. Remember, Gentoo has
>> moved those definitions inside its own module (xdg.*) to refer to the
>> base specification where those locations have been defined. This is
>> for a couple of reasons: to not make userdomain larger than it is
>> already, to make use of the modularity that refpolicy provides, and
>to
>> facilitate some compatibility (no xdg module, then the locations
>> remain user_home_t for instance).
>>
>> A year or two later, a separate xdg module was suggested by Dominick
>> as well (with similar concept as Gentoo has), but it fell through the
>> cracks too (no discussion on it [1]).
>>
>> [1]
>http://oss.tresys.com/pipermail/refpolicy/2013-November/006621.html
>>
>> So one of the decisions we need to take is if a separate module is
>> warranted or not. This can go either way, and if you or the community
>> at large prefers to put it in the userdomain, then I can agree to
>> follow it - I might not fully stand behind it, but this is a
>community
>> effort after all, and I too prefer to get things forward (so,
>> apologies that I didn't follow up then).
>>
>> My suggestion would be as follows:
>>
>> I'll go through Guido's patch and see if there are any *conceptual*
>> differences between his patch and Gentoo's approach. If there are,
>> we'll discuss them here to see what is the best way forward. If
>> Gentoo's conceptual design is more preferred then we'll probably base
>> it on Gentoo's current policy code base. If Guido's is preferential
>> then we start off with Guido's.
>>
>> Once the conceptual differences have been resolved (or there weren't
>> to begin with), then the next step would be to publish the patch
>round
>> again (whatever based upon) with the merged changes from both sets
>(be
>> it Gentoo's or Guido's). As Jason already mentioned - yes, this is a
>> big patch, so it also makes sense to do this in a step-wise approach
>> rather than one big patch set.
>>
>> Is that feasible for you guys? I know I haven't been around/active
>for
>> a long time but that's about to change ;-)
>
>
>Makes sense to me.
I forgot to add:
Of course, the configuration can be automated on distributions...
On the 6th of May 2017 19:00:09 CEST, Guido Trentalancia via refpolicy <[email protected]> wrote:
>Hello.
>
>Conceptually the patch that I submitted can be synthesised as follows:
>
>- never allow any domain to read or write user home directories'
>content unless a specific "enable_homedir" boolean is set to true
>(default value is false, for all daemons and applications);
For maximum usability, distributions can turn the corresponding boolean to true upon installing a given daemon or application and turn it to false upon deinstalling it (e.g. from the .spec file on distributions using RPM or similar).
At any time, end-users can fine-tune the above using setsebool manually to maximize user data confidentiality instead of usability.
>- always allow all domains that were previously allowed to read and/or
>write user home directories' content to read and/or write the
>"Download" subdirectory *only* (this is treated as a shared parking
>area);
>
>- the only exception to the first above rule is when a domain
>*absolutely* needs to read or write the user home directories' content
>for working properly (most notably, gnome-shell needs to manage and
>execute temporary files in the user home directory; I don't think there
>are other exceptions, apart from user management applications that need
>to create user home directories NOT content).
>
>I hope this helps.
>
>Regards,
>
>Guido
>
>On the 6th of May 2017 18:36:08 CEST, Chris PeBenito via refpolicy
><[email protected]> wrote:
>>On 05/06/2017 07:59 AM, Sven Vermeulen via refpolicy wrote:
>>> On Sun, Apr 23, 2017 at 3:14 PM, Chris PeBenito via refpolicy
>>> <[email protected]> wrote:
>>>> On 04/22/2017 07:50 AM, Guido Trentalancia via refpolicy wrote:
>>>>> The patchset that I have posted the other day is ready to use,
>now.
>>>>>
>>>>> How comes these other changes, that you say are equivalent, have
>>not been merged yet?
>>>>>
>>>>> Christopher has already decided to apply the patch that you
>>mentioned, I hope there will be the same functionality implemented at
>>least before next release...
>>>>
>>>> I've given feedback several times. I'm not sure what happened, and
>>I
>>>> can't remember if we couldn't come to a conclusion or if it simply
>>fell
>>>> off my plate.
>>>
>>> I think that's my fault. The last feedback was that you weren't sure
>>> that the approach needs its own module or not. Remember, Gentoo has
>>> moved those definitions inside its own module (xdg.*) to refer to
>the
>>> base specification where those locations have been defined. This is
>>> for a couple of reasons: to not make userdomain larger than it is
>>> already, to make use of the modularity that refpolicy provides, and
>>to
>>> facilitate some compatibility (no xdg module, then the locations
>>> remain user_home_t for instance).
>>>
>>> A year or two later, a separate xdg module was suggested by Dominick
>>> as well (with similar concept as Gentoo has), but it fell through
>the
>>> cracks too (no discussion on it [1]).
>>>
>>> [1]
>>http://oss.tresys.com/pipermail/refpolicy/2013-November/006621.html
>>>
>>> So one of the decisions we need to take is if a separate module is
>>> warranted or not. This can go either way, and if you or the
>community
>>> at large prefers to put it in the userdomain, then I can agree to
>>> follow it - I might not fully stand behind it, but this is a
>>community
>>> effort after all, and I too prefer to get things forward (so,
>>> apologies that I didn't follow up then).
>>>
>>> My suggestion would be as follows:
>>>
>>> I'll go through Guido's patch and see if there are any *conceptual*
>>> differences between his patch and Gentoo's approach. If there are,
>>> we'll discuss them here to see what is the best way forward. If
>>> Gentoo's conceptual design is more preferred then we'll probably
>base
>>> it on Gentoo's current policy code base. If Guido's is preferential
>>> then we start off with Guido's.
>>>
>>> Once the conceptual differences have been resolved (or there weren't
>>> to begin with), then the next step would be to publish the patch
>>round
>>> again (whatever based upon) with the merged changes from both sets
>>(be
>>> it Gentoo's or Guido's). As Jason already mentioned - yes, this is a
>>> big patch, so it also makes sense to do this in a step-wise approach
>>> rather than one big patch set.
>>>
>>> Is that feasible for you guys? I know I haven't been around/active
>>for
>>> a long time but that's about to change ;-)
>>
>>
>>Makes sense to me.
>
>_______________________________________________
>refpolicy mailing list
>refpolicy at oss.tresys.com
>http://oss.tresys.com/mailman/listinfo/refpolicy
On Sat, May 6, 2017 at 7:00 PM, Guido Trentalancia via refpolicy
<[email protected]> wrote:
> Conceptually the patch that I submitted can be synthesised as follows:
>
> - never allow any domain to read or write user home directories' content unless a specific "enable_homedir" boolean is set to true (default value is false, for all daemons and applications);
In our setup, we use four booleans:
*_read_generic_user_content (read rights on user_home_t)
*_manage_generic_user_content (manage rights on user_home_t)
*_read_all_user_content (read rights on not only user_home_t but on
all content types that a regular user domain has access to, handled
through the user_home_content_type attribute)
*_manage_all_user_content (manage rights on all content types that a
regular user domain has access to)
We even try to automatically set those on each domain, but we needed
to hack it a bit for the boolean documentation: we use a template to
automatically generate the booleans and its underlying code, but the
order in which things are done makes it that the in-line documentation
for those booleans (you know, the <desc><p>...</p></desc> stuff) isn't
taken up. We haven't put more effort in changing this order (also to
ensure compatibility) so we just add the missing documentation into
its own gentoo_tunables.xml file in the doc/ subfolder.
Automatically creating the booleans and the various tunable_policy()
statements makes it very easy to include it, which is something I
favor. Perhaps the documentation generation can be automated as well.
I don't like having to include the same set of rules in every user
domain that wants to access user content (or even daemons). By using a
single template, it can be adapted as the user privileges adapt with
new initiatives or innovations in the SELinux policy area.
> - always allow all domains that were previously allowed to read and/or write user home directories' content to read and/or write the "Download" subdirectory *only* (this is treated as a shared parking area);
We only do this for domains where the download directory is intuitive
(like browsers). For instance, image viewers we use the Pictures/
directory for (xdg_pictures_home_t) while media players are for the
Music (xdg_music_home_t) and Videos (xdg_videos_home_t) locations.
However, I'm personally less concerned about what default we should
pick in the reference policy itself, and leave that up to the
distributions (as you mentioned in the other post). Let's focus first
on the content before we make the final choices on the defaults.
Wkr,
Sven
Potentially there are a few updates for this patchset...
I have not heard anything back, none of the two options has been merged
yet, so I don't know what to do.
Regards,
Guido
On 06/05/2017 alle 19.10 +0200, Guido Trentalancia via
refpolicy wrote:
> I forgot to add:
>
> Of course, the configuration can be automated on distributions...
>
> On the 6th of May 2017 19:00:09 CEST, Guido Trentalancia via
> refpolicy <[email protected]> wrote:
> > Hello.
> >
> > Conceptually the patch that I submitted can be synthesised as
> > follows:
> >
> > - never allow any domain to read or write user home directories'
> > content unless a specific "enable_homedir" boolean is set to true
> > (default value is false, for all daemons and applications);
>
> For maximum usability, distributions can turn the corresponding
> boolean to true upon installing a given daemon or application and
> turn it to false upon deinstalling it (e.g. from the .spec file on
> distributions using RPM or similar).
>
> At any time, end-users can fine-tune the above using setsebool
> manually to maximize user data confidentiality instead of usability.
>
> > - always allow all domains that were previously allowed to read
> > and/or
> > write user home directories' content to read and/or write the
> > "Download" subdirectory *only* (this is treated as a shared parking
> > area);
> >
> > - the only exception to the first above rule is when a domain
> > *absolutely* needs to read or write the user home directories'
> > content
> > for working properly (most notably, gnome-shell needs to manage and
> > execute temporary files in the user home directory; I don't think
> > there
> > are other exceptions, apart from user management applications that
> > need
> > to create user home directories NOT content).
> >
> > I hope this helps.
> >
> > Regards,
> >
> > Guido
> >
> > On the 6th of May 2017 18:36:08 CEST, Chris PeBenito via refpolicy
> > <[email protected]> wrote:
> > > On 05/06/2017 07:59 AM, Sven Vermeulen via refpolicy wrote:
> > > > On Sun, Apr 23, 2017 at 3:14 PM, Chris PeBenito via refpolicy
> > > > <[email protected]> wrote:
> > > > > On 04/22/2017 07:50 AM, Guido Trentalancia via refpolicy
> > > > > wrote:
> > > > > > The patchset that I have posted the other day is ready to
> > > > > > use,
> >
> > now.
> > > > > >
> > > > > > How comes these other changes, that you say are equivalent,
> > > > > > have
> > >
> > > not been merged yet?
> > > > > >
> > > > > > Christopher has already decided to apply the patch that you
> > >
> > > mentioned, I hope there will be the same functionality
> > > implemented at
> > > least before next release...
> > > > >
> > > > > I've given feedback several times. I'm not sure what
> > > > > happened, and
> > >
> > > I
> > > > > can't remember if we couldn't come to a conclusion or if it
> > > > > simply
> > >
> > > fell
> > > > > off my plate.
> > > >
> > > > I think that's my fault. The last feedback was that you weren't
> > > > sure
> > > > that the approach needs its own module or not. Remember, Gentoo
> > > > has
> > > > moved those definitions inside its own module (xdg.*) to refer
> > > > to
> >
> > the
> > > > base specification where those locations have been defined.
> > > > This is
> > > > for a couple of reasons: to not make userdomain larger than it
> > > > is
> > > > already, to make use of the modularity that refpolicy provides,
> > > > and
> > >
> > > to
> > > > facilitate some compatibility (no xdg module, then the
> > > > locations
> > > > remain user_home_t for instance).
> > > >
> > > > A year or two later, a separate xdg module was suggested by
> > > > Dominick
> > > > as well (with similar concept as Gentoo has), but it fell
> > > > through
> >
> > the
> > > > cracks too (no discussion on it [1]).
> > > >
> > > > [1]
> > >
> > > http://oss.tresys.com/pipermail/refpolicy/2013-November/006621.ht
> > > ml
> > > >
> > > > So one of the decisions we need to take is if a separate module
> > > > is
> > > > warranted or not. This can go either way, and if you or the
> >
> > community
> > > > at large prefers to put it in the userdomain, then I can agree
> > > > to
> > > > follow it - I might not fully stand behind it, but this is a
> > >
> > > community
> > > > effort after all, and I too prefer to get things forward (so,
> > > > apologies that I didn't follow up then).
> > > >
> > > > My suggestion would be as follows:
> > > >
> > > > I'll go through Guido's patch and see if there are any
> > > > *conceptual*
> > > > differences between his patch and Gentoo's approach. If there
> > > > are,
> > > > we'll discuss them here to see what is the best way forward. If
> > > > Gentoo's conceptual design is more preferred then we'll
> > > > probably
> >
> > base
> > > > it on Gentoo's current policy code base. If Guido's is
> > > > preferential
> > > > then we start off with Guido's.
> > > >
> > > > Once the conceptual differences have been resolved (or there
> > > > weren't
> > > > to begin with), then the next step would be to publish the
> > > > patch
> > >
> > > round
> > > > again (whatever based upon) with the merged changes from both
> > > > sets
> > >
> > > (be
> > > > it Gentoo's or Guido's). As Jason already mentioned - yes, this
> > > > is a
> > > > big patch, so it also makes sense to do this in a step-wise
> > > > approach
> > > > rather than one big patch set.
> > > >
> > > > Is that feasible for you guys? I know I haven't been
> > > > around/active
> > >
> > > for
> > > > a long time but that's about to change ;-)
> > >
> > >
> > > Makes sense to me.
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
On 06/09/2017 07:40 AM, Guido Trentalancia via refpolicy wrote:
> Potentially there are a few updates for this patchset...
>
> I have not heard anything back, none of the two options has been merged
> yet, so I don't know what to do.
>
> Regards,
>
> Guido
Sven, did you have any further updates on this patchset?
> On 06/05/2017 alle 19.10 +0200, Guido Trentalancia via
> refpolicy wrote:
>> I forgot to add:
>>
>> Of course, the configuration can be automated on distributions...
>>
>> On the 6th of May 2017 19:00:09 CEST, Guido Trentalancia via
>> refpolicy <[email protected]> wrote:
>>> Hello.
>>>
>>> Conceptually the patch that I submitted can be synthesised as
>>> follows:
>>>
>>> - never allow any domain to read or write user home directories'
>>> content unless a specific "enable_homedir" boolean is set to true
>>> (default value is false, for all daemons and applications);
>>
>> For maximum usability, distributions can turn the corresponding
>> boolean to true upon installing a given daemon or application and
>> turn it to false upon deinstalling it (e.g. from the .spec file on
>> distributions using RPM or similar).
>>
>> At any time, end-users can fine-tune the above using setsebool
>> manually to maximize user data confidentiality instead of usability.
>>
>>> - always allow all domains that were previously allowed to read
>>> and/or
>>> write user home directories' content to read and/or write the
>>> "Download" subdirectory *only* (this is treated as a shared parking
>>> area);
>>>
>>> - the only exception to the first above rule is when a domain
>>> *absolutely* needs to read or write the user home directories'
>>> content
>>> for working properly (most notably, gnome-shell needs to manage and
>>> execute temporary files in the user home directory; I don't think
>>> there
>>> are other exceptions, apart from user management applications that
>>> need
>>> to create user home directories NOT content).
>>>
>>> I hope this helps.
>>>
>>> Regards,
>>>
>>> Guido
>>>
>>> On the 6th of May 2017 18:36:08 CEST, Chris PeBenito via refpolicy
>>> <[email protected]> wrote:
>>>> On 05/06/2017 07:59 AM, Sven Vermeulen via refpolicy wrote:
>>>>> On Sun, Apr 23, 2017 at 3:14 PM, Chris PeBenito via refpolicy
>>>>> <[email protected]> wrote:
>>>>>> On 04/22/2017 07:50 AM, Guido Trentalancia via refpolicy
>>>>>> wrote:
>>>>>>> The patchset that I have posted the other day is ready to
>>>>>>> use,
>>>
>>> now.
>>>>>>>
>>>>>>> How comes these other changes, that you say are equivalent,
>>>>>>> have
>>>>
>>>> not been merged yet?
>>>>>>>
>>>>>>> Christopher has already decided to apply the patch that you
>>>>
>>>> mentioned, I hope there will be the same functionality
>>>> implemented at
>>>> least before next release...
>>>>>>
>>>>>> I've given feedback several times. I'm not sure what
>>>>>> happened, and
>>>>
>>>> I
>>>>>> can't remember if we couldn't come to a conclusion or if it
>>>>>> simply
>>>>
>>>> fell
>>>>>> off my plate.
>>>>>
>>>>> I think that's my fault. The last feedback was that you weren't
>>>>> sure
>>>>> that the approach needs its own module or not. Remember, Gentoo
>>>>> has
>>>>> moved those definitions inside its own module (xdg.*) to refer
>>>>> to
>>>
>>> the
>>>>> base specification where those locations have been defined.
>>>>> This is
>>>>> for a couple of reasons: to not make userdomain larger than it
>>>>> is
>>>>> already, to make use of the modularity that refpolicy provides,
>>>>> and
>>>>
>>>> to
>>>>> facilitate some compatibility (no xdg module, then the
>>>>> locations
>>>>> remain user_home_t for instance).
>>>>>
>>>>> A year or two later, a separate xdg module was suggested by
>>>>> Dominick
>>>>> as well (with similar concept as Gentoo has), but it fell
>>>>> through
>>>
>>> the
>>>>> cracks too (no discussion on it [1]).
>>>>>
>>>>> [1]
>>>>
>>>> http://oss.tresys.com/pipermail/refpolicy/2013-November/006621.ht
>>>> ml
>>>>>
>>>>> So one of the decisions we need to take is if a separate module
>>>>> is
>>>>> warranted or not. This can go either way, and if you or the
>>>
>>> community
>>>>> at large prefers to put it in the userdomain, then I can agree
>>>>> to
>>>>> follow it - I might not fully stand behind it, but this is a
>>>>
>>>> community
>>>>> effort after all, and I too prefer to get things forward (so,
>>>>> apologies that I didn't follow up then).
>>>>>
>>>>> My suggestion would be as follows:
>>>>>
>>>>> I'll go through Guido's patch and see if there are any
>>>>> *conceptual*
>>>>> differences between his patch and Gentoo's approach. If there
>>>>> are,
>>>>> we'll discuss them here to see what is the best way forward. If
>>>>> Gentoo's conceptual design is more preferred then we'll
>>>>> probably
>>>
>>> base
>>>>> it on Gentoo's current policy code base. If Guido's is
>>>>> preferential
>>>>> then we start off with Guido's.
>>>>>
>>>>> Once the conceptual differences have been resolved (or there
>>>>> weren't
>>>>> to begin with), then the next step would be to publish the
>>>>> patch
>>>>
>>>> round
>>>>> again (whatever based upon) with the merged changes from both
>>>>> sets
>>>>
>>>> (be
>>>>> it Gentoo's or Guido's). As Jason already mentioned - yes, this
>>>>> is a
>>>>> big patch, so it also makes sense to do this in a step-wise
>>>>> approach
>>>>> rather than one big patch set.
>>>>>
>>>>> Is that feasible for you guys? I know I haven't been
>>>>> around/active
>>>>
>>>> for
>>>>> a long time but that's about to change ;-)
>>>>
>>>>
>>>> Makes sense to me.
--
Chris PeBenito
On Aug 6, 2017 11:10 PM, "Chris PeBenito via refpolicy" <
[email protected]> wrote:
On 06/09/2017 07:40 AM, Guido Trentalancia via refpolicy wrote:
> Potentially there are a few updates for this patchset...
>
> I have not heard anything back, none of the two options has been merged
> yet, so I don't know what to do.
>
> Regards,
>
> Guido
Sven, did you have any further updates on this patchset?
Not yet. You were the only ones with some comments on the Gentoo-based
patch set, and one of then was that you wanted to see if other comments
came through.
Other than that you mentioned that in some places the naming isn't what you
would expect but you didn't say what that was.
I'm open to update the patch with fixed naming once I know what direction
to go with, as naming differences can be handled by Gentoo with aliases to
make the transition smoothly.
Wkr,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20170808/00ba8011/attachment.html