On Wed, Nov 27, 2019 at 10:03:44AM -0500, Stephen Smalley wrote:
> On 11/27/19 6:22 AM, Dominick Grift wrote:
> > On Tue, Nov 26, 2019 at 01:27:42PM -0500, Stephen Smalley wrote:
> > > 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.
> >
> > I am thinking that we might be able to add something to cil_resolve_userprefix() that would just not process any entries referencing the "prefix" keyword as in "user ... prefix ...;" instead of "user ... rbacseprole ...;", and instead emits a warning: "Not processing deprecated userprefix: userprefix. Use userrbacseprole instead."
> > That would then just not add those entries to users_extra, and instead rely on "fallback_rbacseprole=object_r" in genhomedircon.c, if the "migration" code in libsemanage does not catch it first.
>
> I don't think we want warnings; otherwise someone upgrading Fedora to new
> userspace would get constant warnings on all subsequent libsemanage
> transactions due to their existing distro-provided users_extra file.
>
> Also, not to bikeshed, but userrbacseprole is hard on the eyes. Looks like
> libsemanage/src/genhomedircon.c currently tests whether the prefix value is
> a homedir role (prefix_is_homedir_role()) and uses it as such in that case.
> Can we just do that? And if we have to rename it, maybe just call it
> homedir_role instead.
I would then prefer something like "userfilerole", "filerole" and "user ... filerole ...;"
homedir_role is inaccurate. It never was a homedir only thing:
/tmp, /var/tmp, /run/user/%{USERID}, /var/spool/mail/%{USERNAME}, /home, /dev/shm
>
>
>
>
--
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:
signature.asc
Description: PGP signature
