selinux-refpolicy.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Haines <richard_c_haines@btinternet.com>
To: Ashish Mishra <ashishm@mvista.com>, Chris PeBenito <pebenito@ieee.org>
Cc: selinux-refpolicy@vger.kernel.org, Paul Moore <paul@paul-moore.com>
Subject: Re: How is policy.31 created from modules under /usr/share/selinux
Date: Wed, 09 Dec 2020 14:37:36 +0000	[thread overview]
Message-ID: <a926d6a67a7c4013983c716c8a797b9194e2f81a.camel@btinternet.com> (raw)
In-Reply-To: <CAP2OjciFL+zWnyU8VVp1qbD+1mguR8bB9+XPNSR2gbt6avi93g@mail.gmail.com>

On Wed, 2020-12-09 at 19:42 +0530, Ashish Mishra wrote:
> 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?

I've only had a quick look at code and I could see two ways to fix:
1) Modify the Rules.modular part of the make file to move or copy the
policy and file contexts set of files over to $DESTDIR.
2) Modify semodule/semanage to handle $DESTDIR. I think this would be
more difficult to fix as lots go on here.

Maybe Chris could comment.

> 
> 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
> > 
> > 



  reply	other threads:[~2020-12-09 14:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-05 19:19 How is policy.31 created from modules under /usr/share/selinux Ashish Mishra
2020-12-06 15:29 ` Richard Haines
2020-12-06 16:30   ` Ashish Mishra
2020-12-06 17:15     ` Richard Haines
2020-12-07  1:21       ` Ashish Mishra
2020-12-07 12:39         ` Richard Haines
2020-12-07 13:26           ` Ashish Mishra
2020-12-08 15:36             ` Chris PeBenito
2020-12-08 15:58               ` Ashish Mishra
2020-12-09  9:53                 ` Richard Haines
2020-12-09 14:12                   ` Ashish Mishra
2020-12-09 14:37                     ` Richard Haines [this message]
2020-12-09 15:07                       ` Steve Lawrence
2020-12-09 16:13                         ` Richard Haines
2020-12-09 22:02                           ` Chris PeBenito
2020-12-13 17:06                             ` Ashish Mishra
2020-12-14 15:16                               ` Chris PeBenito

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=a926d6a67a7c4013983c716c8a797b9194e2f81a.camel@btinternet.com \
    --to=richard_c_haines@btinternet.com \
    --cc=ashishm@mvista.com \
    --cc=paul@paul-moore.com \
    --cc=pebenito@ieee.org \
    --cc=selinux-refpolicy@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).