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.
