# Kernel Self Protection

## alamahant

Hi Guys

Starting with the 5.13 kernel when emerging gentoo-sources with USE="experimental" there is an option for

Kernel Self Protection

Would you enable this or not?

Is it useful or it may cause more problems than it solves?

Thanks a lot...

----------

## NeddySeagoon

alamahant,

Trust but verify :)

Yes, sort of. Check the  Kernel Self Protection Project and see it it sets the same things as they recommended.

I've been using those settings for a few years, set by me, so I personally would not use the one click setting.

You also need some kernel parameters, which that option will not supply. 

I have 

```
root=UUID=33f110eb-3689-4dd8-bd8e-e704871da480 net.ifnames=0 kvm-intel.nested=1 slub_debug=P page_poison=1 slab_nomerge init=/init
```

afther reading the Kernel Self Protection Project wiki.

----------

## pietinger

 *alamahant wrote:*   

> Starting with the 5.13 kernel when emerging gentoo-sources with USE="experimental" [...]

 

You will have it in 5.10.61 also. And you will have it available WITHOUT USE="experimental" also.

 *alamahant wrote:*   

> Would you enable this or not?

 

I had all settings of KSPP before in my custon kernel ... but I enabled it also.

 *alamahant wrote:*   

> Is it useful or it may cause more problems than it solves?

 

You can only enable it, if some kernel options are disabled, so it is not for all users. See more in /usr/src/linx/distro/Kconfig (it is self-explained).

(I wrote a german guide for this before two month: https://forums.gentoo.org/viewtopic-p-8632690.html#8632690 )

Edit 2022-08-24: I made an english wiki article also. Link: https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Kernel_Hardening_with_KSPPLast edited by pietinger on Wed Aug 24, 2022 9:16 pm; edited 1 time in total

----------

## pietinger

 *NeddySeagoon wrote:*   

> I have 
> 
> ```
> [...]slub_debug=P page_poison=1[...]
> ```
> ...

 

If you have kernel 5.4 (or higher) you dont need it anymore, because you can use these command line parameters:

```
init_on_alloc=1 init_on_free=1
```

- or -  (I think it is better to set most of possible in the kernel, so I dont need to set it in the command line)

```
CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y and CONFIG_INIT_ON_FREE_DEFAULT_ON=y
```

These are set also when enabling our new Gentoo-KSPP-settings.

----------

## NeddySeagoon

pietinger,

Thank you. I may actually have both.

I have this bad habit of migrating kernel .configs with make oldconfig. :)

----------

## alamahant

Thank you so much guys for your care and attention.

Thanks.

----------

## pa4wdh

I'm not sure if this is the right place to share experiences with the KSPP options. I'll post them here, feel free to move if it's not appropriate.

I've been testing with the KSPP options on my amd64 desktop and my RISC-V PC (see https://forums.gentoo.org/viewtopic-t-998288.html).

