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;
From:   Dominick Grift <dominick.grift@defensec.nl>
To:     Chris PeBenito <pebenito@ieee.org>
Cc:     Topi Miettinen <toiwoton@gmail.com>,
        Russell Coker <russell@coker.com.au>,
        refpolicy <selinux-refpolicy@vger.kernel.org>
Subject: Re: [RFC] Purging dead modules
References: <352607e8-2de0-fc71-8403-15942d65c837@ieee.org>
        <ypjl35z7fqf0.fsf@defensec.nl> <3283555.42QHSe7XtN@liv>
        <d138760c-2993-2079-c847-d7465fae2f7a@gmail.com>
        <86e9b2ce-22ab-3de2-25f9-8e2f485e88c8@ieee.org>
Date:   Wed, 13 Jan 2021 14:33:50 +0100
In-Reply-To: <86e9b2ce-22ab-3de2-25f9-8e2f485e88c8@ieee.org> (Chris PeBenito's
        message of "Wed, 13 Jan 2021 08:21:49 -0500")
Message-ID: <ypjlpn29dkqp.fsf@defensec.nl>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Chris PeBenito <pebenito@ieee.org> 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?=C2=A0 I'm thinking something like 3-5 years.
>>>>
>>>> Agree
>>>
>>> I think we should drop them when the programs aren't in the latest DEVE=
LOPMENT
>>> 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 candidate=
s 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
kerneloops.org? AFAIK that site is offline so not sure how Debian still
expects kerneloops to still work?

--=20
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint =3D FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=3Dget&search=3D0xDA7E521F10F64098
Dominick Grift