[refpolicy] [PATCH 0/33] description

Guido Trentalancia guido at trentalancia.net
Sat May 6 17:10:54 UTC 2017

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 <refpolicy at oss.tresys.com> 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);

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
>- 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. 
>On the 6th of May 2017 18:36:08 CEST, Chris PeBenito via refpolicy
><refpolicy at oss.tresys.com> 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
>>> <refpolicy at oss.tresys.com> 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,
>>>>> 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
>>>> can't remember if we couldn't come to a conclusion or if it simply
>>>> 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
>>> 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
>>> 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
>>> cracks too (no discussion on it [1]).
>>> [1]
>>> 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
>>> 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
>>> 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
>>> 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
>>> again (whatever based upon) with the merged changes from both sets
>>> 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
>>> a long time but that's about to change ;-)
>>Makes sense to me.
>refpolicy mailing list
>refpolicy at oss.tresys.com

More information about the refpolicy mailing list