Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4054694pxu; Wed, 9 Dec 2020 07:19:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJzMhcQ9eBt+mb83QF0zwardkLoOKoExb0XXF85SBa32KEhQwMXB97aGxOzaNuWI2mVlSwra X-Received: by 2002:a50:fc8b:: with SMTP id f11mr2476005edq.11.1607527142747; Wed, 09 Dec 2020 07:19:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607527142; cv=none; d=google.com; s=arc-20160816; b=nbLXIYJ0i7nHvjBYg+M/kuZGRAHQC24peE3q49DkU5bb7A7gQYx/lEXrf0zMTDL2Th R7ijUvPIEm8lpJvnHb7ml2uARPrWvzQpNT2QvbiddE/y4UyX7sBEf5VSDD3AiZwxGyuT Y/cKthl2dr8x6QEszPAtKgHVVps9YqpTvO3PaXB++GD/UdMkWGGJWdflTl2nMM62ftN9 wtX91NkS3vXdXkqu7Ac/Z0XvZYclkYS7Lid0Uyn5Z3YhBCO7rGgTFquR+8OF3sPw6tLc mqaaLbK6xN9mSOKeI2TS5/tkNNFgukSWbHbLpU5P7Fj6nsvenpIGRNmboLgtTXE+Nr2z YyMw== 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=uMptCtOL3c5LSJX7rXyT4lZ/JMXpbU4NFHngN61c4QU=; b=TXsxy5ZZyOlRpb5S66UqCavFqLMbTdHYlMe4+kvvEzeCJcjvdgw6hWNHATXKUcjO1r cTOVGc/NsLrg+Lea5s6vtWqCcsMqV49Fa2cUMYi0QwJ6/xoYOGCWlJgKYRwFxKHpIQjj TiGQARn641HmISiC/rYE/DjAD9atw3bkGzQzcbHf6kYaJf5Jxz7BNOgnAmXevfiyvhKG sM4deh/fb+6mQHOVURwQMUyhTFzYyN6/8O2I1WkeAr1mFzk0Ws9Y9y4Qie4PPIq+uf8m WbNh6odO3hnPIrGhDsJwFpU2PK/v8DzGRQ4Wc9o7MtrHIXGof4kS2Yqr4a1peojxFyYx FWkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@btinternet.com header.s=btmx201904 header.b="tFh/oUA3"; 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 r6si888794eji.697.2020.12.09.07.18.57; Wed, 09 Dec 2020 07:19:02 -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="tFh/oUA3"; 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 S1730870AbgLIOi1 (ORCPT + 16 others); Wed, 9 Dec 2020 09:38:27 -0500 Received: from mailomta22-sa.btinternet.com ([213.120.69.28]:42088 "EHLO sa-prd-fep-042.btinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725885AbgLIOi1 (ORCPT ); Wed, 9 Dec 2020 09:38:27 -0500 Received: from sa-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.38.5]) by sa-prd-fep-042.btinternet.com with ESMTP id <20201209143741.HHRZ15135.sa-prd-fep-042.btinternet.com@sa-prd-rgout-002.btmx-prd.synchronoss.net>; Wed, 9 Dec 2020 14:37:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btmx201904; t=1607524661; bh=uMptCtOL3c5LSJX7rXyT4lZ/JMXpbU4NFHngN61c4QU=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:MIME-Version; b=tFh/oUA3HmijHjwz/0GJaRcunAClV70oeMv6LlY5/+HqZz7sWqWU18LX9FXBVKcTjEtOwo+i5GyiXogW8XHPMjvFYVfxjIkBWt9tTTAzLrOrJd3aTjrb10XPYtHpE8WGX1svoXONt0DzGVrlOcGysoOz6EibjLlJVXkf0Ewsq1qXAWN0Z26Wnz6Bk6J144taV3xsP3XB9K8WadyYbx3BdUP62O7xO2+7GNDqta7LG05yOcs6RUqFPGULgDbeYlVvAKsvlfCM8r+kSxkZtFsq5ur1MeKutFaGT00D3JP441bMmAd2cfM3rHmjfEU1QxEmUPuMrTVnybuLSWGqbCJLPw== Authentication-Results: btinternet.com; auth=pass (LOGIN) smtp.auth=richard_c_haines@btinternet.com X-SNCR-Rigid: 5ED9AA6E1DF28E20 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: gggruggvucftvghtrhhoucdtuddrgedujedrudejkedgieejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkuffhvfffjghftggfggfgsehtkeertddtreejnecuhfhrohhmpeftihgthhgrrhguucfjrghinhgvshcuoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqeenucggtffrrghtthgvrhhnpedvieduhfdvjeetffejledvuedvhefgffelgffhfeelgeeijeejleekleejjefhvdenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedvudefrdduvddvrdduuddvrddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurdduleekngdpihhnvghtpedvudefrdduvddvrdduuddvrddupdhmrghilhhfrhhomhepoehrihgthhgrrhgupggtpghhrghinhgvshessghtihhnthgvrhhnvghtrdgtohhmqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeorghshhhishhhmhesmhhvihhsthgrrdgtohhmqedprhgtphhtthhopeeophgruhhlsehprghulhdqmhhoohhrvgdrtghomheqpdhrtghpthhtohepoehpvggsvghnihhtohesihgvvggvrdhorhhgqedprhgtphhtthhopeeoshgvlhhinhhugidqrhgvfhhpohhlihgthies 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 sa-prd-rgout-002.btmx-prd.synchronoss.net (5.8.340) (authenticated as richard_c_haines@btinternet.com) id 5ED9AA6E1DF28E20; Wed, 9 Dec 2020 14:37:41 +0000 Message-ID: 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 14:37:36 +0000 In-Reply-To: References: <858c9383f7c75e1e39bafaeab6388cd6af902c4f.camel@btinternet.com> <0b58a502b5036e8b92b274068fbea53ca915992e.camel@btinternet.com> <2806a33b-87ad-61b1-9143-5a24d770a180@ieee.org> <1b218c6ab1380164cd6c1c774fa4cd3db6d8eb8c.camel@btinternet.com> 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 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 > 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 > > > 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 > > > >