* [RFC 1/3] libsemanage: fall back to valid "object_r" role instead of "user" prefix string
2019-11-23 14:42 [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition Dominick Grift
@ 2019-11-23 14:42 ` Dominick Grift
2019-11-23 14:42 ` [RFC 2/3] semanage: do not default prefix to "user" Dominick Grift
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Dominick Grift @ 2019-11-23 14:42 UTC (permalink / raw)
To: selinux; +Cc: 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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [RFC 2/3] semanage: do not default prefix to "user"
2019-11-23 14:42 [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition Dominick Grift
2019-11-23 14:42 ` [RFC 1/3] libsemanage: fall back to valid "object_r" role instead of "user" prefix string Dominick Grift
@ 2019-11-23 14:42 ` Dominick Grift
2019-11-23 14:42 ` [RFC 3/3] cil: qualify roles from symtable when resolving userprefix Dominick Grift
2019-11-25 13:24 ` [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition Stephen Smalley
3 siblings, 0 replies; 11+ messages in thread
From: Dominick Grift @ 2019-11-23 14:42 UTC (permalink / raw)
To: selinux; +Cc: 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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [RFC 3/3] cil: qualify roles from symtable when resolving userprefix
2019-11-23 14:42 [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition Dominick Grift
2019-11-23 14:42 ` [RFC 1/3] libsemanage: fall back to valid "object_r" role instead of "user" prefix string Dominick Grift
2019-11-23 14:42 ` [RFC 2/3] semanage: do not default prefix to "user" Dominick Grift
@ 2019-11-23 14:42 ` Dominick Grift
2019-11-25 13:24 ` [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition Stephen Smalley
3 siblings, 0 replies; 11+ messages in thread
From: Dominick Grift @ 2019-11-23 14:42 UTC (permalink / raw)
To: selinux; +Cc: 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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition
2019-11-23 14:42 [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition Dominick Grift
` (2 preceding siblings ...)
2019-11-23 14:42 ` [RFC 3/3] cil: qualify roles from symtable when resolving userprefix Dominick Grift
@ 2019-11-25 13:24 ` Stephen Smalley
2019-11-25 13:50 ` Dominick Grift
2019-11-25 14:10 ` Dominick Grift
3 siblings, 2 replies; 11+ messages in thread
From: Stephen Smalley @ 2019-11-25 13:24 UTC (permalink / raw)
To: Dominick Grift, selinux
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(-)
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition
2019-11-25 13:24 ` [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition Stephen Smalley
@ 2019-11-25 13:50 ` Dominick Grift
2019-11-25 14:10 ` Dominick Grift
1 sibling, 0 replies; 11+ messages in thread
From: Dominick Grift @ 2019-11-25 13:50 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition
2019-11-25 13:24 ` [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition Stephen Smalley
2019-11-25 13:50 ` Dominick Grift
@ 2019-11-25 14:10 ` Dominick Grift
2019-11-26 18:27 ` Stephen Smalley
1 sibling, 1 reply; 11+ messages in thread
From: Dominick Grift @ 2019-11-25 14:10 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition
2019-11-25 14:10 ` Dominick Grift
@ 2019-11-26 18:27 ` Stephen Smalley
2019-11-27 11:22 ` Dominick Grift
0 siblings, 1 reply; 11+ messages in thread
From: Stephen Smalley @ 2019-11-26 18:27 UTC (permalink / raw)
To: selinux, Dominick Grift
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(-)
>>>
>>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition
2019-11-26 18:27 ` Stephen Smalley
@ 2019-11-27 11:22 ` Dominick Grift
2019-11-27 15:03 ` Stephen Smalley
0 siblings, 1 reply; 11+ messages in thread
From: Dominick Grift @ 2019-11-27 11:22 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition
2019-11-27 11:22 ` Dominick Grift
@ 2019-11-27 15:03 ` Stephen Smalley
2019-11-27 15:25 ` Dominick Grift
0 siblings, 1 reply; 11+ messages in thread
From: Stephen Smalley @ 2019-11-27 15:03 UTC (permalink / raw)
To: selinux, Dominick Grift, Christopher J. PeBenito
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC 0/3] Second phase of UserPrefix to UserRBACSEPRole transition
2019-11-27 15:03 ` Stephen Smalley
@ 2019-11-27 15:25 ` Dominick Grift
0 siblings, 0 replies; 11+ messages in thread
From: Dominick Grift @ 2019-11-27 15:25 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, Christopher J. PeBenito
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread