On Mon, Nov 25, 2019 at 4:18 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On 11/25/19 10:13 AM, Ondrej Mosnacek wrote: > > E.g. RHEL-5 has key_socket class in the policy, but not the > > system::module_request permission. > > > > Signed-off-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx> > > --- > > policy/Makefile | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/policy/Makefile b/policy/Makefile > > index 57cc172..7c2d21e 100644 > > --- a/policy/Makefile > > +++ b/policy/Makefile > > @@ -94,8 +94,10 @@ TARGETS+=test_notify.te > > endif > > > > ifeq ($(shell grep -q key_socket $(POLDEV)/include/support/all_perms.spt && echo true),true) > > +ifeq ($(shell grep -q module_request $(POLDEV)/include/support/all_perms.spt && echo true),true) > > TARGETS += test_key_socket.te > > endif > > +endif > > > > ifeq (x$(DISTRO),$(filter x$(DISTRO),xRHEL4 xRHEL5 xRHEL6)) > > TARGETS:=$(filter-out test_overlayfs.te test_mqueue.te test_ibpkey.te, $(TARGETS)) > > > > Alternatively, consider wrapping use of module_request in > test_key_socket.te with a suitable ifdef. Probably ought to be using > the policy interface, kernel_request_load_module(), and then we can just > wrap it with ifdef(`kernel_request_load_module', ...). Rationale: The > purpose of this test and its policy is to test the key_socket checks, > not module_request; allowing module_request is just incidental. Good point, I'll look into doing it that way in v3. (I posted v2 before spotting your reply.) -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.
