kernel-hardening-checker - A tool for checking the security hardening options

项目说明

kernel-hardening-checker

![GitHub tag (latest by date)]() ![License: GPL v3]()<br />
![status-badge]()<br />
![functional test]() ![functional test co]()<br />
![引擎 unit-test]() ![unit-test co]()<br />
![static analysis]() ![package test]()

Moti

There are plenty of security hardening options for the Linux kernel. A lot of them are
not enabled by the major distros. We have to enable these options ourselves to
make our systems more secure.

But nobody likes checking configs manually. So let the computers do their job!

__kernel-hardening-checker__ (formerly __kconfig-hardened-check__) is a 工具 for checking the security hardening options of the Linux kernel.

License: GPL-3.0.

Repositories

- At GitHub <
- At Codeberg: < (go there if something goes wrong with GitHub)
- At SourceCraft: <

Features

kernel-hardening-checker supports checking:

- Kconfig options (compile-time)
- Kernel command line arguments (boot-time)
- Sysctl parameters (runtime)

Supported architectures:

- X86_64
- X86_32
- ARM64
- ARM
- RISC-V

The security hardening recommendations are based on:

- [KSPP recommended settings][1]
- [Direct feedback from the Linux kernel maintainers][23]
- Kernel options disabled by [grsecurity][3] to cut attack surface
- [CLIP OS kernel configuration][2]
- [GrapheneOS][25] recommendations
- [SECURITY_LOCKDOWN_LSM][5] patchset
- [CIS Benchmark][27]

I also created the [__Linux Kernel Defence Map__][4], which is a graphical representation of the
relationships between security hardening features and the corresponding classes
or exploitation techniques.

Attention!

Please note that changing the Linux kernel security parameters may also affect system performance
and functionality of userspace software. Therefore, when setting these parameters, consider
the threat model of your Linux-based information system and thoroughly test its typical workload.

Installation

There are multiple options:

- You can install the package from this Git repository using pip:

If you encounter an error due to an externally managed en, create a en using python3 -m venv.

- You can install the kernel-hardening-checker package via the package manager on some GNU/Linux distributions. See <

- Alternatively, you can simply run ./bin/kernel-hardening-checker from the cloned repository without installation.

Usage

Output modes

- no -m argument for the default output mode (see the example below)
- -m for printing additional info:
- the configuration options without a corresponding check
- the internals of complex checks with AND/OR, like this:

- -m json for printing the results in JSON format (for combining kernel-hardening-checker with other tools)
- -m show_ok for showing only successful checks
- -m show_fail for showing only failed checks

Example output

Generating a Kconfig fragment with the security hardening options

With the -g argument, the 工具 generates a Kconfig fragment with the security hardening options for the selected architecture.

This Kconfig fragment can be merged with the existing Linux kernel config:

Thanks

Thanks to the [contributors][26] and users of this project!

Questions and answers

❓ How do all these kernel parameters influence the Linux kernel security?

To answer this question, you can use the kernel-hardening-checker [sources of recommendations][24]
and the [Linux Kernel Defence Map][4] with its references.

❓ What about the performance impact of these security hardening features?

