On 09/23/2016 11:43 AM, Gary Tierney wrote:
> On Fri, Sep 23, 2016 at 03:28:44PM +0100, Gary Tierney wrote:
>> Introduces support for generating homedir/user contexts for
>> policies that implement RBACSEP. The support works by taking the
>> prefix of a logins seuser and replacing the role field in their
>> context specifications with the prefix. A new option
>> "genhomedircon-rbacsep" was added to /etc/selinux/semanage.conf
>> to allow toggling this behavior.
>>
>> The user prefix can be set from both standard kernel policy and
>> CIL:
>>
>> CIL: (user user_u) (role user_r) (userrole user_u user_r)
>> (userprefix user_u user_r)
>>
>> kernel policy language: role user_r; user user_u roles { user_r }
>> prefix user_r;
>>
>> Signed-off-by: Gary Tierney <gary.tierney@xxxxxxx>
<snip>
> perfinion at #selinux on freenode IRC suggested that the
> genhomedircon-rbacsep option should be dropped, and instead a
> RBACSEP context should be chosen first in all cases. If validation
> of this context fails, then it should fall back to whatever the
> existing role is.
>
> Anyone have thoughts on this? This seems to me like a much better
> solution than using a new genhomedircon-rbacsep option, but the
> problem of using "userprefix" still remains.
Does a valid RBACSEP context necessarily mean that RBACSEP was
desired/intended? (likely: otherwise the role-type association
wouldn't be authorized)
Does an invalid RBACSEP context necessarily mean that RBACSEP was not
desired/intended? (unclear: what if we just forgot the role-type
statement for a particular type)
Also, we base it on context validation, then it could differ for
different entries - some could end up with RBACSEP applied and others not.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
