From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA392C4332E for ; Tue, 12 Jan 2021 00:27:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8968C22D58 for ; Tue, 12 Jan 2021 00:27:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404107AbhALA0F (ORCPT ); Mon, 11 Jan 2021 19:26:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404214AbhAKXxY (ORCPT ); Mon, 11 Jan 2021 18:53:24 -0500 Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94684C061786 for ; Mon, 11 Jan 2021 15:52:43 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id x23so858403lji.7 for ; Mon, 11 Jan 2021 15:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VjU6u8cIVsgmq21TsbWjqth++4HYD7QsXhBe2nUyACk=; b=Y15R/pANJwP58U5HmFzFLK2Ppp1iTlRYg2KDIbnqKPwlP5K6xAtTlkm1UtwRup5XuD sPFy5dCRsDVx2bC4zgsF3aMavqwICAOW9oPxUvUPbaMkaSv0QbykTPSG/JBM1B0odhDo KPwthG27/llp66DTHqf/IgBHd+zc0SVirTeC9t+Q3oHWNvMT+Z1PUn97ziyjBi4g5spU UJfifzV5huk/5TtMjC5ADwdB8io6ZHBjd0u3ISwkPCgYvUpa2XwpLEybHRYT3b+WDA2X yJLmKZkWErPdNzN8kNSk7xYhnPxSmC6V61QXBAvxQwCp2qqQFX9jCEiUQ4QvSBXhDiGi UISg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VjU6u8cIVsgmq21TsbWjqth++4HYD7QsXhBe2nUyACk=; b=GOpp0QPTKlk7yX/MHWMwk1DlgkYPYQhqycQGLpEBGGmdvLJUboqrlBmtkwkzVSgi9v l13SbeVX0LfZ2Cw5169k4Le5cnb+1g8xO0DgTBSltu5LMbxB3Kon5t8ofWrl69/LO39K OosZZpXsaucSrvo6ocDrH5CrLcLOuuKpynO82kqoMY9RC2k9HNWvqMIOHHX1DbAiXPTt 4At93O6foSXA7fZFRaZ2lLEByL0RTiDhGIn+xDpzYu6gdNVmE3F6CvcCjt6IWPLHmCUW 6AV4br3RmYxZwTwu8MkIZZe4G2fqu1itaKM7cLnPfQxrtEpaV/gFPoxJCfK61Y5wDifK XQVg== X-Gm-Message-State: AOAM533k8covRZtSG/hjFd80iRt59FoPtjqLE/52zUK4HHNYqPJttcyD Z2iKtHJTLMKKrJf/7qlRz8QgGsgEFZH08w== X-Google-Smtp-Source: ABdhPJwmDW1BIIZh+w+g5HNgHshNp1RRt7EfArTaj3BzOK/MdjiHMR8mm2VYKLSV/r/v9e3QdKkt7A== X-Received: by 2002:a2e:978e:: with SMTP id y14mr777758lji.501.1610409161828; Mon, 11 Jan 2021 15:52:41 -0800 (PST) Received: from [192.168.1.33] (88-114-222-21.elisa-laajakaista.fi. [88.114.222.21]) by smtp.gmail.com with ESMTPSA id g15sm160007lfd.42.2021.01.11.15.52.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jan 2021 15:52:41 -0800 (PST) Subject: Re: [RFC] Purging dead modules To: Russell Coker , Dominick Grift Cc: Chris PeBenito , refpolicy References: <352607e8-2de0-fc71-8403-15942d65c837@ieee.org> <3283555.42QHSe7XtN@liv> From: Topi Miettinen Message-ID: 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 List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org 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