That is not an easy question, since the performance impact depends on the system workload.
A detailed e of the performance impact of Linux security hardening features is
in TODO (the issue [#66][21]). There are some interesting works in this area:
- Ike De [][7] conducted some performance tests and described the results in [this article][8].
- Fabian Rauscher, Benedict Herzog, Timo Hönig, and Daniel Gruss published an article
["Systematic Analysis of Kernel Security Performance and Energy Costs"][28] that describes
energy and run-time o of the hardware mitigations (CONFIG_CPU_MITIGATIONS).

❓ Can I easily check which kernel support some Kconfig option?

Yes. See the [LKDDb][18] project (Linux Kernel Dri) by Giacomo Catenazzi [][19].
You can use it for the mainline or stable tree from [kernel.org][20] or for your custom kernel sources.

❓ Does my kernel have all those mitigations of Transient Execution in my hardware?

Checking the kernel config is not enough to answer this question.
I highly recommend using the [spectre-meltdown-checker][13] 工具 maintained by Stéphane Lesimple [][14].

❓ How can I disable loading of Linux kernel modules?

You can cut the attack surface of your system and protect it from many LPE exploits if you disable loading Linux kernel modules.

However, it's not easy to do that without breaking the needed functionality 😉. There are several options:

1. Compile the modules you need into the kernel and disable CONFIG_MODULES. That is not possible if you use a precompiled kernel from some GNU/Linux distribution.

2. Use the nomodule kernel boot parameter. That is possible only if your kernel image contains all the needed functionality and you don't have to load any modules.

3. Enable the kernel.modules_disabled sysctl parameter __after your system has booted and loaded all the needed kernel modules__.
It's a good compromise: this sysctl parameter disables loading kernel modules until the next reboot. I' a systemd unit that performs this task:

To enable this service, run the following commands and reboot:

If you need some time after booting for manual actions that cause loading kernel modules, then uncomment ExecStartPre. It's a nice hack 😊.
There is another approach: if you know which kernel modules you need beforehand, you can simply call modprobe for them before locking modules_disabled.

4. Write an empty value to the kernel.modprobe sysctl parameter. This is the weakest option, which only disables kernel module autoloading.
Moreover, writing the original value /usr/bin/modprobe back to this sysctl parameter re-enables this dangerous feature.

❓ How does disabling CONFIG_USER_NS cut the attack surface? It's needed for containers!

Yes, the CONFIG_USER_NS option provides some isolation between the userspace programs,
but the 工具 recommends disabling it to cut the attack surface __of the kernel__.

The rationale:

- An LWN article about the corresponding LKML discussion:

- A Twitter thread about CONFIG_USER_NS and security:

- A good o of the trade-off between having user namespaces enabled, disabled and a only for root:

❓ KSPP and CLIP OS recommend CONFIG_PANIC_ON_OOPS=y. Why doesn't kernel-hardening-checker do the same?

I can't support this recommendation because:
- It decreases system robustness (a kernel oops is still not a rare situation even on production systems)
- It allows easier denial-of-service attacks on the whole system

You should enable CONFIG_PANIC_ON_OOPS if:
- Your kernel doesn't encounter oopses during a typical workload
- An occasional system reboot is not a problem in your use case

I see a good compromise, which kernel-hardening-checker recommends:
- Enable the CONFIG_BUG kconfig option. If a kernel oops happens in the process context, the offending/attacking process is killed. In other cases, the kernel panics, which is similar to CONFIG_PANIC_ON_OOPS=y.
- Set the sysctl options kernel.oops_limit and kernel.warn_limit to 100, for example. On the one hand, this value doesn't allow easy DoS. On the other hand, it is not too large to catch the exploitation attempts generating a lot of kernel warnings or oopses.

❓ Why does enabling CONFIG_STATIC_USERMODEHELPER break things in my GNU/Linux system?

Linux kernel usermode helpers can be used for pri escalation in kernel exploits
([example 1][9], [example 2][10]). CONFIG_STATIC_USERMODEHELPER prevents that method. But it
requires the corresponding support in the userspace: see the [example implementation][11] by
Tycho Andersen [][12].

❓ Why is the CONFIG_GCC_PLUGINS option automatically disabled during the kernel compilation?

It means that your gcc doesn't support plugins. For example, if you have gcc-14 on Ubuntu,
try to install the gcc-14-plugin-dev package; it should help.

[1]:
[2]:
[3]:
[4]:
[5]:
[6]:
[7]:
[8]:
[9]:
[10]:
[11]:
[12]:
[13]:
[14]:
[15]:
[16]:
[17]:
[18]:
[19]:
[20]:
[21]:
[22]:
[23]:
[24]:
[25]:
[26]:
[27]:
[28]:

项目信息

开发语言：Python

Star 数：2139

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕A 工具 for checking the security hardening options of the Linux kernel展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。