All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antoine Tenart <atenart@kernel.org>
To: José Pekkarinen <jose.pekkarinen@unikie.com>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH] package/refpolicy: Treat all modules as custom
Date: Wed, 22 Sep 2021 16:23:40 +0200	[thread overview]
Message-ID: <163232062091.4283.13096713479109144471@kwain> (raw)
In-Reply-To: <CAJPV9Mp-6PBtw5G2YDORJ_5cqypjtrc2CR3cMrzfe36RpUW2oQ@mail.gmail.com>

Quoting José Pekkarinen (2021-09-22 16:00:19)
>    On Tue, Sep 21, 2021 at 4:42 PM Antoine Tenart <[1]atenart@kernel.org>
>    wrote:
>      Quoting José Pekkarinen (2021-09-21 15:32:32)
>      > On Tue, Sep 21, 2021 at 10:12 AM Antoine Tenart
>      <[1][2]atenart@kernel.org>
>      > wrote:
>      >
>      > I tested today to build the system with buildroot 2021.05.2(without
>      > the patch) and it reproduces exactly the same behaviour,
>      > policy/modules.conf doesn't receive the line to activate the secure
>      > module, and if I search in policy.conf or policy.32 through sesearch I
>      > find no sign of the policies defined in the module.  I'll attempt the
>      > upgrade to 2021.08, but that will require a bit more time.
> 
>      Alternatively you can just test with newer refpolicy versions, outside
>      of Buildroot and look at the generated modules.conf. This will give the
>      same information and should be easier to do. (My feeling is this won't
>      change and we'll have to dive into the refpolicy logic for enabling
>      modules when running 'make conf').
> 
>    The config generator requires a summary line in the module.if file
>    to be added in policy/modules.conf, otherwise it doesn't process
>    any further.  It seems to be something tricky to address, in your
>    end developing a check the summary is in place doesn't make sense,
>    in their end, not using that hook to learn the modules from the xml
>    make be also complicated.

I agree, having a check for the summary would be outside of Buildroot's
scope. It's linked to how SELinux modules should be written.

However I'm surprised as my understanding was the summary was required
for the refpolicy configuration step to succeed (I did use a summary
for all my tests because of this). When removing a summary from a module
I always get the following error, and the Buildroot build stops.

  doc/policy.xml:8376: element module: validity error : Element module content does not follow the DTD, expecting (summary , desc? , required? , (interface | template)* , (bool | tunable)*), got ()
  Document doc/policy.xml does not validate against doc/policy.dtd

Do you have an idea what made your build to succeed even though you did
not have a summary in your module?

Antoine
_______________________________________________
buildroot mailing list
buildroot@lists.buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2021-09-22 14:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30 11:45 [Buildroot] [PATCH] package/refpolicy: Treat all modules as custom José Pekkarinen
2021-08-30 21:14 ` Thomas Petazzoni
2021-09-17 17:22 ` Antoine Tenart
2021-09-20  6:01   ` José Pekkarinen
2021-09-20  9:30     ` Antoine Tenart
2021-09-20  9:44       ` José Pekkarinen
2021-09-20 13:21         ` Antoine Tenart
2021-09-20 13:39           ` José Pekkarinen
2021-09-20 13:52             ` Antoine Tenart
2021-09-21  6:29               ` José Pekkarinen
2021-09-21  7:12                 ` Antoine Tenart
2021-09-21 13:32                   ` José Pekkarinen
2021-09-21 13:42                     ` Antoine Tenart
2021-09-22 14:00                       ` José Pekkarinen
2021-09-22 14:23                         ` Antoine Tenart [this message]
2021-09-23  6:26                           ` José Pekkarinen
2021-09-23  7:59                             ` Antoine Tenart
2021-09-23  8:33                               ` Antoine Tenart
2021-09-23  8:47                                 ` José Pekkarinen
2021-09-23  9:08                               ` José Pekkarinen
2021-09-23  9:17                                 ` Antoine Tenart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=163232062091.4283.13096713479109144471@kwain \
    --to=atenart@kernel.org \
    --cc=buildroot@buildroot.org \
    --cc=jose.pekkarinen@unikie.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.