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

José Pekkarinen jose.pekkarinen at unikie.com
Mon Sep 20 13:39:13 UTC 2021


On Mon, Sep 20, 2021 at 4:21 PM Antoine Tenart <atenart at kernel.org> wrote:

> Quoting José Pekkarinen (2021-09-20 11:44:42)
> >    On Mon, Sep 20, 2021 at 12:30 PM Antoine Tenart <[1]
> atenart at kernel.org>
> >    wrote:
> >
> >      Quoting José Pekkarinen (2021-09-20 08:01:27)
> >      >
> >      >    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
> >
> >      This should work. Did you check the content of your module show up
> after
> >      applying this patch?
> >
> >    Yes, after the patch I can see the module copied in the folder:
> >    build/refpolicy-2.20200818$ ls policy/modules/buildroot/
> >    base.fc  base.if  base.te  metadata.xml  secure.fc  secure.if
>  secure.te
> >
> >      And:
> >
> >    /build/refpolicy-2.20200818$ grep secure policy/modules.conf
> >    # Module: secure
> >    secure = base
> >    # Small and secure DNS daemon.
>
> I'm missing something here. I did the test and using the module and
> configuration snippets you provided (replacing $OUTPUT_DIR/selinux with
> something else; and adding a <summary> to secure.if[1]). It worked. The
> 'secure' module was found and enabled.
>
> The logic is the following in Buildroot for extra modules:
>
> 1. The modules are rsynced in policy/modules/buildrood/.
> 2. If not already there, a metadata.xml file is added.
> 3. The refpolicy build system is used[2] to generate modules.conf using
>    all modules matching 'policy/modules/*/*.te'.
> 4. All modules in modules.conf are disabled and then only the ones in
>    REFPOLICY_MODULES are enabled.
>
> It looks like more of a refpolicy/module issue than a Buildroot one:
> steps 1 and 2 seem to work, but not step 3. If you retrieve the
> refpolicy project outside of Builroot and mimic the above steps, are
> your modules listed in modules.conf? If not that might be a good
> starting point. I don't have a better idea for now...
>

Hi,

I did, and this is how modules.conf looks like when

it comes to the section of my module:

[...]
# Module: xscreensaver
#
# Modular screen saver and locker for X11.
#
xscreensaver = module

# Layer: buildroot
# Module: secure
#
# Layer: kernel
# Module: storage
[...]

Now, reading the INSTALL file, it says the following:

If you do not have a modules.conf, one can be generated:

   make conf

This will create a *default modules.conf*.

This default makes me think it implies you'd need to

activate your own modules if they are there, and why I believe
buildroot would require that extra logic. refpolicy project may
stand for letting users add their own, but not taking part on
it theirselves.

Best regards.

José.



>
> Antoine
>
> [1] Which I guess is not your issue as otherwise the configuration step
>     fails and the build stops.
> [2] `make -j1 bare conf`
>


-- 

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


More information about the buildroot mailing list