[refpolicy] [PATCH 0/33] description

Guido Trentalancia guido at trentalancia.net
Sat May 6 17:00:09 UTC 2017


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



More information about the refpolicy mailing list