Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAP2OjcjCFYiyMfqa=X__X6g0U0143U5Fd-xGaKJgGNabFUpr7w@mail.gmail.com>
 <858c9383f7c75e1e39bafaeab6388cd6af902c4f.camel@btinternet.com>
 <CAP2OjciTWXRsYWw9VtOJGUOGj9B35HMXBHF94O6Qc=csg5=Spw@mail.gmail.com>
 <e82841a8b652f4b4b697ba1e417fdac56f443adb.camel@btinternet.com>
 <CAP2OjchJjMo8zMVvHk-_esu-53E0=367yV8cuZtwQwubi7+q=Q@mail.gmail.com>
 <0b58a502b5036e8b92b274068fbea53ca915992e.camel@btinternet.com>
 <CAP2Ojcg7DgQsEHJP3TZj=Q9NjZjqb3ugw+D2UYC4qmqt-PcZWw@mail.gmail.com>
 <2806a33b-87ad-61b1-9143-5a24d770a180@ieee.org> <CAP2OjcgtcoUmBQZJSzz2DYQ-g23=RrSXT-uefCROUi3y_tU=tg@mail.gmail.com>
 <1b218c6ab1380164cd6c1c774fa4cd3db6d8eb8c.camel@btinternet.com>
In-Reply-To: <1b218c6ab1380164cd6c1c774fa4cd3db6d8eb8c.camel@btinternet.com>
From:   Ashish Mishra <ashishm@mvista.com>
Date:   Wed, 9 Dec 2020 19:42:01 +0530
Message-ID: <CAP2OjciFL+zWnyU8VVp1qbD+1mguR8bB9+XPNSR2gbt6avi93g@mail.gmail.com>
Subject: Re: How is policy.31 created from modules under /usr/share/selinux
To:     Richard Haines <richard_c_haines@btinternet.com>
Cc:     Chris PeBenito <pebenito@ieee.org>,
        selinux-refpolicy@vger.kernel.org, Paul Moore <paul@paul-moore.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Richard ,

Will check with the monolithic policy to check the behavior of the
semodule as you suggested.

Is there any similar approach / workaround for modular one?

Thanks for pointers again.

Ashish


On Wed, Dec 9, 2020 at 3:23 PM Richard Haines
<richard_c_haines@btinternet.com> wrote:
>
> On Tue, 2020-12-08 at 21:28 +0530, Ashish Mishra wrote:
> > Hi Chris ,
> >
> > Continuing on the inputs Richard shared , I was able to zero down to
> > the problem.
> > To recreate , step  can be directly tested by command mentioned in
> > step-c
> >
> > a) I am having custom-rootfs under which I am trying to get the
> > refpolicy installed.
> >
> > b) By using make load DESTDIR=/tmp/custom-rootfs , the setup reaches
> > to state where
> >      # semodule -s refpolicy -i NAME-OF-MODULE is triggered for every
> > module under /tmp/custom-rootfs/usr/share/selinux/refpolicy
> >      ==> This semodule behavior is causing the problem.
> >
> > c) By default semodule install the file under /etc/selinux of HOST
> > system rather than /tmp/custom-rootfs/etc/selinux
> >     This behaviour can be recreated / verified by :
> >     # semodule  -s selinux-store-name -i sample.pp
> >     This instruction creates an entry of selinux-store-name and
> > creates policy.32 file there .
> >      ==> Instead , here i wanted the file to be created under
> > /tmp/custom-rootfs/etc/selinux & not /etc/selinux
> >
> > d) Currently trying to look at the file from where this instruction
> > is
> > executed & then check if
> >     somehow semodule can be made to use /tmp/custom-
> > rootfs/etc/selinux
> > over default /etc/selinux
> >
> > Thanks for sharing the info w.r.t your use case , will look at them .
> > They can help me to understand the process in a better way.
> >
> > Please feel free to revert if any further details are required or if
> > i
> > am missing any aspect .
>
> I've been AWOL for a few days so just picking up on this query. I can
> now see the problem as described. If you generate a monolithic policy
> (MONOLITHIC=y) using sequence below it all works. However if you build
> a modular policy (MONOLITHIC=n), then semodule will install the final
> binary policy in /etc/selinux/refpolicy/policy regardless of DESTDIR.
>
> I guess semodule should obey orders??
>
> export DESTDIR=/tmp/custom-embedded-rootfs
> mkdir refpol
> cd refpol
> git clone https://github.com/SELinuxProject/refpolicy.git
> Edit build.conf file to requirements (e.g. NAME = refpolicy etc.)
> make install-src
> cd /tmp/custom-embedded-rootfs/etc/selinux/refpolicy/src/policy
> make conf
> make load
>
>
>
>
> >
> > Thanks  ,
> > Ashish
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Dec 8, 2020 at 9:06 PM Chris PeBenito <pebenito@ieee.org>
> > wrote:
> > >
> > > (SELinux main mail list to BCC since this is a refpolicy question.)
> > >
> > > On 12/7/20 8:26 AM, Ashish Mishra wrote:
> > > >   4)  Further debugging I can confirm that the final binary
> > > > (policy.31)
> > > > seems to be
> > > >        using HARD-CODDED location of /etc/selinux instead of what
> > > > is
> > > > being passed as DESTDIR.
> > > >       The policy.31 is created not at custom-embedded-rootfs
> > > > location.
> > > >
> > > >        Due to this :
> > > >          - policy.31 is created in
> > > > /etc/selinux/refpolicy/policy/policy.31
> > > >            instead of what i was expecting at
> > > > /tmp/custom-embedded-
> > > > rootfs/etc/selinux/refpolicy/policy/policy.31
> > > >            as DESTDIR=${ROOT}  and i do get *.pp at the expected
> > > > location of /tmp/custom-embedded-
> > > > rootfs/etc/selinux/refpolicy/src/policy
> > > >                   ${MAKE} -C
> > > > ${ROOT}/etc/selinux/${PKG}/src/policy load
> > > > DESTDIR=${ROOT}
> > >
> > >
> > > I can't reproduce your issue.  I use monolithic policy regularly in
> > > the way
> > > you're using it.
> > >
> > > Here's the Makefile variables:
> > >
> > >  From Makefile:
> > >    topdir := $(DESTDIR)/etc/selinux
> > >    installdir := $(topdir)/$(strip $(NAME))
> > >    policypath := $(installdir)/policy
> > >
> > >  From Rules.monolithic:
> > >    loadpath = $(policypath)/$(notdir $(polver))
> > >
> > > $(notdir $(polver)) is "policy.31" and NAME is what you have in
> > > build.conf, e.g.
> > > "refopolicy".
> > >
> > >
> > > Then the install target for monolithic looks like this (with
> > > "echo"s removed):
> > >
> > > $(loadpath): $(policy_conf)
> > >          @$(INSTALL) -d -m 0755 $(@D)
> > >          $(verbose) $(CHECKPOLICY) -U $(UNK_PERMS)  $^ -o $@
> > >
> > > --
> > > Chris PeBenito
>
>