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=-14.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 C8054C433E9 for ; Sun, 21 Feb 2021 14:47:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 95C8264E86 for ; Sun, 21 Feb 2021 14:47:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230077AbhBUOrQ (ORCPT ); Sun, 21 Feb 2021 09:47:16 -0500 Received: from conssluserg-02.nifty.com ([210.131.2.81]:64427 "EHLO conssluserg-02.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230045AbhBUOrO (ORCPT ); Sun, 21 Feb 2021 09:47:14 -0500 Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (authenticated) by conssluserg-02.nifty.com with ESMTP id 11LEkEJw018830; Sun, 21 Feb 2021 23:46:15 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 11LEkEJw018830 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1613918775; bh=jpeCrPBkpqDTRmJNiKNUkX+1VgE88GRr1ejOnJsXFaY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=HAyL7AkohPuL4yy2HMBIdsu5SUvn1dvwYlxH/bL7qO/Vcwa/6lM+gcYNUzRnzDgSc tCNCcfuwHGcAlK6IT9aoZ3usZ5hiod3kbu1MAlLl3168IpWqRg6xPattT4RIoQnXOX buBy6JSgqZbzZ2sSvI+msSDCPh3s5NLJk7fDl5ZaJ2+H3cE4BfBo5fEi4RY/MpOVE+ WQBsOTq0ziwdKAi3APXk9ZfBdsn4NGTArQ9pE0hyZbSW4hXFTSH8Y3ki2REA/0ya1p DDxKCBhW5PnVekvqahP1bYO46rSzl8I1n87ngbUTIOkuOeB00kb51wEZAiLctQEll3 7V7myLRS7zKSw== X-Nifty-SrcIP: [209.85.215.182] Received: by mail-pg1-f182.google.com with SMTP id a4so8453360pgc.11; Sun, 21 Feb 2021 06:46:15 -0800 (PST) X-Gm-Message-State: AOAM530hOATVVNF9kraYMFShceLMp83BdgpOIiJkhY28ifXb0RBrhlhH +dRaXaoROBM5zzHtfslsBwjfSE8ambW7aiSC/xQ= X-Google-Smtp-Source: ABdhPJxma72dHfe9EEP25keVH9m43oNbIOaTLqkU9zVQyOC0KMwzA1NH/8Cl6Gk80jnpK8xgGwb5fbOUFUoteHKaFSk= X-Received: by 2002:a62:d454:0:b029:1ed:a6d6:539d with SMTP id u20-20020a62d4540000b02901eda6d6539dmr792619pfl.63.1613918774514; Sun, 21 Feb 2021 06:46:14 -0800 (PST) MIME-Version: 1.0 References: <20210215181511.2840674-1-mic@digikod.net> <20210215181511.2840674-4-mic@digikod.net> <8809a929-980a-95d1-42dc-576ff54e2923@digikod.net> In-Reply-To: <8809a929-980a-95d1-42dc-576ff54e2923@digikod.net> From: Masahiro Yamada Date: Sun, 21 Feb 2021 23:45:36 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/3] security: Add LSMs dependencies to CONFIG_LSM To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: Ondrej Mosnacek , James Morris , "Serge E . Hallyn" , Casey Schaufler , Nicolas Iooss , Linux Kbuild mailing list , Linux kernel mailing list , Linux Security Module list , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org On Sun, Feb 21, 2021 at 8:11 PM Micka=C3=ABl Sala=C3=BCn = wrote: > > > On 21/02/2021 09:50, Masahiro Yamada wrote: > > On Tue, Feb 16, 2021 at 4:03 AM Ondrej Mosnacek w= rote: > >> > >> On Mon, Feb 15, 2021 at 7:17 PM Micka=C3=ABl Sala=C3=BCn wrote: > >>> From: Micka=C3=ABl Sala=C3=BCn > >>> > >>> Thanks to the previous commit, this gives the opportunity to users, w= hen > >>> running make oldconfig, to update the list of enabled LSMs at boot ti= me > >>> if an LSM has just been enabled or disabled in the build. Moreover, > >>> this list only makes sense if at least one LSM is enabled. > >>> > >>> Cc: Casey Schaufler > >>> Cc: James Morris > >>> Cc: Masahiro Yamada > >>> Cc: Serge E. Hallyn > >>> Signed-off-by: Micka=C3=ABl Sala=C3=BCn > >>> Link: https://lore.kernel.org/r/20210215181511.2840674-4-mic@digikod.= net > >>> --- > >>> > >>> Changes since v1: > >>> * Add CONFIG_SECURITY as a dependency of CONFIG_LSM. This prevent an > >>> error when building without any LSMs. > >>> --- > >>> security/Kconfig | 4 ++++ > >>> 1 file changed, 4 insertions(+) > >>> > >>> diff --git a/security/Kconfig b/security/Kconfig > >>> index 7561f6f99f1d..addcc1c04701 100644 > >>> --- a/security/Kconfig > >>> +++ b/security/Kconfig > >>> @@ -277,6 +277,10 @@ endchoice > >>> > >>> config LSM > >>> string "Ordered list of enabled LSMs" > >>> + depends on SECURITY || SECURITY_LOCKDOWN_LSM || SECURITY_YAMA= || \ > >>> + SECURITY_LOADPIN || SECURITY_SAFESETID || INTEGRITY |= | \ > >>> + SECURITY_SELINUX || SECURITY_SMACK || SECURITY_TOMOYO= || \ > >>> + SECURITY_APPARMOR || BPF_LSM > >> > >> This looks really awkward, since all of these already depend on > >> SECURITY (if not, it's a bug)... I guarantee you that after some time > >> someone will come, see that the weird boolean expression is equivalent > >> to just SECURITY, and simplify it. > > > > > > Currently, LSM does not depend on SECURITY. > > So you can always define LSM irrespective of SECURITY, > > which seems a bug. > > > > So, I agree with adding 'depends on SECURITY'. > > > > What he is trying to achieve in this series > > seems wrong, of course. > > This may be wrong in the general case, but not for CONFIG_LSM. > > > > > > >> I assume the new mechanism wouldn't work as intended if there is just > >> SECURITY? If not, then maybe you should rather specify this value > >> dependency via some new field rather than abusing "depends on" (say, > >> "value depends on"?). The fact that a seemingly innocent change to the > >> config definition breaks your mechanism suggests that the design is > >> flawed. > > Masahiro, what do you think about this suggested "value depends on"? Of course, no. See the help text in init/Kconfig: This choice is there only for converting CONFIG_DEFAULT_SECURITY in old kernel configs to CONFIG_LSM in new kernel configs. Don't change this choice unless you are creating a fresh kernel config, for this choice will be ignored after CONFIG_LSM has been set. When CONFIG_LSM is already set in the .config, this choice is just ignored. So, oldconfig is working as the help message says. If you think 2623c4fbe2ad1341ff2d1e12410d0afdae2490ca is a pointless commit, you should ask Kees about it. > >> > >> I do think this would be a useful feature, but IMHO shouldn't be > >> implemented like this. > >> > >>> default "lockdown,yama,loadpin,safesetid,integrity,smack,seli= nux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK > >>> default "lockdown,yama,loadpin,safesetid,integrity,apparmor,s= elinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR > >>> default "lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf= " if DEFAULT_SECURITY_TOMOYO > >>> -- > >>> 2.30.0 > >>> > >> > >> -- > >> Ondrej Mosnacek > >> Software Engineer, Linux Security - SELinux kernel > >> Red Hat, Inc. > >> > > > > -- Best Regards Masahiro Yamada