Kicksecure security-misc: a sysctl hardening set for privacy focused desktops

A hardening policy expressed as one sysctl drop-in

Kicksecure security-misc collects miscellaneous Linux security hardening settings for Kicksecure and derivatives. The primary language is Shell, and the project describes itself as a set of settings rather than as a tool, which is the right description: there is no daemon, no service and no runtime component.

The mechanism is the standard Linux one. Sysctl settings are configured via the `/usr/lib/sysctl.d/990-security-misc.conf` configuration file, and the README says significant hardening is applied to a myriad of components. The 990 prefix places the file late in the sysctl.d ordering, so it runs after the distribution's own defaults and overrides them.

That single file is the whole of the kernel space and user space policy, and the README enumerates it exhaustively. Kernel space items include restricting access to kernel addresses through kernel pointers regardless of user privileges, restricting access to the kernel logs to `CAP_SYSLOG` since they often contain sensitive information, preventing kernel information leaks in the console during boot, restricting `bpf()` to `CAP_BPF`, restricting TTY line discipline loading to `CAP_SYS_MODULE`, and restricting the `userfaultfd()` syscall to `CAP_SYS_PTRACE`, which the README notes reduces the likelihood of use-after-free exploits.

The user space side disables `ptrace()` for all processes, randomizes addresses for mmap base, stack, VDSO pages and heap, raises the minimum address a process can request for memory mapping to 64KB against kernel null pointer dereference vulnerabilities, and increases the maximum number of memory map areas a process may use to 1,048,576.

The net effect is that a reviewer reads one file and knows the kernel policy of the system. That is the value of the approach, and it is also the reason the file is long.

What the settings are defending against

The individual settings are grouped by the attack they address, and the README is explicit about the reasoning in each case.

Several items exist because of a history of kernel exploitation. Disabling `kexec` is described as preventing its use to replace the running kernel. Disabling asynchronous I/O is attributed to `io_uring` having been the source of numerous kernel exploits. Disabling 32-bit vDSO mappings is justified as a legacy compatibility feature. Restricting the `userfaultfd()` syscall to `CAP_SYS_PTRACE` is tied to use-after-free exploits, and that is the same class of bug that made user namespaces and `bpf()` worth restricting to privileged callers in the first place.

The networking section is the longest and the most conventional, and it reads like a checklist. TCP SYN cookie protection assists against SYN flood attacks, reverse path filtering of packets from all interfaces prevents IP spoofing, ICMP redirect acceptance and sending are disabled to prevent man-in-the-middle attacks and minimize information disclosure, and ARP filtering mitigates ARP spoofing and cache poisoning. The README also drops gratuitous ARP packets, ignores ICMP echo requests to prevent clock fingerprinting and Smurf attacks, ignores bogus ICMP error responses, and disables source routing.

The IPv6 position is worth noting because it is the opposite of the usual default. The README says it does not accept IPv6 router advertisements and solicitations, which can result in both man-in-the-middle and denial-of-service attacks, and IPv6 Privacy Extensions are listed as optional rather than enabled.

Smaller sections cover the physical world. The CD-ROM/DVD section disables automatic tray closure and ejection functionality to prevent scripted tray cycling attacks, disables debug messages to limit information disclosure, and optionally restricts the drives by disabling kernel checking and hardware access.

The settings that can break your system

A hardening set is only useful if you know which parts will cost you, and the README is unusually clear about the trade-offs in three places.

The first is the immediate panic on out of memory condition. The setting forces an immediate kernel panic on OOM, which combined with the setting that forces an immediate system reboot on a single kernel panic means the machine goes down rather than relying on the oom_killer to terminate a process by OOM score. The README's stated reason is to avoid arbitrarily terminating security features based on their OOM score. Its stated cost is that this creates the risk of userspace-based denial-of-service attacks that maliciously fill memory. That is a deliberate choice in favour of failing loudly, and it is a real availability risk.

The second is the setting that forces the kernel to immediately panic on oopses and on kernel warnings in the `WARN()` path, which the README ties to kernel exploitation attempts and defence. The third is the optional forcing of immediate kernel panics on NMIs triggered by serious hardware-level I/O issues, uncorrectable memory and hardware errors, and undefined or unknown sources, in order to prevent data corruption.

User namespaces are the fourth. Disabling all use of user namespaces is optional, as is restricting them to `CAP_SYS_ADMIN`, with the reason given that they can lead to substantial privilege escalation. That choice has a price: sandboxed applications, container tooling and several development workflows depend on user namespaces, and the README itself calls the restriction optional.

The fifth is the networking pair. Disabling SACK and DSACK is listed as optional because they have historically been a known vector for exploitation, and disabling TCP timestamps allows detecting the system time, so the README also recommends disabling reuse of `TIME_WAIT` sockets for new outgoing connections.

