SELinux-Refpolicy Archive on
 help / color / Atom feed
From: Dominick Grift <>
To: Chris PeBenito <>
Cc: Topi Miettinen <>,
	Russell Coker <>,
	refpolicy <>
Subject: Re: [RFC] Purging dead modules
Date: Wed, 13 Jan 2021 14:33:50 +0100
Message-ID: <> (raw)
In-Reply-To: <> (Chris PeBenito's message of "Wed, 13 Jan 2021 08:21:49 -0500")

Chris PeBenito <> writes:

> On 1/11/21 6:52 PM, Topi Miettinen wrote:
>> On 11.1.2021 17.48, Russell Coker wrote:
>>> On Tuesday, 12 January 2021 2:23:47 AM AEDT Dominick Grift wrote:
>>>>> I'm looking to remove modules for dead programs, such as hal and
>>>>> consolekit. The question is how long to keep modules for dead
>>>>> programs?  I'm thinking something like 3-5 years.
>>>> Agree
>>> I think we should drop them when the programs aren't in the latest DEVELOPMENT
>>> versions of Fedora, Debian, or any other distribution that supports SE Linux.
>> I think this could be automated. If no file contexts in a module
>> match any files in a list of all files of all packages of the
>> selected distros concatenated, the module is probably obsolete
>> (which could be also verified by looking at old releases) or it's
>> for 3rd party software (never found in earlier distro releases). I
>> tried to do this locally to disable unused modules, but it took way
>> too long time with shell scripts. I suppose with a database or other
>> proper tools it would be trivial.
> This is a good idea, but may be a problem for the Gentoo guys.
> I'd probably simplify it to only looking at labels for executables,
> since a package's manifest might not hit all of the data files'
> entries.

Not sure if it is worth the trouble to automate this. The list of candidates I came up with
were also verified by just using `dnf whatprovides /usr/bin/app` to see
if it returns. Most modules though are still relevant and it's is pretty
obvious that they are still relevant. So I would argue that spending
half an hour perusing the refpolicy and looking for candidates, then
verifying is enough to atleast identify the most obvious candidates for

In reply to Russell Coker and kerneloops: Does kerneloops not depend on AFAIK that site is offline so not sure how Debian still
expects kerneloops to still work?

gpg --locate-keys
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 14:48 Chris PeBenito
2021-01-11 15:23 ` Dominick Grift
2021-01-11 15:48   ` Russell Coker
2021-01-11 23:52     ` Topi Miettinen
2021-01-13 13:21       ` Chris PeBenito
2021-01-13 13:33         ` Dominick Grift [this message]
2021-01-19 15:11           ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

SELinux-Refpolicy Archive on

Archives are clonable:
	git clone --mirror selinux-refpolicy/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux-refpolicy selinux-refpolicy/ \
	public-inbox-index selinux-refpolicy

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone