Re: [PATCH refpolicy] kernel: remove some unused initial SID contexts

On Monday, November 3, 2025 9:23:11 AM Eastern Standard Time Stephen Smalley 
wrote:
> On Mon, Nov 3, 2025 at 8:33 AM Stephen Smalley
> 
> <[email protected]> wrote:
> > On Sun, Nov 2, 2025 at 8:07 PM Russell Coker <[email protected]> wrote:
> > > On Sunday, 2 November 2025 12:28:21 AEDT Russell Coker wrote:
> > > > The above is what apparently used to be the policy so it looks like
> > > > node_t
> > > > is being changed to sysctl_t.
> > > 
> > > allow sshd_t sysctl_t:tcp_socket node_bind;
> > > 
> > > I also tried rebooting a VM running that policy (previously I had loaded
> > > it on a running system) and got the same result with TCP as an
> > > additional issue.
> > > 
> > > Also I tried kernel 6.12.48+deb13-amd64 (the latest kernel for
> > > Debian/Trixie the latest stable release).
> > 
> > My apologies, please revert. Due to differences between Fedora selinux
> > policy and refpolicy, I did NOT test loading of the patched refpolicy
> > itself but instead manually patched the base module (i.e. semodule -cE
> > base, edit base.cil to remove the CIL sidcontext statements for the
> > "UNKNOWN*" sids, then semodule -i base.cil) and tested that behavior,
> > which worked correctly. Looking at the generated base module from the
> > patched refpolicy, it is removed not only the sidcontext statements
> > but also the sid declarations and omitting them from the sidorder
> > statement, thereby perturbing the SID assignments. Not yet sure where
> > this is happening in refpolicy build.
> 
> Ok, if I semodule_unpackage base.pp base.mod and dismod base.mod, then
> select 0 (Display initial SIDs), I see the initial SIDs with the
> expected SID values and gaps for those that lack a context. But if I
> run checkmodule -C -o base.cil base.mod, the resulting CIL file omits
> any SID declarations that lack a context and therefore ends up
> renumbering them when they are compiled into a kernel policy.

I reverted the patch. We can reapply it once a fix for this is in a release 
checkpolicy.


-- 
Chris PeBenito