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

[Dominick Grift <dac.override@gmail.com>]

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

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.

I believe that Reference policy and derivatives can and probably should already omit the "user" prefix from their gen_user() calls.
They probably can and probably should remove any UserPrefix statements altogether without any issues.

If there are no UserPrefixes present in the policy then genhomedircon should fall back to object_r.
Any upgrades will then just add specified userrbacseproles and other existing users should fall back to object_r via genhomedircon.

I might have overlooked aspects, and truth be told this is a little above my pay grade.
Then again this functionality is already broken, and it has been for a long time.

If Reference policy ever were to implement separation based on roles then this needs to be addressed first I believe.

> 
> > 
> > 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(-)
> > 
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

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