Looking at Hardened

Hello!
Looking at the Hardened kernel and I was thinking of trying it. Then I realized it’s quite far behind (“low 5.7” if you know what I mean) instead of “low 5.8”.

I am trying to find out more info but when I google (sorry, when i duck) I mostly find old articles on how to harden your own kernel.

Anyone wants to fill me in a bit?

4 Likes

@Resiliencia runs the hardened kernel. Wait a bit and I am sure he’ll be along.

4 Likes

You read about it at: https://wiki.archlinux.org/index.php/Security
Search for Kernel hardening.

1 Like

Thank you, but this is exactly what I wrote above: I am interested in 1. What is done in the “default hardened” (so you don’t have to do it yourself) and 2. How far behind, and how frequent it updates.

There, in the arch wiki, there are a lot of details about the options enabled in the hardened kernel.
I tried once but went into some problems with brave browser and sandbox warnings…
Based on that, and also based on the fact that I like to use the newest cutting edge kernels, I switched back to the non hardened.

A few things that I found interesting in that wiki page, but non related to kernel hardening, is regarding the CPU vulnerabilities (I have an Intel i7 7700 which has a lot of vulnerabilities).
So changed my kernel cmd line in Grub, and now everything is mitgated…
You can confirm if this applies to you by: grep . -r /sys/devices/system/cpu/vulnerabilities/

Also changed my fstab for the file systems used for data to have the nodev,nosuid,noexec options.

There are other nice suggestions there, but based on my usage, this is what I found useful to me.

Regarding your last question, unfortunately I don’t know how often is updated…
PS: sorry for my english

4 Likes

Have you been over to its GitHub page to have a look?

1 Like

Hardened, this kernel is more focused on security than the other three kernels we know. In addition, implementations can be added such as:

AppArmor and SeLinux

Hmm… it’s not that far behind in its versions, I think 5.8 made Hardened late, but it updates its versions, almost at the same time as the current kernel or at most about 2 days later.

Since I use it, I can say that I see it a little faster than Zen and from the on and off much more precise.
Otherwise, there is not much to say about its behaviour unlike the other Arch kernels, now; if you want to configure it as it should be and as the Wiki indicates, it takes time, then there you can say that it is too safe with respect to the other kernels, in my humble opinion.
Linux 5.7.17.a-1-hardened

5 Likes

Thank you!
What you are basically saying is, regarding the last part, that taking the time to configure it manually is overkill?

Really ??
Then I wanna try :partying_face:

1 Like

To check kernel configs for potential security risks, you can use the kcc python script:
sudo pip install kcc

Then simply run
kcc /path/to/config

Example, default Arch config:

CONFIG_LEGACY_VSYSCALL_NONE is not set but is required to be set to y (Modern libc no longer needs a fixed-position mapping in userspace, remove it as a possible target.)
CONFIG_MODIFY_LDT_SYSCALL is set but is required to be not set (Unused dangerous option)
CONFIG_ACPI_CUSTOM_METHOD is set as =m but is required to be not set (Dangerous; enabling this allows direct physical memory writing)
CONFIG_MODULE_SIG_FORCE is not set but is required to be set to y (Enforce module signing)
CONFIG_INET_DIAG is set as =m but is required to be not set (Prior to v4.1, assists heap memory attacks; best to keep interface disabled)
CONFIG_DEVMEM is set but is required to be not set (/dev/mem is dangerous and has no legitimate users anymore)
CONFIG_PROC_KCORE is set but is required to be not set (Dangerous; exposes kernel text image layout)
CONFIG_HARDENED_USERCOPY_FALLBACK is set but is required to be not set (Protect against ioctl buffer overflows)
CONFIG_DEBUG_LIST is not set but is required to be set to y (Needed to protect against targeted corruption by rootkits)
CONFIG_DEBUG_SG is not set but is required to be set to y (Needed to protect against targeted corruption by rootkits)
CONFIG_DEBUG_NOTIFIERS is not set but is required to be set to y (Needed to protect against targeted corruption by rootkits)
CONFIG_DEBUG_CREDENTIALS is not set but is required to be set to y (Needed to protect against targeted corruption by rootkits)

Hardened:

CONFIG_MODULE_SIG_FORCE is not set but is required to be set to y (Enforce module signing)
CONFIG_INET_DIAG is set as =m but is required to be not set (Prior to v4.1, assists heap memory attacks; best to keep interface disabled)
2 Likes

These are the things that confuse me slightly; if this is pre-hardened, why aren’t the things that says “required to be set as X” not set?

Default Arch or hardened? As for default Arch, no idea, this is a question for Arch devs.

In case of MODULE_SIG_FORCE: difficult to enable because many people use out-of-tree modules (nvidia, vbox, …)

In case of INET_DIAG: only really dangerous if the module is loaded, which is normally not the case.

2 Likes

@Beardedgeek72
You can easily look at how far behind the hardened kernel is with the akm app:

As you can see, it is not behind at all.

4 Likes

I use Apparmor with the mainline and zen kernel.
From my searching I understood most apparmor profiles are available from and for Ubuntu.
But it is really easy to create your own profiles for the main packages (for me this means telegram, evolution and of course firefox). Maybe not the “best” profiles, but much better than nothing. Can recommend everyone to try.

1 Like

Trying to generate a profile for an app and get this:

ERROR: Can't find system log "/var/log/syslog". Please check permissions.

Edit: it seems Arch is writing to messages.log instead. How change so apparmor checks correctly?

By the way, the kernels support “lockdown” mode.

Lockdown here basically means that once booted, not even root can make changes to the running kernel. For example, it will not be possible to load or remove modules. Even if an attacker gained root access, (s)he cannot load malicious modules.

However, it also means that out-of-tree modules won’t be loaded (maybe it would work if the modules were signed?) so for many people it’s not really a good option.

To test it, simply use lockdown=integrity boot parameter.

1 Like

There… I have run it since yesterday before lunch and uninstalled the zen kernel today (keeping the LTS as backup, as always).

It is actually more responsive than both vanilla and zen kernels. An interesting side-effect I guess?

5 Likes

I will try that soon :grin:

1 Like

You’d have to check the kernel config.

Normally, hardened kernels are slower due to several security optimisations needing additional resources.

Could you run a couple benchmarks and compare?
“It’s more responsive” is not precise enough IMO.
That, and it’s 5.7 - difficult to compare with 5.8 I think.

EDIT: I have a difficult time to believe it is faster. linux-hardened has stack leak plugin enabled, this was disabled in default Arch because it cost too much performance: https://github.com/archlinux/svntogit-packages/commit/8c1be2f6cdd6b3fa1b9d06dfd8791dc580ebe364#diff-8d0411b338c83cd8cd8ad9d9db127101

That was with 5.2, maybe with newer kernels the performance improved again, dunno.

1 Like

All I am saying is that it boots quicker, loads the display manager quicker and loads into Xfce from the diplay manager quicker. With no benchmarks that’s noticeable. When IN Xfce… hard to tell since well Xfce is not exactly heavy to work with for a modern i5 processor.