SELinux-Refpolicy Archive on
 help / color / Atom feed
From: Chris PeBenito <>
To: Dominick Grift <>
Cc: Topi Miettinen <>,
	Russell Coker <>,
	refpolicy <>
Subject: Re: [RFC] Purging dead modules
Date: Tue, 19 Jan 2021 10:11:08 -0500
Message-ID: <> (raw)
In-Reply-To: <>

On 1/13/21 8:33 AM, Dominick Grift wrote:
> 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
> removal.
> 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?

I've created a pull request on GitHub to remove modules:

I will be merging it at the end of the week unless there are any further objections.

Chris PeBenito

      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
2021-01-19 15:11           ` Chris PeBenito [this message]

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