Borrowing from here to match hardened profile with more recent kernels:
* https://madaidans-insecurities.github.io/guides/linux-hardening.html?#boot-parameters
* https://github.com/a13xp0p0v/kernel-hardening-checker/
Removed "slub_debug" as that option disables kernel memory address
hashing. You also see a big warning about this in the dmesg:
"This system shows unhashed kernel memory addresses via the console, logs, and other interfaces."
"init_on_alloc=1" and "init_on_free=1" zeroes all SLAB and SLUB allocations. Introduced in 6471384af2a6530696fc0203bafe4de41a23c9ef. Also the default for the Android Google kernel btw. It is on by default through the KConfig.
"slab_nomerge" prevents the merging of slab/slub caches. These are
effectively slab/slub pools.
"LEGACY_VSYSCALL_NONE" disables the older vsyscall mechanic that relies on
static address. It got superseeded by vdsos a decade ago. Read some
LWN.net to learn more ;)
"debugfs=off" I'm sure there are some few userspace programs that rely on
debugfs, but they shouldn't.
Most other things mentioned on the blog where already the default on a
running machine or may not be applicable.
Most other Kconfigs changes come from the kernel hardening checker and
were added, when they were not applied to the kernel already.
Unsure about CONFIG_STATIC_USERMODEHELPER. Would need testing.
Yama is a LSM which restricts debugging. This prevents processes from
snooping on another. It can be easily disabled with sysctl.
This was initially included in #14392 and disabled by default by
86721a5f78.
This has been part of the hardened configuration, but many other distros
ship this for quite some time (Ubuntu for about ten years), so I'd say
it might make sense to enable this per default.
The `nix.*` options, apart from options for setting up the
daemon itself, currently provide a lot of setting mappings
for the Nix daemon configuration. The scope of the mapping yields
convience, but the line where an option is considered essential
is blurry. For instance, the `extra-sandbox-paths` mapping is
provided without its primary consumer, and the corresponding
`sandbox-paths` option is also not mapped.
The current system increases the maintenance burden as maintainers have to
closely follow upstream changes. In this case, there are two state versions
of Nix which have to be maintained collectively, with different options
avaliable.
This commit aims to following the standard outlined in RFC 42[1] to
implement a structural setting pattern. The Nix configuration is encoded
at its core as key-value pairs which maps nicely to attribute sets, making
it feasible to express in the Nix language itself. Some existing options are
kept such as `buildMachines` and `registry` which present a simplified interface
to managing the respective settings. The interface is exposed as `nix.settings`.
Legacy configurations are mapped to their corresponding options under `nix.settings`
for backwards compatibility.
Various options settings in other nixos modules and relevant tests have been
updated to use structural setting for consistency.
The generation and validation of the configration file has been modified to
use `writeTextFile` instead of `runCommand` for clarity. Note that validation
is now mandatory as strict checking of options has been pushed down to the
derivation level due to freeformType consuming unmatched options. Furthermore,
validation can not occur when cross-compiling due to current limitations.
A new option `publicHostKey` was added to the `buildMachines`
submodule corresponding to the base64 encoded public host key settings
exposed in the builder syntax. The build machine generation was subsequently
rewritten to use `concatStringsSep` for better performance by grouping
concatenations.
[1] - https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md
Enabling the profile can lead to hard-to-debug issues, which should be
warned about in addition to the cost in features and performance.
See https://github.com/NixOS/nixpkgs/issues/108262 for an example.
linux-hardened sets kernel.unprivileged_userns_clone=0 by default; see
anthraxx/linux-hardened@104f44058f.
This allows the Nix sandbox to function while reducing the attack
surface posed by user namespaces, which allow unprivileged code to
exercise lots of root-only code paths and have lead to privilege
escalation vulnerabilities in the past.
We can safely leave user namespaces on for privileged users, as root
already has root privileges, but if you're not running builds on your
machine and really want to minimize the kernel attack surface then you
can set security.allowUserNamespaces to false.
Note that Chrome's sandbox requires either unprivileged CLONE_NEWUSER or
setuid, and Firefox's silently reduces the security level if it isn't
allowed (see about:support), so desktop users may want to set:
boot.kernel.sysctl."kernel.unprivileged_userns_clone" = true;
As discussed in https://github.com/NixOS/nixpkgs/pull/73763, prevailing
consensus is to revert that commit. People use the hardened profile on
machines and run nix builds, and there's no good reason to use
unsandboxed builds at all unless you're in a platform that doesn't
support them.
This reverts commit 00ac71ab19.
Disables the build sandbox by default to avoid incompatibility with
defaulting user namespaces to false. Ideally there would be some kind of
linux kernel feature that allows us to trust nix-daemon builders to
allow both nix sandbox builds and disabling untrusted naemspaces at the
same time.
The rationale for this is that old filesystems have recieved little scrutiny
wrt. security relevant bugs.
Lifted from OpenSUSE[1].
[1]: 8cb42fb665
Co-Authored-By: Renaud <c0bw3b@users.noreply.github.com>
systemd provides two sysctl snippets, 50-coredump.conf and
50-default.conf.
These enable:
- Loose reverse path filtering
- Source route filtering
- `fq_codel` as a packet scheduler (this helps to fight bufferbloat)
This also configures the kernel to pass coredumps to `systemd-coredump`.
These sysctl snippets can be found in `/etc/sysctl.d/50-*.conf`,
and overridden via `boot.kernel.sysctl`
(which will place the parameters in `/etc/sysctl.d/60-nixos.conf`.
Let's start using these, like other distros already do for quite some
time, and remove those duplicate `boot.kernel.sysctl` options we
previously did set.
In the case of rp_filter (which systemd would set to 2 (loose)), make
our overrides to "1" more explicit.
slab_nomerge may reduce surface somewhat
slub_debug is used to enable additional sanity checks and "red zones" around
allocations to detect read/writes beyond the allocated area, as well as
poisoning to overwrite free'd data.
The cost is yet more memory fragmentation ...
For the hardened profile disable symmetric multi threading. There seems to be
no *proven* method of exploiting cache sharing between threads on the same CPU
core, so this may be considered quite paranoid, considering the perf cost.
SMT can be controlled at runtime, however. This is in keeping with OpenBSD
defaults.
TODO: since SMT is left to be controlled at runtime, changing the option
definition should take effect on system activation. Write to
/sys/devices/system/cpu/smt/control
For the hardened profile enable flushing whenever the hypervisor enters the
guest, but otherwise leave at kernel default (conditional flushing as of
writing).
Introduces the option security.protectKernelImage that is intended to control
various mitigations to protect the integrity of the running kernel
image (i.e., prevent replacing it without rebooting).
This makes sense as a dedicated module as it is otherwise somewhat difficult
to override for hardened profile users who want e.g., hibernation to work.
A module for security options that are too small to warrant their own module.
The impetus for adding this module is to make it more convenient to override
the behavior of the hardened profile wrt user namespaces.
Without a dedicated option for user namespaces, the user needs to
1) know which sysctl knob controls userns
2) know how large a value the sysctl knob needs to allow e.g.,
Nix sandbox builds to work
In the future, other mitigations currently enabled by the hardened profile may
be promoted to options in this module.
