Re: [RFC] Purging dead modules

Chris PeBenito <[email protected]>
Newsgroups org.kernel.vger.selinux-refpolicy
Message-ID <[email protected]>
On 1/13/21 8:33 AM, Dominick Grift wrote:
> Chris PeBenito <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.