Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.

On 2019/02/09 9:28, Tetsuo Handa wrote:

On 2019/02/09 1:23, Casey Schaufler wrote:

quoted

On 2/8/2019 2:52 AM, Tetsuo Handa wrote:

quoted

To help administrators easily understand what LSM modules are possibly enabled by default (which
have to be fetched from e.g. /boot/config-`uname -r`)

$ cat /sys/kernel/security/lsm

/sys/kernel/security/lsm is list of "actually" enabled modules, isn't it?
What I want is "possibly" enabled modules. Ubuntu would chose from either

  (a) explicitly add security=apparmor to kernel command line

or

  (b) explicitly remove tomoyo from CONFIG_LSM at kernel config

in order not to enable TOMOYO for those who want to enable only one of 
SELinux/Smack/AppArmor. And for those who want to enable TOMOYO, I think
that (b) (in other words, add

  lsm="modules listed in CONFIG_LSM" + ",tomoyo"

) will retain compatibility when it becomes possible to enable more than
one of SELinux/Smack/AppArmor at the same time.

If we can know "possibly" enabled modules from dmesg, users don't need to
look at e.g. /boot/config-`uname -r`. It is not essential, but it's handy.

Well, thinking again, specifying

lsm="modules listed in /sys/kernel/security/lsm" + ",tomoyo"

makes sense, for there is no need to care about disabled modules when
enabling TOMOYO. Therefore,

+	pr_info("Security Framework initializing: %s\n", order);
-	pr_info("Security Framework initializing\n");

won't be needed.

On 2019/02/09 6:33, Kees Cook wrote:

On Thu, Feb 7, 2019 at 8:24 AM Casey Schaufler [off-list ref] wrote:

quoted

I added Kees to the CC list. Kees, what to you think about
ignoring security= if lsm= is specified? I'm ambivalent.

This was one of many earlier suggestions, and the consensus seemed to
be "don't mix security= and lsm=". Why would anyone use both?

Then, can we add this change?

+	if (chosen_lsm_order) {
+		if (chosen_major_lsm) {
+			pr_info("security= is ignored because of lsm=\n");
+			chosen_major_lsm = NULL;
+		}
+	}