Re: [PATCH 1/1] genhomedircon: support policies using RBACSEP

[Gary Tierney <gary.tierney@gmx.com>]

[-- Attachment #1: Type: text/plain, Size: 4265 bytes --]

On Fri, Sep 23, 2016 at 03:36:47PM -0400, Stephen Smalley wrote:
>On 09/23/2016 10:28 AM, 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 was previously used as a prefix for types, e.g. you
>could have:
>HOME_DIR/\.gnupg(/.+)?  system_u:object_r:ROLE_gpg_secret_t
>and get it replaced with:
>/home/[^/]+/\.gnupg(/.+)?       system_u:object_r:user_gpg_secret_t
>/root/\.gnupg(/.+)?             system_u:object_r:sysadm_gpg_secret_t
>
>So I guess you could use it for the role field too, but for consistency
>you would want it to be:
>HOME_DIR/\.gnupg(/.+)?  system_u:ROLE_r:ROLE_gpg_secret_t
>
>and the prefix would still just be "user".
>

That would work for us currently with refpolicy, but if I write a 
similar CIL statement:

(filecon "HOME_DIR/\.gnupg(/.+)?" (system_u ROLE_r ROLE_gpg_secret_t))

Then I get a compile error because secilc thinks ROLE_r is the name of 
the role.  I don't think there's any way to work around this in CIL.

>>
>> 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@gmx.com>
>> ---
>>  libsemanage/src/conf-parse.y    | 14 +++++++++++++-
>>  libsemanage/src/conf-scan.l     |  1 +
>>  libsemanage/src/genhomedircon.c | 30 +++++++++++++++++++++++++++++-
>>  libsemanage/src/semanage_conf.h |  1 +
>>  4 files changed, 44 insertions(+), 2 deletions(-)
>>
>>
>> diff --git a/libsemanage/src/genhomedircon.c b/libsemanage/src/genhomedircon.c
>> index 3fc9e7a..98f9ebd 100644
>> --- a/libsemanage/src/genhomedircon.c
>> +++ b/libsemanage/src/genhomedircon.c
>> @@ -857,7 +866,7 @@ static int setup_fallback_user(genhomedircon_settings_t * s)
>>  	int errors = 0;
>>
>>  	retval = semanage_seuser_list(s->h_semanage, &seuser_list, &nseusers);
>> -	if (retval < 0 || (nseusers < 1)) {
>> +	if (retval < 0 || (nseusers < 2)) {
>
>Why did this test change?
>

My mistake, didn't intend to include that in this patch.

>>  		/* if there are no users, this function can't do any other 
>>  		work */
>>  		return errors;
>>  	}
>> @@ -886,6 +895,17 @@ static int setup_fallback_user(genhomedircon_settings_t * s)
>>  					level = FALLBACK_LEVEL;
>>  			}
>>
>> +			if (u && s->h_semanage->conf->genhomedircon_rbacsep &&
>> +			    !semanage_user_has_role(u, prefix)) {
>
>I don't think you want to use prefix alone here, since it may be a
>prefix rather than a role name.
>
>The kernel policy contains the list of authorized roles for the user, so
>libsepol could export that, but that won't tell you anything about a
>default.
>
>libselinux get_default_context() and friends are context-sensitive (the
>result depends on the caller's context, such that it may differ for
>login vs sshd vs gdm and even among multiple distinct instances of any
>of these, e.g. if they have different levels), so I don't think you can
>use those.
>
>I don't think we presently provide a good way to find this information,
>which is why we added the user prefix in the first place.  But it is
>intended to be a prefix, not a role.

Do you have any suggestions on how this information could be configured? 
I toyed with extending the policy language to support something like a 
"userhomedirrole" statement, but didn't look too much into what the 
implications of that would be.  That doesn't seem too suitable either 
since it'd only be used by genhomedircon.

I agree that the prefix isn't really suitable and this is more of a hack 
than a good solution (I forgot to include RFC in the subject!), though 
I'm unsure what the next step would be in creating a good solution for 
this.  Any input would be appreciated.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]