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:     Russell Coker <russell@coker.com.au>,
        Dominick Grift <dominick.grift@defensec.nl>
Cc:     Chris PeBenito <pebenito@ieee.org>,
        refpolicy <selinux-refpolicy@vger.kernel.org>
References: <352607e8-2de0-fc71-8403-15942d65c837@ieee.org>
 <ypjl35z7fqf0.fsf@defensec.nl> <3283555.42QHSe7XtN@liv>
From:   Topi Miettinen <toiwoton@gmail.com>
Message-ID: <d138760c-2993-2079-c847-d7465fae2f7a@gmail.com>
Date:   Tue, 12 Jan 2021 01:52:39 +0200
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: <3283555.42QHSe7XtN@liv>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

> The new policy will only be used by new versions of those distributions.
> Running a newer version of policy on an older version will not provide any
> benefits and in some cases won't work properly.  People should NOT expect the
> Git refpolicy to work well on Debian/Buster, if they try it they shouldn't
> expect much help from me.  While I have a general aim that you should be able
> to upgrade kernel, SE Linux policy (and things that get dragged in with it
> like libc), and applications separately this isn't a guarantee.  If Debian/
> Unstable doesn't include a daemon then I have no interest in supporting that
> daemon with SE Linux policy in Debian/Unstable.  People can migrate their
> configuration to the replacement daemon as part of the process of upgrading SE
> Linux policy.

As a Debian user, I've actually found that upstream refpolicy works 
somewhat better (as in less need to fix things by adding local rules) 
for unstable and especially when I'm building software myself directly 
from upstream, which may need the latest policy to work. Of course 
developing the reference policy is also easier when using upstream master.

-Topi