SELinux-Refpolicy Archive on lore.kernel.org
 help / color / Atom feed
From: Chris PeBenito <pebenito@ieee.org>
To: Topi Miettinen <toiwoton@gmail.com>,
	Russell Coker <russell@coker.com.au>,
	Dominick Grift <dominick.grift@defensec.nl>
Cc: refpolicy <selinux-refpolicy@vger.kernel.org>
Subject: Re: [RFC] Purging dead modules
Date: Wed, 13 Jan 2021 08:21:49 -0500
Message-ID: <86e9b2ce-22ab-3de2-25f9-8e2f485e88c8@ieee.org> (raw)
In-Reply-To: <d138760c-2993-2079-c847-d7465fae2f7a@gmail.com>

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.

-- 
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 [this message]
2021-01-13 13:33         ` Dominick Grift
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=86e9b2ce-22ab-3de2-25f9-8e2f485e88c8@ieee.org \
    --to=pebenito@ieee.org \
    --cc=dominick.grift@defensec.nl \
    --cc=russell@coker.com.au \
    --cc=selinux-refpolicy@vger.kernel.org \
    --cc=toiwoton@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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

SELinux-Refpolicy Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux-refpolicy/0 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/ https://lore.kernel.org/selinux-refpolicy \
		selinux-refpolicy@vger.kernel.org
	public-inbox-index selinux-refpolicy

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux-refpolicy


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git