If you take one practical lesson from this file, take this one: the optional items are optional for a reason, and the reasoning in the README is a better guide than the fact that a setting exists.

CPU mitigations at boot, deliberately stricter than the distribution default

The boot side of the project is handled separately from sysctl. Mitigations for known CPU vulnerabilities are enabled in their strictest form and simultaneous multithreading, SMT, is disabled, configured through the `/etc/default/grub.d/40_cpu_mitigations.cfg` configuration file.

The interesting decision here is the one about not using the built-in mechanism. The README says the project does not rely on the already enabled-by-default `mitigations=auto` kernel boot parameter to perform CPU mitigations, as many other distributions do. Its reason is twofold: the use is totally redundant, and it does not apply all hardening settings to their strictest possible levels.

This is a case where a distribution default and a privacy focused distribution disagree about the right trade-off, and the resolution is to spell the settings out in a GRUB configuration file. The cost of that choice is that it is on the distribution maintainer to track new CPU vulnerabilities and update the file, because the kernel's own automatic mechanism will not do it. The benefit is that the behaviour is auditable in one place rather than depending on a heuristic that decides per workload.

Disabling SMT by default is the other visible decision, and it sits in the same category. It costs measurable performance on some workloads, and it reduces the attack surface of a class of side channel attacks that exploit the timing relationship between the two threads of a core.

The repository layout shows how this is assembled for a distribution: a `debian/` directory, an `rpm_spec/` directory, a `usr/` tree, an `etc/` tree, a `var/` tree and a `ci/` directory, plus a `Makefile.builder`. That is a packaging shape rather than a script shape, which is a hint about who this is for.

What this repository is not

The first thing to understand is that this is not an installable tool. There is no command to run, no package to install with a package manager and no configuration wizard. The repository contains the policy, and integrating it means copying the configuration into an image build or onto a system.

The second is that it is not a complete security baseline. It covers kernel settings, boot parameters and a few device level behaviours. It does not cover file system permissions, mandatory access control, service configuration, package verification or network policy. Reading it as a checklist for hardening a system would be a mistake; it is a subset, and a subset chosen by people who have opinions about desktops and privacy.

The third is the version mismatch risk, and the README raises it first. All the security features seen in this repository may not yet be incorporated into a public Kicksecure or Whonix release, and the project directs readers to the forums with accompanying dates to see what is actually included in the most recent release. That is a two-way warning. If you are a user, the repository may contain settings your installed release does not have. If you are a maintainer, the repository may run ahead of what is shipped.

For that reason the repository also carries a `changelog.upstream` file, a `version` file and a CI directory, which is how a project tracks the gap between upstream changes and what has been packaged.

The licence is a custom one that GitHub cannot classify, with a COPYING file at the top level. If you plan to reuse these settings in a product, read the COPYING file rather than assuming the terms of a standard licence.

How this compares to sysctl hardening done elsewhere

The alternative to a curated drop-in file is to write your own. The difference in approach is entirely in the review and maintenance burden, and in who carries it.

A hand-rolled sysctl configuration starts as a small file with a handful of obvious settings: disable dangerous kernel modules, restrict kernel pointers, protect the dmesg buffer. It grows as each incident or paper prompts an addition, and it is usually owned by one person on a team, whose institutional knowledge leaves when they do. It also tends to drift, because nobody tests whether a setting breaks a workload.

The Kicksecure approach moves that burden into a public file that anyone can read, comment on and track, with the KSPP recommended settings as the stated starting point. The README says the kernel hardening section is inspired by the Kernel Self Protection Project and attempts to implement all recommended Linux kernel settings by the KSPP and many more sources. So the file is not a matter of taste alone; it is a documented baseline plus additions, and the reasoning is written next to each setting.

The other alternative is to use a distribution's own hardening profile, which several mainstream distributions now ship. The difference there is that the profile is chosen for a general population and usually errs toward compatibility, and the settings are applied at the distribution's chosen level rather than the strictest one.

The trade is that the strictest level is not free. A machine configured this way will run into software that expects ptrace, user namespaces, SACK, TCP timestamps or a working io_uring, and each of those collisions produces a bug report rather than a security finding. The value of this repository is that it names the collisions in advance.

Editorial conclusion

Adopt Kicksecure security-misc as a reference when you are building a privacy oriented Linux distribution or a hardened workstation image and want a reviewed set of kernel settings rather than assembling sysctl values yourself, since the drop-in approach makes the whole policy reviewable in one file. Do not adopt it wholesale on a general purpose server, because the settings assume a desktop threat model, and several of them, including user namespace restrictions, immediate panic on OOM and the disabling of SACK, are documented as optional and carry a denial of service trade-off. Before you enable anything, read the upstream forum thread to see which settings are actually in a public Kicksecure or Whonix release, and test each optional setting against the software you need to run.

Frequently asked questions

Official sources

1. Issues
2. Kicksecure/security-misc on GitHub
3. Project website
4. README