[Buildroot] [PATCH] package/refpolicy: Treat all modules as custom

José Pekkarinen jose.pekkarinen at unikie.com
Mon Sep 20 06:01:27 UTC 2021


On Fri, Sep 17, 2021 at 8:22 PM Antoine Tenart <atenart at kernel.org> wrote:

> Hello José,
>
> Quoting José Pekkarinen (2021-08-30 13:45:31)
> > The current processing of the modules doesn't work for
> > custom made policies appended through the extra dir mechanism,
> > since sed won't find a match for custom modules, it will
> > continue without triggering and error. This patch removes
> > all the modules from modules.conf and add them one by
> > one using REFPOLICY_MODULES values.
>
> I'm failing to see what particular setup the change below would fix.
>
> Could you elaborate on the above? Maybe including configuration
> snippets and example of such a module (with the file tree, starting from
> REFPOLICY_EXTRA_MODULES_DIRS).
>
> Thanks!
> Antoine
>

Absolutely, in the security section of my .config we can read the

following:

BR2_PACKAGE_POLICYCOREUTILS=y
BR2_PACKAGE_REFPOLICY=y
BR2_REFPOLICY_EXTRA_MODULES_DIRS="$OUTPUT_DIR/selinux"
BR2_PACKAGE_REFPOLICY_POLICY_STATE_ENFORCING=y

In $OUTPUT_DIR/selinux I have the following files:

$ ls
secure.fc  secure.if  secure.te
$ cat secure.fc
$ cat secure.if
$  cat secure.te
policy_module(secure, 1.0);

#============= bin_t ==============
allow bin_t user_home_t:dir { getattr open read };
allow bin_t user_home_t:file { getattr open read };

#============= chkpwd_t ==============
allow chkpwd_t device_t:chr_file { read write };
allow chkpwd_t proc_t:filesystem getattr;
allow chkpwd_t sysctl_kernel_t:dir search;
allow chkpwd_t sysctl_kernel_t:file { open read };
allow chkpwd_t tmpfs_t:dir search;
[...]

The problem arises because the secure module is not

known to refpolicy, and at the time of building, policy/modules.conf
requires a line that the recipe sed, but no reference of secure
module is in the file beforehand. Since then, the sed modifies
nothing and the policies I have in the file doesn't turn up if
I execute sesearch on the policy file that in my case is policy.32
since I'm working with buildroot 2021.02.x. Please let me know
if there is any further question.

Best regards.

José.


> diff --git a/package/refpolicy/refpolicy.mk b/package/refpolicy/
> refpolicy.mk
> > index 0194708b37..1c0a2c3385 100644
> > --- a/package/refpolicy/refpolicy.mk
> > +++ b/package/refpolicy/refpolicy.mk
> > @@ -85,9 +85,9 @@ endef
> >  # In the context of a monolithic policy enabling a piece of the policy
> as
> >  # 'base' or 'module' is equivalent, so we enable them as 'base'.
> >  define REFPOLICY_CONFIGURE_MODULES
> > -       $(SED) "s/ = module/ = no/g" $(@D)/policy/modules.conf
> > +       $(SED) "/ = module/d" $(@D)/policy/modules.conf
> >         $(foreach m,$(sort $(REFPOLICY_MODULES)),
> > -               $(SED) "/^$(m) =/c\$(m) = base" $(@D)/policy/modules.conf
> > +               $(SED) "/^# Module: $(m)/a\$(m) = base"
> $(@D)/policy/modules.conf
> >         )
> >  endef
> >
> > --
> > 2.25.1
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 

José.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildroot.org/pipermail/buildroot/attachments/20210920/6226ef15/attachment.html>


More information about the buildroot mailing list