[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKj-Pq4krHmKd__4MoXBe1FK399cDZnSxdPigZo78tPfA@mail.gmail.com>
Date: Thu, 21 Mar 2019 09:38:20 -0700
From: Kees Cook <keescook@...omium.org>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Casey Schaufler <casey@...aufler-ca.com>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
linux-security-module <linux-security-module@...r.kernel.org>,
Trond Myklebust <trond.myklebust@...merspace.com>,
"open list:NFS, SUNRPC, AND..." <linux-nfs@...r.kernel.org>,
Anna Schumaker <anna.schumaker@...app.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: mount.nfs: Protocol error after upgrade to linux/master
On Tue, Mar 19, 2019 at 3:56 AM Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
>
> Since Kees Cook seems to be busy now, here is my version...
>
> From 885553e4793d9af2d4e9e99c7d137b0ec7b5f8ad Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> Date: Tue, 19 Mar 2019 19:52:31 +0900
> Subject: [PATCH] LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"
>
> Commit 70b62c25665f636c ("LoadPin: Initialize as ordered LSM") removed
> CONFIG_DEFAULT_SECURITY_{SELINUX,SMACK,TOMOYO,APPARMOR,DAC} from
> security/Kconfig and changed CONFIG_LSM to provide a fixed ordering as a
> default value. That commit expected that existing users (upgrading from
> Linux 5.0 and earlier) will edit CONFIG_LSM value in accordance with
> their CONFIG_DEFAULT_SECURITY_* choice in their old kernel configs. But
> since users might forget to edit CONFIG_LSM value, this patch revives
> the choice (only for providing the default value for CONFIG_LSM) in order
> to make sure that CONFIG_LSM reflects CONFIG_DEFAULT_SECURITY_* from their
> old kernel configs.
>
> Reported-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Signed-off-by: Kees Cook <keescook@...omium.org>
> Signed-off-by: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> ---
> security/Kconfig | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/security/Kconfig b/security/Kconfig
> index 1d6463f..743e594 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -239,9 +239,43 @@ source "security/safesetid/Kconfig"
>
> source "security/integrity/Kconfig"
>
> +choice
> + prompt "Default security module [superseded by 'Ordered list of enabled LSMs' below]"
> + default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX
> + default DEFAULT_SECURITY_SMACK if SECURITY_SMACK
> + default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO
> + default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR
> + default DEFAULT_SECURITY_DAC
> +
> + help
> + This choice is there only for converting CONFIG_DEFAULT_SECURITY in old
> + kernel config to CONFIG_LSM in new kernel config. Don't change this choice
> + unless you are creating a fresh kernel config, for this choice will be
> + ignored after CONFIG_LSM is once defined.
> +
> + config DEFAULT_SECURITY_SELINUX
> + bool "SELinux" if SECURITY_SELINUX=y
> +
> + config DEFAULT_SECURITY_SMACK
> + bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y
> +
> + config DEFAULT_SECURITY_TOMOYO
> + bool "TOMOYO" if SECURITY_TOMOYO=y
> +
> + config DEFAULT_SECURITY_APPARMOR
> + bool "AppArmor" if SECURITY_APPARMOR=y
> + config DEFAULT_SECURITY_DAC
> + bool "Unix Discretionary Access Controls"
> +
> +endchoice
> +
> config LSM
> string "Ordered list of enabled LSMs"
> - default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
> + default "yama,loadpin,safesetid,integrity,selinux" if DEFAULT_SECURITY_SELINUX
> + default "yama,loadpin,safesetid,integrity,smack" if DEFAULT_SECURITY_SMACK
> + default "yama,loadpin,safesetid,integrity,tomoyo" if DEFAULT_SECURITY_TOMOYO
> + default "yama,loadpin,safesetid,integrity,apparmor" if DEFAULT_SECURITY_APPARMOR
> + default "yama,loadpin,safesetid,integrity"
> help
> A comma-separated list of LSMs, in initialization order.
> Any LSMs left off this list will be ignored. This can be
This is mostly good. I'd like to keep the other LSMs listed though
(similar to what I had originally) so that if a legacy-major doesn't
initialize, later ones will be. I want to remove the concept of
"major" LSMs. The only thing that should matter is init order...
-Kees
> --
> 1.8.3.1
>
>
--
Kees Cook
Powered by blists - more mailing lists