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

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

[Dominick Grift]

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.

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

-- 
2.24.0

[RFC 1/3] libsemanage: fall back to valid "object_r" role instead of "user" prefix string

[Dominick Grift]

There are a few references to the "user" prefix that have to be changed to a valid role so that cil_resolve_userprefix can be made to validate the given role.
Fortunately object_r is alway's there. I do not like to hard-code identifiers but I see no other option.

Signed-off-by: Dominick Grift <dac.override@gmail.com>
---
 libsemanage/src/genhomedircon.c | 2 +-
 libsemanage/src/user_record.c   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libsemanage/src/genhomedircon.c b/libsemanage/src/genhomedircon.c
index d08c88de..6a21223d 100644
--- a/libsemanage/src/genhomedircon.c
+++ b/libsemanage/src/genhomedircon.c
@@ -85,7 +85,7 @@
 #define TEMPLATE_USERID "%{USERID}"
 
 #define FALLBACK_SENAME "user_u"
-#define FALLBACK_PREFIX "user"
+#define FALLBACK_PREFIX "object_r"
 #define FALLBACK_LEVEL "s0"
 #define FALLBACK_NAME "[^/]+"
 #define FALLBACK_UIDGID "[0-9]+"
diff --git a/libsemanage/src/user_record.c b/libsemanage/src/user_record.c
index 45239250..91228eb8 100644
--- a/libsemanage/src/user_record.c
+++ b/libsemanage/src/user_record.c
@@ -240,7 +240,7 @@ int semanage_user_create(semanage_handle_t * handle,
 		goto err;
 
 	/* Initialize the prefix for migration purposes */
-	if (semanage_user_extra_set_prefix(handle, tmp_user->extra, "user") < 0)
+	if (semanage_user_extra_set_prefix(handle, tmp_user->extra, "object_r") < 0)
 		goto err;
 
 	*user_ptr = tmp_user;
@@ -349,7 +349,7 @@ hidden int semanage_user_join(semanage_handle_t * handle,
 		    < 0)
 			goto err;
 		if (semanage_user_extra_set_prefix
-		    (handle, tmp_user->extra, "user") < 0)
+		    (handle, tmp_user->extra, "object_r") < 0)
 			goto err;
 	}
 
-- 
2.24.0

[RFC 2/3] semanage: do not default prefix to "user"

[Dominick Grift]

By default `semanage-user -m ...` resets the prefix to "user". We need it not to. Defaulting to '' results is no change to the current prefix.

Signed-off-by: Dominick Grift <dac.override@gmail.com>
---
 python/semanage/semanage | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/python/semanage/semanage b/python/semanage/semanage
index b2fabea6..e5abfdd2 100644
--- a/python/semanage/semanage
+++ b/python/semanage/semanage
@@ -425,7 +425,7 @@ def setupUserParser(subparsers):
                             help=_('''
 SELinux Roles.  You must enclose multiple roles within quotes, separate by spaces. Or specify -R multiple times.
 '''))
-    userParser.add_argument('-P', '--prefix', default="user", help=argparse.SUPPRESS)
+    userParser.add_argument('-P', '--prefix', default='', help=argparse.SUPPRESS)
     userParser.add_argument('selinux_name', nargs='?', default=None, help=_('selinux_name'))
     userParser.set_defaults(func=handleUser)
 
-- 
2.24.0

[RFC 3/3] cil: qualify roles from symtable when resolving userprefix

[Dominick Grift]

This ensures that the role in the userprefix statement is valid. Idea and implementation by Gary Tierney.

