[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:
>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
><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,
>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



More information about the refpolicy mailing list