Re: [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition

[Stephen Smalley <sds@tycho.nsa.gov>]

On 11/25/19 9:10 AM, Dominick Grift wrote:
> On Mon, Nov 25, 2019 at 08:24:21AM -0500, Stephen Smalley wrote:
>> On 11/23/19 9:42 AM, Dominick Grift wrote:
>>> In 2008 support for UserPrefix was removed from Reference policy.
>>> The code to support this functionality in libsepol and libsemanage however remained albeit slightly modified.
>>> I am not sure why it was not fully removed.
>>>
>>> DefaultRole replaces UserPrefix functionality but the code in libsepol and libsemanage was only slighty adjusted to accomodate my use-case.
>>> This was done in 88e334f1923396d5ace56b8439c731dcde0d1f3b (2016).
>>> I do not use semanage and I do not mind using the old UserPrefix statement, but there is some confusion.
>>> For example there was a report recently about how semanage does not document UserPrefix.
>>> The documentation was likely removed from view because UserPrefix is no longer supported as such.
>>>
>>> I want to make the situation better and this proposal is the next phase.
>>> This proposal causes some disruption as Reference policy based policy often calls the gen_user() macro with the "user" prefix.
>>>
>>> Example: gen_user(user_u, user, user_r, s0, s0)
>>>
>>> This will no longer be valid, and the userprefix parameter in gen_user() can be left empty (or needs a valid role if RBACSEP DefaultRole is leveraged).
>>>
>>> Example: gen_user(user_u,, user_r, s0, s0)
>>>
>>> UserPrefix will now default to object_r. This should not affect common policy implementations.
>>>
>>> The next phases will be:
>>>
>>> Renaming the UserPrefix statement to UserRBACSEPRole, and renaming references to (user)?prefix to (user)?rbacseprole.
>>> Adjusting semanage to expose UserRBACSEPRole.
>>> Removing legacy UserPrefix (ROLE/USER_TEMPLATE) references from libsemanage.
>>>
>>> After this the UserPrefix to UserRBACSEPRole transition should be completed.
>>>
>>> This should get us by until someone decides to rewrite libsemanage to take advantage of CIL, simplify the code, and to make the code more robust.
>>
>> I guess my only question with regard to this phase and the next ones is with
>> regard to backward compatibility.  Even if no one is using this facility, we
>> have to make sure we do not break existing installs upon upgrade.
> 
> Maybe we can duplicate the code instead. That way we would not have to touch the existing, but dead userprefix code.
> That should address any compatibility issues.

At a minimum, we must avoid breaking existing installs upon upgrade, and 
we must avoid breaking compilation of existing policy modules (both 
refpolicy and CIL).

A simple test would be ensuring that if you upgrade the userspace and 
run semodule -B with your previously installed policy (including its 
existing userprefix statements), there are no errors and you get the 
same file_contexts.homedirs as you had before.

That should be relatively easy to ensure for targeted policy.  Might be 
more complicated with your policy, the CLIP policy, or perhaps others.

> 
>>
>>>
>>> Dominick Grift (3):
>>>     libsemanage: fall back to valid "object_r" role instead of "user"
>>>       prefix string
>>>     semanage: do not default prefix to "user"
>>>     cil: qualify roles from symtable when resolving userprefix
>>>
>>>    libsemanage/src/genhomedircon.c    |  2 +-
>>>    libsemanage/src/user_record.c      |  4 ++--
>>>    libsepol/cil/src/cil.c             |  7 +++++--
>>>    libsepol/cil/src/cil_internal.h    |  1 +
>>>    libsepol/cil/src/cil_resolve_ast.c | 10 ++++------
>>>    python/semanage/semanage           |  2 +-
>>>    6 files changed, 14 insertions(+), 12 deletions(-)
>>>
>>
>