Signed-off-by: Dominick Grift <dac.override@gmail.com>
---
 libsepol/cil/src/cil.c             |  7 +++++--
 libsepol/cil/src/cil_internal.h    |  1 +
 libsepol/cil/src/cil_resolve_ast.c | 10 ++++------
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/libsepol/cil/src/cil.c b/libsepol/cil/src/cil.c
index de729cf8..aa3057ad 100644
--- a/libsepol/cil/src/cil.c
+++ b/libsepol/cil/src/cil.c
@@ -1218,6 +1218,7 @@ int cil_userprefixes_to_string_nopdb(struct cil_db *db, char **out, size_t *size
 	struct cil_list_item *curr;
 	struct cil_userprefix *userprefix = NULL;
 	struct cil_user *user = NULL;
+	struct cil_role *role = NULL;
 
 	*out = NULL;
 
@@ -1230,7 +1231,8 @@ int cil_userprefixes_to_string_nopdb(struct cil_db *db, char **out, size_t *size
 	cil_list_for_each(curr, db->userprefixes) {
 		userprefix = curr->data;
 		user = userprefix->user;
-		str_len += strlen("user ") + strlen(user->datum.fqn) + strlen(" prefix ") + strlen(userprefix->prefix_str) + 2;
+		role = userprefix->role;
+		str_len += strlen("user ") + strlen(user->datum.fqn) + strlen(" prefix ") + strlen(role->datum.fqn) + 2;
 	}
 
 	*size = str_len * sizeof(char);
@@ -1241,9 +1243,10 @@ int cil_userprefixes_to_string_nopdb(struct cil_db *db, char **out, size_t *size
 	cil_list_for_each(curr, db->userprefixes) {
 		userprefix = curr->data;
 		user = userprefix->user;
+		role = userprefix->role;
 
 		buf_pos = snprintf(str_tmp, str_len, "user %s prefix %s;\n", user->datum.fqn,
-									userprefix->prefix_str);
+				   role->datum.fqn);
 		str_len -= buf_pos;
 		str_tmp += buf_pos;
 	}
diff --git a/libsepol/cil/src/cil_internal.h b/libsepol/cil/src/cil_internal.h
index 30fab649..e52a4285 100644
--- a/libsepol/cil/src/cil_internal.h
+++ b/libsepol/cil/src/cil_internal.h
@@ -481,6 +481,7 @@ struct cil_userprefix {
 	char *user_str;
 	struct cil_user *user;
 	char *prefix_str;
+	struct cil_role *role;
 };
 
 struct cil_selinuxuser {
diff --git a/libsepol/cil/src/cil_resolve_ast.c b/libsepol/cil/src/cil_resolve_ast.c
index 87575860..28f3b418 100644
--- a/libsepol/cil/src/cil_resolve_ast.c
+++ b/libsepol/cil/src/cil_resolve_ast.c
@@ -952,7 +952,7 @@ int cil_resolve_userprefix(struct cil_tree_node *current, void *extra_args)
 {
 	struct cil_userprefix *userprefix = current->data;
 	struct cil_symtab_datum *user_datum = NULL;
-	struct cil_tree_node *user_node = NULL;
+	struct cil_symtab_datum *role_datum = NULL;
 	int rc = SEPOL_ERR;
 
 	rc = cil_resolve_name(current, userprefix->user_str, CIL_SYM_USERS, extra_args, &user_datum);
@@ -960,15 +960,13 @@ int cil_resolve_userprefix(struct cil_tree_node *current, void *extra_args)
 		goto exit;
 	}
 
-	user_node = user_datum->nodes->head->data;
-
-	if (user_node->flavor != CIL_USER) {
-		cil_log(CIL_ERR, "Userprefix must be a user: %s\n", user_datum->fqn);
-		rc = SEPOL_ERR;
+	rc = cil_resolve_name(current, userprefix->prefix_str, CIL_SYM_ROLES, extra_args, &role_datum);
+	if (rc != SEPOL_OK) {
 		goto exit;
 	}
 
 	userprefix->user = (struct cil_user*)user_datum;
+	userprefix->role = (struct cil_role*)role_datum;
 
 exit:
 	return rc;
-- 
2.24.0

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

[Stephen Smalley]

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.

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

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

[Dominick Grift]

[-- 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 --]

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

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3221 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.

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.

> 
> > 
> > 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 --]

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

[Stephen Smalley]

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

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

[Dominick Grift]

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

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.

> 
> > 
> > > 
> > > > 
> > > > 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 --]

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

[Stephen Smalley]

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.

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

[Dominick Grift]

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

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]