Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3845382pxu; Wed, 9 Dec 2020 01:57:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJzIqZ84GFutp1tjAV8pPgZyOZm/i8OTFFoBAcGgAvu+w8WDT35ZEQTR/4dNw5Cfh1fMzayD X-Received: by 2002:a17:906:ec9:: with SMTP id u9mr1365071eji.400.1607507861717; Wed, 09 Dec 2020 01:57:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607507861; cv=none; d=google.com; s=arc-20160816; b=yhX+deymlxKg6slpjd3KEpnUSCRUwIvZJtiKOpKJAdDqTwFguiYdH8PV18qKzVuExP tCEvBI5G53+z2qbDA3Ctay2Hljc9ushs4BgVIv16ifAQmYRlTc+a8wLxNa072ErWwR1x U/29phPPiZefHOUkk2cdcYA+ImO4e5zdVMd6FTkLD+QBWPxSQeBIAT2yFRcZTqcn3L/M UxVGYeF/UA97S0xGo/eAcNCoSxPiN+Dczam+BWWw2SkyJIeU2bCIdbQ41xoeaU9UlWGj /PTuNw5xxKJxOJYXFyP6iKuwFjy02LAZIYlaZqY7qoBgCrBjbVSP5PF3GKXlyrK2tXvg Hx4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=aGnuCfJf7Yw0Zx8NVN7GmmLKeOFHhdojd845tCpBzno=; b=v+8mzNCiOaIhHSHollA99vNcS8GKpQ3WVdby24Kdo9kguGwrRROSduQ8aQaDTVv8GC Yxmp2yHKPTNvlntsbkQoJwn/QbZHtBAMg6R8TC9qGV3O/utyR4KJ3bJo8pq6dRCmR4+9 1frhzI/bSld7Hbtq5bBImD7UscuHXo37nbBNiHNanclFsdc9LA8PX/7MZC5jsnwHMoyF gVB/Zh9ojtzZyLaBo7B+5tRJCsa23CELXGdxpzdbPJF4MFe1oKnCAtWXVIxgwjX8GuZG 2zsZNaOFozBSZvl5fm6O4Rvw6qbjwxcKt3QVSqvSI9Aw0Pz+0VEXoUUKc7ek+5LpbxiL BmQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@btinternet.com header.s=btmx201904 header.b="BXDz6w/J"; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=btinternet.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b22si576430edj.13.2020.12.09.01.57.34; Wed, 09 Dec 2020 01:57:41 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@btinternet.com header.s=btmx201904 header.b="BXDz6w/J"; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=btinternet.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728613AbgLIJyI (ORCPT + 16 others); Wed, 9 Dec 2020 04:54:08 -0500 Received: from mailomta2-re.btinternet.com ([213.120.69.95]:16047 "EHLO re-prd-fep-046.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728504AbgLIJyI (ORCPT ); Wed, 9 Dec 2020 04:54:08 -0500 Received: from re-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.54.8]) by re-prd-fep-046.btinternet.com with ESMTP id <20201209095325.CUZI13971.re-prd-fep-046.btinternet.com@re-prd-rgout-005.btmx-prd.synchronoss.net>; Wed, 9 Dec 2020 09:53:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1607507605; bh=aGnuCfJf7Yw0Zx8NVN7GmmLKeOFHhdojd845tCpBzno=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:MIME-Version; b=BXDz6w/JtgxWWRVxOGr8Ajh/K2critDf0IIp67R268qeK2oeeV1TYZlMkjVEx3u7dryAEH/f7ZXHEZsY7LnBe4el8yUjUerT+CJjz4BQpKfwB0KtdUkk/1/NURpMgFmg9D/PP7519otrOxn1MxFPv+b3lUzXKx3ytbZ1BMQHtF5OmWKpxngjM+3CRpcu7AK4yw0Mx56IAS+bGUMGsuDwCQB546hMffTgksNfxzb75wDsoFSg+opJ6Ds+yB7VKpuzbRbSK83PojALt0poSGb4YSNKFEzWSkAjNGtOxD5IESYepjU5Xppkpn7KyfWjPiJupkIzSMUQd6wHsItQ1UlcoA== Authentication-Results: btinternet.com; auth=pass (LOGIN) smtp.auth=richard_c_haines@btinternet.com X-SNCR-Rigid: 5ED9C74D1DC2188A X-Originating-IP: [213.122.112.1] X-OWM-Source-IP: 213.122.112.1 (GB) X-OWM-Env-Sender: richard_c_haines@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedrudejkedguddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkuffhvfffjghftggfggfgsehtkeertddtreejnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpedvieduhfdvjeetffejledvuedvhefgffelgffhfeelgeeijeejleekleejjefhvdenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedvudefrdduvddvrdduuddvrddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurdduleekngdpihhnvghtpedvudefrdduvddvrdduuddvrddupdhmrghilhhfrhhomhepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeorghshhhishhhmhesmhhvihhsthgrrdgtohhmqedprhgtphhtthhopeeophgruhhlsehprghulhdqmhhoohhrvgdrtghomheqpdhrtghpthhtohepoehpvggsvghnihhtohesihgvvggvrdhorhhgqedprhgtphhtthhopeeoshgvlhhinhhugidqrhgvfhhpohhlihgthies vhhgvghrrdhkvghrnhgvlhdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-SNCR-hdrdom: btinternet.com Received: from [192.168.1.198] (213.122.112.1) by re-prd-rgout-005.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9C74D1DC2188A; Wed, 9 Dec 2020 09:53:25 +0000 Message-ID: <1b218c6ab1380164cd6c1c774fa4cd3db6d8eb8c.camel@btinternet.com> Subject: Re: How is policy.31 created from modules under /usr/share/selinux From: Richard Haines To: Ashish Mishra , Chris PeBenito Cc: selinux-refpolicy@vger.kernel.org, Paul Moore Date: Wed, 09 Dec 2020 09:53:18 +0000 In-Reply-To: References: <858c9383f7c75e1e39bafaeab6388cd6af902c4f.camel@btinternet.com> <0b58a502b5036e8b92b274068fbea53ca915992e.camel@btinternet.com> <2806a33b-87ad-61b1-9143-5a24d770a180@ieee.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.1 (3.38.1-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org 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 > 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