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