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;
Subject: Re: [RFC] Purging dead modules
To:     Dominick Grift <dominick.grift@defensec.nl>
Cc:     Topi Miettinen <toiwoton@gmail.com>,
        Russell Coker <russell@coker.com.au>,
        refpolicy <selinux-refpolicy@vger.kernel.org>
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>
 <ypjlpn29dkqp.fsf@defensec.nl>
From:   Chris PeBenito <pebenito@ieee.org>
Message-ID: <5b759422-3f04-1818-b043-65b420150439@ieee.org>
Date:   Tue, 19 Jan 2021 10:11:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <ypjlpn29dkqp.fsf@defensec.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

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

https://github.com/SELinuxProject/refpolicy/pull/335

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

-- 
Chris PeBenito