Message ID | 161947648054.55076.7300753011213416749.stgit@olly (mailing list archive) |
---|---|
State | Changes Requested |
Delegated to: | Ondrej Mosnáček |
Headers | show |
Series | testsuite: fix cap_userns for kernels >= v5.12 | expand |
On Tue, Apr 27, 2021 at 12:34 AM Paul Moore <paul@paul-moore.com> wrote: > Starting with Linux v5.12 CAP_SETFCAP is required to map UID 0/root. > This is due to kernel commit db2e718a4798 ("capabilities: require > CAP_SETFCAP to map uid 0"). In order to resolve this in the test > suite allow the test_cap_userns_t domain to exercise the setfcap > capability. Thanks! We hit this in our mainline kernel CI as well and I was going to send a patch for this, but I didn't have the right kernel build at hand to test, so I deferred it. One comment below. > > Signed-off-by: Paul Moore <paul@paul-moore.com> > --- > policy/test_cap_userns.te | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/policy/test_cap_userns.te b/policy/test_cap_userns.te > index ab74325..052afea 100644 > --- a/policy/test_cap_userns.te > +++ b/policy/test_cap_userns.te > @@ -14,6 +14,7 @@ typeattribute test_cap_userns_t capusernsdomain; > > # This domain is allowed sys_admin on non-init userns for mount. > allow test_cap_userns_t self:cap_userns sys_admin; > +allow test_cap_userns_t self:capability setfcap; I think we should allow the capability to both domains (i.e. to capusernsdomain). We are testing cap_userns::sys_admin here and if the tested operation is not denied for a domain that has only capability::setfcap, we want the test to fail. Also, a comment with a sentence explaining why CAP_SETFCAP is needed would be nice :) > > # Domain for process that is not allowed non-init userns capabilities > type test_no_cap_userns_t; > -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
On Tue, Apr 27, 2021 at 4:33 AM Ondrej Mosnacek <omosnace@redhat.com> wrote: > On Tue, Apr 27, 2021 at 12:34 AM Paul Moore <paul@paul-moore.com> wrote: > > diff --git a/policy/test_cap_userns.te b/policy/test_cap_userns.te > > index ab74325..052afea 100644 > > --- a/policy/test_cap_userns.te > > +++ b/policy/test_cap_userns.te > > @@ -14,6 +14,7 @@ typeattribute test_cap_userns_t capusernsdomain; > > > > # This domain is allowed sys_admin on non-init userns for mount. > > allow test_cap_userns_t self:cap_userns sys_admin; > > +allow test_cap_userns_t self:capability setfcap; > > I think we should allow the capability to both domains (i.e. to > capusernsdomain). We are testing cap_userns::sys_admin here and if the > tested operation is not denied for a domain that has only > capability::setfcap, we want the test to fail. > > Also, a comment with a sentence explaining why CAP_SETFCAP is needed > would be nice :) Fair enough, v2 will be out shortly.
diff --git a/policy/test_cap_userns.te b/policy/test_cap_userns.te index ab74325..052afea 100644 --- a/policy/test_cap_userns.te +++ b/policy/test_cap_userns.te @@ -14,6 +14,7 @@ typeattribute test_cap_userns_t capusernsdomain; # This domain is allowed sys_admin on non-init userns for mount. allow test_cap_userns_t self:cap_userns sys_admin; +allow test_cap_userns_t self:capability setfcap; # Domain for process that is not allowed non-init userns capabilities type test_no_cap_userns_t;
Starting with Linux v5.12 CAP_SETFCAP is required to map UID 0/root. This is due to kernel commit db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0"). In order to resolve this in the test suite allow the test_cap_userns_t domain to exercise the setfcap capability. Signed-off-by: Paul Moore <paul@paul-moore.com> --- policy/test_cap_userns.te | 1 + 1 file changed, 1 insertion(+)