On my amd64 desktop the kernel with these options set works ok. One problem i run into is that the virtualbox-modules fail to compile (and the old ones don't load anymore  :Smile:  ).

I think this might be due to the CONFIG_X86_32 option which has to be switched off, does anyone have a workaround for that?

On my RISC-V PC there is only the GENTOO_KERNEL_SELF_PROTECTION_COMMON option since there are no RISC-V specific options yet, but some options there don't seem to be as common as the name suggests:

- It depends on !X86_X32 this seems to be x86_64 specific  :Smile:  and might be better in GENTOO_KERNEL_SELF_PROTECTION_X86_64

- It selects GCC_PLUGIN_STACKLEAK which is only implemented for x86_64 and arm64 (implementation seems to be simple, but i don't know enough details to do it myself)

It's still re-compiling (which will take a while  :Smile: ) so i can't report if the new kernel actually works.

----------

## pietinger

 *pa4wdh wrote:*   

> I'm not sure if this is the right place to share experiences with the KSPP options.

 

Its perfect here.

 *pa4wdh wrote:*   

> [...]does anyone have a workaround for that?

 

You have only two choices:

1. Dont select gentoo-KSPP and do all the settings (from KSPP Homepage) by yourself (without the settings making problems).

2. Edit /usr/src/linux/distro/Kconfig (but this you have to do with every new kernel version).

 *pa4wdh wrote:*   

> On my RISC-V PC there is only the GENTOO_KERNEL_SELF_PROTECTION_COMMON option since there are no RISC-V specific options yet, but some options there don't seem to be as common as the name suggests:
> 
> - It depends on !X86_X32 this seems to be x86_64 specific  and might be better in GENTOO_KERNEL_SELF_PROTECTION_X86_64
> 
> - It selects GCC_PLUGIN_STACKLEAK which is only implemented for x86_64 and arm64 

 

If this is true, you should open a bug report for our developers. So, they can modify this in our distro-file.

----------

## NeddySeagoon

pa4wdh,

I have Virtualbox on a /no-multilib/ install with a kernel that has so support for 32 bit native software.

Virtualbox works here.

I suspect in a /multilib/ install it may do things differently, since it may build expecting 32 bit support from the host.

----------

## pa4wdh

I've been looking at the vbox issue a bit more, it seems modpost is acutally the one that's producing errors:

```

ERROR: modpost: "module_layout" [/var/tmp/portage/app-emulation/virtualbox-modules-6.1.28/work/vboxdrv/vboxdrv.ko] undefined!

ERROR: modpost: "latent_entropy" [/var/tmp/portage/app-emulation/virtualbox-modules-6.1.28/work/vboxdrv/vboxdrv.ko] undefined!

ERROR: modpost: "vmemmap_base" [/var/tmp/portage/app-emulation/virtualbox-modules-6.1.28/work/vboxdrv/vboxdrv.ko] undefined!

ERROR: modpost: "page_offset_base" [/var/tmp/portage/app-emulation/virtualbox-modules-6.1.28/work/vboxdrv/vboxdrv.ko] undefined!

ERROR: modpost: "stackleak_track_stack" [/var/tmp/portage/app-emulation/virtualbox-modules-6.1.28/work/vboxdrv/vboxdrv.ko] undefined!

```

The strange thing is that those are actually defined:

```

pc14 /usr/src/linux # grep -E "(module_layout|latent_entropy|vmemmap_base|page_offset_base|stackleak_track_stack)" *.symvers

vmlinux.symvers:0xea984526   stackleak_track_stack   vmlinux   EXPORT_SYMBOL   

vmlinux.symvers:0xfd43d459   latent_entropy   vmlinux   EXPORT_SYMBOL   

vmlinux.symvers:0x0cf512e4   module_layout   vmlinux   EXPORT_SYMBOL   

vmlinux.symvers:0x97651e6c   vmemmap_base   vmlinux   EXPORT_SYMBOL   

vmlinux.symvers:0x7cd8d75e   page_offset_base   vmlinux   EXPORT_SYMBOL   

```

@pietinger:

Thanks for your suggestion on the issue. I know i can disable the kernel option but i'd rather have a workaround to get vbox going with all the settings set how they are now.

Regarding RISC-V:

It's now running only with GCC_PLUGIN_STACKLEAK disabled. Boot took considerably longer (i guess due to zero'ing of memory, CPU isn't that fast and there's 16GB of memory), but for the rest it's working as it should.

I'm pretty sure stackleak is only implemented for arm64 and x86:

```

pc17 /usr/src/linux/arch # grep -R HAVE_ARCH_STACKLEAK *

Kconfig:config HAVE_ARCH_STACKLEAK

arm64/Kconfig:   select HAVE_ARCH_STACKLEAK

x86/Kconfig:   select HAVE_ARCH_STACKLEAK

```

I do have an old bugzilla account, is it possible to change the email address? Or should i just create a new one?

O, and one other thing i saw on both machines:

GENTOO_KERNEL_SELF_PROTECTION_COMMON also selects SECURITY_YAMA. SECURITY_YAMA depends on SECURITY, but that isn't selected. This leads to kconfig errors. Of course easy to solve by manually enabling CONFIG_SECURITY, but might be nice to include it with GENTOO_KERNEL_SELF_PROTECTION_COMMON.

----------

## NeddySeagoon

pa4wdh,

If you email infra@ with the email on the account now, they may be able to change the email on your bugs account.

They way want more evidence that you really own the account.

----------

## Onkobu

I personally go along the recommendations of kconfig-hardened-check[1]. It absolutely depends on your requirements. I also outlined this (partly) in another post of mine [2] regarding (controversial) load pinning.

I compared the settings once and had difficulties reverting them by simple unchecking. At least stack initialization doesn't return to the (hardest all zero) setting. But I didn't dive into the dependencies causing this. Simply reverted to the old config.

Instead of automagically setting security to 11 by checking a single option/ USE-variable I'd appreciate some recommendations with context in the security handbook[3] or similar.

You either don't need that level of security for a desktop machine that runs behind a NAT box to just check some virtual machine images. A server with an IP facing outside shouldn't be that open and versatile – limit attack surface. That is what motivates hardening. (Maybe you want instead a proxy or load balancer or application gateway in front of a DMZ with a second network segment next to it running the sensitive services.)

Locking services in powerful and versatile VMs can also be replaced quite often by more direct sandboxing in Linux namespaces – something that also lacks in the security handbook entirely. Planning to document this for distcc in a local network[4]. And user namespace for example is marked as security risk but essential to run for example non root containers (container as general term, locked down subsystem through namespaces not favoring any tool on top of runc). Also emerge starts to require namespaces for sandboxing in the kernel options.

[1] https://github.com/a13xp0p0v/kconfig-hardened-check

[2] https://forums.gentoo.org/viewtopic-p-8687128.html

[3] https://wiki.gentoo.org/wiki/Security_Handbook/Kernel_security

[4] https://wiki.gentoo.org/wiki/Talk:Distcc#Some_improvements_regarding_security

----------

## Onkobu

 *NeddySeagoon wrote:*   

> pa4wdh,
> 
> I have Virtualbox on a /no-multilib/ install with a kernel that has so support for 32 bit native software.
> 
> Virtualbox works here.
> ...

 

Should work since 2016: https://forums.virtualbox.org/viewtopic.php?t=80639#p378992

----------

## pa4wdh

 *NeddySeagoon wrote:*   

> pa4wdh,
> 
> If you email infra@ with the email on the account now, they may be able to change the email on your bugs account.
> 
> They way want more evidence that you really own the account.

 

Thanks for the pointer. I do still have access to the account but no longer use it, so i'll just create a new bugzilla account.

@Onkobu:

Thanks for sharing your thoughts on this

 *Quote:*   

> I personally go along the recommendations of kconfig-hardened-check[1]. It absolutely depends on your requirements.

 

This looks interesting, thanks for sharing.

 *Quote:*   

> I compared the settings once and had difficulties reverting them by simple unchecking. At least stack initialization doesn't return to the (hardest all zero) setting. But I didn't dive into the dependencies causing this. Simply reverted to the old config.

 

All settings changed by the options don't revert automatically when you deselect the option, as far as i know that's expected behavior of Kconfig. I also saved the -pre-kspp kernel configurations to be able to revert easily.

 *Quote:*   

> Instead of automagically setting security to 11 by checking a single option/ USE-variable I'd appreciate some recommendations with context in the security handbook[3] or similar. 

 

I think it's part of a bigger puzzle and if there's a single switch to help with a good part of the puzzle it's worth trying. IT security in general is easy to do wrong and hard to do right, anything that makes the right thing easier is welcome.

"Remove anything you don't need" from your security handbook is indeed a sensible advise, there have been numerous vulnerabilities that didn't apply to my systems because the kernel feature/use flag was disabled  :Smile: 

 *Quote:*   

> You either don't need that level of security for a desktop machine that runs behind a NAT box to just check some virtual machine images. A server with an IP facing outside shouldn't be that open and versatile – limit attack surface. That is what motivates hardening. (Maybe you want instead a proxy or load balancer or application gateway in front of a DMZ with a second network segment next to it running the sensitive services.) 

 

I understand it may be overdone for a desktop, but my desktop is my playground, it's where i test new stuff. The good thing about that i usually quickly notice when something doesn't work as it did before. When i'm sure enough i'll change my servers based on the experience gained with my experiments on my desktop.

As a side note: Be aware that the average desktop (with browsers/mail clients/etc) has a huge attack surface which huge applications handling untrusted data.

----------

## pietinger

pa4wdh,

I am also interested in a secure installation and wrote some articles (in german section) for that. In my first post of this thread (3.post) you will find a link to one of these articles. Look at the whole thread and forget my german sayings; but you will find some interesting links to english articles ...

----------

## pa4wdh

Small update: I created a bug report (830460) and a fix is on it's way

----------

## pa4wdh

Ok, the virtualbox problem was completely my own fault  :Shocked: , sorry for wasting your time with it.

I build all my kernels without module support, my desktop is the exception because of virtualbox. When i recompiled my kernel with the KSPP settings enabled i forgot to run make moduiles and make modules_install  :Confused: , this is still required even though i don't have anything selected as a module in the kernel config because it updates the symbol tables (which modpost uses, and couldn't do it's job because of that).

When that is done, the virtualbox modules compile correctly, load correctly and running VM's works as expected.

----------

## pietinger

In my first post in this thread I gave a link to a german guide. In the mean time I made an english article in our Wiki:

https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Kernel_Hardening_with_KSPP

----------

## pjp

Thank you!

Last year some time I started to use a common translation service while reading through it to make sure I understood the translation. It was still on the "I'll finish that some day" list.

----------

