Suggestion: default to lockdown=confidentiality in kernel 5.4+

[hugecheese]

	lockdown=	[SECURITY]
			{ integrity | confidentiality }
			Enable the kernel lockdown feature. If set to
			integrity, kernel features that allow userland to
			modify the running kernel are disabled. If set to
			confidentiality, kernel features that allow userland
			to extract confidential information from the kernel
			are also disabled.

[hugecheese]

Also as a side note @anthraxx kernel v5.4-rc6 just dropped an hour ago

[tsautereau-anssi]

@anthraxx What do you think? I see nothing wrong about that.

[Bernhard40]

@tsautereau-anssi the problem with that is it requires all loaded modules to be signed which in most scenarios will break out-of-three ones like wireguard. Managing this on runtime is more user friendly.

[tsautereau-anssi]

@Bernhard40 Fair enough ;)

[anthraxx]

For now i think i agree with this opinion as a huge majority of users runs on desktop systems using dkms etc. This would create quite a bad default user experience for the majority. For LOCKDOWN a better idea would be to have a nice place to document things similar to CLIP OS and recommend setting lockdown at runtime if you don't need modules. Mostly I'm more a fan ob being restrictive and secure by default, so an opt-out approach, but I believe lockdown would be quite problematic.

[tsautereau-anssi]

FWIW I use lockdown in confidentiality mode and I can still load a wireguard module obtained via Arch Linux's wireguard-dkms package. I observe the following in my kernel logs:

wireguard: loading out-of-tree module taints kernel.
wireguard: module verification failed: signature and/or required key missing - tainting kernel
wireguard: WireGuard 0.0.20200318 loaded. See www.wireguard.com for information.
wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <[email protected]>. All Rights Reserved.

I'm using the default Kconfig from Arch Linux's linux-hardened package, which features:

CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
CONFIG_MODULE_SIG_ALL=y

I'll investigate this shortly.

[Bernhard40]

https://github.com/torvalds/linux/blob/aefcf2f4b58155d27340ba5f9ddbe9513da8286d/kernel/module.c#L2864

[tsautereau-anssi]

https://github.com/torvalds/linux/blob/aefcf2f4b58155d27340ba5f9ddbe9513da8286d/kernel/module.c#L2864

Can you elaborate please? I read that code beforehand and it doesn't help me understand.

[anthraxx]

that comment boil down to CONFIG_MODULE_SIG_FORCE being enabled or module.sig_enforce=1 being supplied and only then it does return -EKEYREJECTED;

However, that is only the signature enforcing part, it calls security_locked_down(LOCKDOWN_MODULE_SIGNATURE);. in https://github.com/torvalds/linux/blob/aefcf2f4b58155d27340ba5f9ddbe9513da8286d/kernel/module.c#L2882 When confidentiality is set, f.e. via cmdline in https://github.com/torvalds/linux/blob/aefcf2f4b58155d27340ba5f9ddbe9513da8286d//security/lockdown/lockdown.c#L69 this should lead to https://github.com/torvalds/linux/blob/aefcf2f4b58155d27340ba5f9ddbe9513da8286d//security/lockdown/lockdown.c#L55 which sets the option and and should print a pr_notice. After that, the code in https://github.com/torvalds/linux/blob/aefcf2f4b58155d27340ba5f9ddbe9513da8286d//security/lockdown/lockdown.c#L88 should fail with -EPERM which should bail out in https://github.com/torvalds/linux/blob/aefcf2f4b58155d27340ba5f9ddbe9513da8286d/kernel/module.c#L3799 load_module https://github.com/torvalds/linux/blob/aefcf2f4b58155d27340ba5f9ddbe9513da8286d/kernel/module.c#L3968

[tsautereau-anssi]

that comment boil down to CONFIG_MODULE_SIG_FORCE being enabled or module.sig_enforce=1 being supplied and only then it does return -EKEYREJECTED;

Yes sure but security_locked_down(LOCKDOWN_MODULE_SIGNATURE) should return -EPERM. But never mind, I'm just silly. I set lockdown=confidentiality on my command line, but I don't explicitly enable lockdown via the lsm= parameter.

[tsautereau-anssi]

So @anthraxx you might consider changing CONFIG_LSM="yama" to CONFIG_LSM=lockdown,yama in your Arch package config.

[Bernhard40]

@tsautereau-anssi so dkms modules are blocked if you set both lockdown=confidentiality and lsm=lockdown?

[tsautereau-anssi]

@tsautereau-anssi so dkms modules are blocked if you set both lockdown=confidentiality and lsm=lockdown?

Yes.

[sempervictus]

This is harder for upstream/more generic kernels, but it is quite viable if you're building all your modules together (by dragging them kicking && screaming into the tree). Will add to our linux-hardened setups, thanks.