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