Re: [PATCH 03/11] Kernel: Pin loading kernel files to one filesystem

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 6053 bytes --]

Hello,

Hmm, Peter confirmed to me that this works on the kernel he built.

> On 21 Mar 2022, at 20:24, alf(a)i100.no wrote:
> 
> Den 2022-03-21 19:50, skrev Michael Tremer:
>> Hello,
>>> On 21 Mar 2022, at 17:15, Arne Fitzenreiter <arne_f(a)ipfire.org> wrote:
>>> At my knowledge enforce loadpin is incompatible with initramfs.
>>> https://lwn.net/Articles/682302/
>> I cannot find that being mentioned in this article. And I am not sure
>> whether the initramdisk counts as its own file system.
> 
> Quoting what I think is the relevant section from the article
> "
> The current module is also likely to run into trouble on systems that boot with an initramfs image; the first modules will almost certainly be loaded from that image (that's why it exists, usually), causing loads to be pinned to a temporary filesystem that will go away at the end of the bootstrap process. In the current patch, if the filesystem to which loading is pinned disappears, loading of files will be disabled entirely — behavior that makes sense, but which may not lead to the desired results in an initramfs setting.
> "

Thank you for helping me finding the correct paragraph.

> And a somewhat related discussion
> https://forums.gentoo.org/viewtopic-p-8686594.html?sid=bbf2ffea6f1ad4a3f69073bfabfdb021

I generally do agree that it does not make a lot of sense for kernel modules to have this enabled. We sign our kernel modules anyways which means that we do not need to trust the filesystem we load them from. However, there is some benefit here for firmware and other files the kernel loads. Those have no protection, and we can slightly mitigate any attacks here. How likely is this? Very unlikely, but still we can protect ourselves against them.

So this means that we potentially cannot enable the ENFORCE mode. But we can boot up the system and very early in the boot process set the loadpin sysctl so that any other file systems being mounted after that point can be used to load any files into the kernel.

@Peter: Would you please change the patch?

-Michael

> And a patch to the kernel, which I could not figure out if has been merged
> https://lkml.org/lkml/2021/4/8/1446
> But it does not seem to be merged to me
> https://github.com/torvalds/linux/blob/5bfc75d92efd494db37f5c4c173d3639d4772966/security/loadpin/loadpin.c
> 
> Alf
> 
>>> Also we have some older installations that have a seperate /var partition and /lib/firmware was moved to /var/lib/firmware
>>> so i think we cannot apply this!
>> The firmware currently is in /lib/firmware and since we have now a way
>> to compress it, there is no need to move it any more. That should
>> allow us enabling this switch.
>> Best,
>> -Michael
>>> Arne
>>> Am 2022-03-19 22:09, schrieb Peter Müller:
>>>> This can be safely enabled on IPFire, as we never swap filesystems
>>>> during runtime.
>>>> Fixes: #12432
>>>> Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org>
>>>> ---
>>>> config/kernel/kernel.config.aarch64-ipfire | 3 ++-
>>>> config/kernel/kernel.config.armv6l-ipfire  | 3 ++-
>>>> config/kernel/kernel.config.riscv64-ipfire | 3 ++-
>>>> config/kernel/kernel.config.x86_64-ipfire  | 3 ++-
>>>> 4 files changed, 8 insertions(+), 4 deletions(-)
>>>> diff --git a/config/kernel/kernel.config.aarch64-ipfire
>>>> b/config/kernel/kernel.config.aarch64-ipfire
>>>> index 35c249253..d9179c061 100644
>>>> --- a/config/kernel/kernel.config.aarch64-ipfire
>>>> +++ b/config/kernel/kernel.config.aarch64-ipfire
>>>> @@ -7555,7 +7555,8 @@ CONFIG_FORTIFY_SOURCE=y
>>>> # CONFIG_SECURITY_SMACK is not set
>>>> # CONFIG_SECURITY_TOMOYO is not set
>>>> # CONFIG_SECURITY_APPARMOR is not set
>>>> -# CONFIG_SECURITY_LOADPIN is not set
>>>> +CONFIG_SECURITY_LOADPIN=y
>>>> +CONFIG_SECURITY_LOADPIN_ENFORCE=y
>>>> # CONFIG_SECURITY_YAMA is not set
>>>> # CONFIG_SECURITY_SAFESETID is not set
>>>> # CONFIG_SECURITY_LOCKDOWN_LSM is not set
>>>> diff --git a/config/kernel/kernel.config.armv6l-ipfire
>>>> b/config/kernel/kernel.config.armv6l-ipfire
>>>> index 5b4ff8e20..522278160 100644
>>>> --- a/config/kernel/kernel.config.armv6l-ipfire
>>>> +++ b/config/kernel/kernel.config.armv6l-ipfire
>>>> @@ -7559,7 +7559,8 @@ CONFIG_HARDENED_USERCOPY_PAGESPAN=y
>>>> # CONFIG_SECURITY_SMACK is not set
>>>> # CONFIG_SECURITY_TOMOYO is not set
>>>> # CONFIG_SECURITY_APPARMOR is not set
>>>> -# CONFIG_SECURITY_LOADPIN is not set
>>>> +CONFIG_SECURITY_LOADPIN=y
>>>> +CONFIG_SECURITY_LOADPIN_ENFORCE=y
>>>> # CONFIG_SECURITY_YAMA is not set
>>>> # CONFIG_SECURITY_SAFESETID is not set
>>>> # CONFIG_SECURITY_LOCKDOWN_LSM is not set
>>>> diff --git a/config/kernel/kernel.config.riscv64-ipfire
>>>> b/config/kernel/kernel.config.riscv64-ipfire
>>>> index d4c0e0451..ebb830eb7 100644
>>>> --- a/config/kernel/kernel.config.riscv64-ipfire
>>>> +++ b/config/kernel/kernel.config.riscv64-ipfire
>>>> @@ -6192,7 +6192,8 @@ CONFIG_FORTIFY_SOURCE=y
>>>> # CONFIG_SECURITY_SMACK is not set
>>>> # CONFIG_SECURITY_TOMOYO is not set
>>>> # CONFIG_SECURITY_APPARMOR is not set
>>>> -# CONFIG_SECURITY_LOADPIN is not set
>>>> +CONFIG_SECURITY_LOADPIN=y
>>>> +CONFIG_SECURITY_LOADPIN_ENFORCE=y
>>>> # CONFIG_SECURITY_YAMA is not set
>>>> # CONFIG_SECURITY_SAFESETID is not set
>>>> # CONFIG_SECURITY_LOCKDOWN_LSM is not set
>>>> diff --git a/config/kernel/kernel.config.x86_64-ipfire
>>>> b/config/kernel/kernel.config.x86_64-ipfire
>>>> index 8b525ef89..675c3ce1e 100644
>>>> --- a/config/kernel/kernel.config.x86_64-ipfire
>>>> +++ b/config/kernel/kernel.config.x86_64-ipfire
>>>> @@ -6968,7 +6968,8 @@ CONFIG_FORTIFY_SOURCE=y
>>>> # CONFIG_SECURITY_SMACK is not set
>>>> # CONFIG_SECURITY_TOMOYO is not set
>>>> # CONFIG_SECURITY_APPARMOR is not set
>>>> -# CONFIG_SECURITY_LOADPIN is not set
>>>> +CONFIG_SECURITY_LOADPIN=y
>>>> +CONFIG_SECURITY_LOADPIN_ENFORCE=y
>>>> # CONFIG_SECURITY_YAMA is not set
>>>> # CONFIG_SECURITY_SAFESETID is not set
>>>> # CONFIG_SECURITY_LOCKDOWN_LSM is not set