Ich habe die obigen Konfigurationsdateien um die Vorschläge auf der Internetseite
https://madaidans-insecurities.github.i ... ening.html erweitert.
Die Einträge in der Datei
/etc/default/grub.d/01_hardening.cfg lauten bei mir nun:
Code: Alles auswählen
# Linux command line options recommended by the KSPP
# https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#kernel_command_line_options
# Modifiziert nach den Vorschlägen auf https://madaidans-insecurities.github.io/guides/linux-hardening.html zur Veröffentlichung auf https://debianforum.de/forum/
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT kaslr pti=on slab_nomerge page_poison=1
slub_debug=FPZ nosmt init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 vsyscall=none debugfs=off
oops=panic module.sig_enforce=1 lockdown=integrity lockdown=confidentiality mce=0 quiet loglevel=0
systemd.volatile=yes ipv6.disable=1"
# Other interesting options are:
# - intel_iommu=on (sometimes intel_iommu=on,igfx_off) for enabing I/OMMU
# When done editing the file, rebuild grub configuration with: update-grub
Der Einträge in der Datei
/usr/lib/sysctl.d/10-hardening.conf lauten bei mir nun:
Code: Alles auswählen
# sysctl recommended by the KSPP
# https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#sysctls
# Modifiziert nach den Vorschlägen auf https://madaidans-insecurities.github.io/guides/linux-hardening.html zur Veröffentlichung auf https://debianforum.de/forum/
# If all relevant modules have been loaded in the initramfs (by listing them in
# /etc/initramfs/modules and rebuilding the initramfs with update-initramfs,
# one can completely disable modules loading with:
# kernel.modules_disable=1
# KERNEL SELF-PROTECTION
# Try to keep kernel address exposures out of various /proc files (kallsyms, modules, etc).
kernel.kptr_restrict = 2
# Avoid kernel memory address exposures via dmesg.
kernel.dmesg_restrict = 1
# Despite the value of dmesg_restrict , the kernel log will still be displayed in the
# console during boot. Malware that is able to record the screen during boot may
# be able to abuse this to gain higher privileges. This option prevents those
# information leaks. This must be used in combination with certain boot
# parameters described below to be fully effective.
kernel.printk=3 3 3 3
# eBPF exposes quite large attack surface. As such, it must be restricted. These
# sysctls restrict eBPF to the CAP_BPF capability ( CAP_SYS_ADMIN on kernel
# versions prior to 5.8) and enable JIT hardening techniques, such as constant
# blinding.
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2
# This restricts loading TTY line disciplines to the CAP_SYS_MODULE capability to
# prevent unprivileged attackers from loading vulnerable line disciplines with the
# TIOCSETD ioctl which has been abused in a number of exploits before.
dev.tty.ldisc_autoload=0
# The userfaultfd() syscall is often abused to exploit use-after-free flaws. Due
# to this, this sysctl is used to restrict this syscall to the CAP_SYS_PTRACE
# capability.
vm.unprivileged_userfaultfd=0
# Turn off kexec, even if it's built in.
kernel.kexec_load_disabled = 1
# The SysRq key exposes a lot of potentially dangerous debugging functionality
# to unprivileged users. Contrary to common assumptions, SysRq is not only an
# issue for physical attacks as it can also be triggered remotely. The value of this
# sysctl makes it so that a user can only use the secure attention key which will
# be necessary for accessing root securely. Alternatively, you can simply set the
# value to 0 to disable SysRq completely.
kernel.sysrq=4
# User namespaces are a feature in the kernel which aim to improve sandboxing
# and make it easily accessible for unprivileged users however, this feature
# exposes significant kernel attack surface for privilege escalation so this sysctl
# restricts the usage of user namespaces to the CAP_SYS_ADMIN capability. For
# unprivileged sandboxing, it is instead recommended to use a setuid binary with
# little attack surface to minimise the potential for privilege escalation. This topic
# is covered further in the sandboxing section.
# Be aware though that this sysctl only exists on certain Linux distributions as it
# requires a kernel patch. If your kernel does not include this patch, you can
# alternatively disable user namespaces completely (including for root) by setting
# user.max_user_namespaces=0.
kernel.unprivileged_userns_clone=0
user.max_user_namespaces=0
# Block non-uid-0 profiling (needs distro patch, otherwise this is the same as "= 2")
kernel.perf_event_paranoid = 3
# NETWORK
# USER SPACE
# ptrace is a system call that allows a program to alter and inspect another
# running process which allows attackers to trivially modify the memory of other
# running programs. This restricts usage of ptrace to only processes with the
# CAP_SYS_PTRACE capability. Alternatively, set the sysctl to 3 to disable ptrace
# entirely.
# 1: Avoid non-ancestor ptrace access to running processes and their credentials.
# 2: Restrict ptrace access to processes with CAP_SYS_PTRACE
# 3: Completely disable ptrace
kernel.yama.ptrace_scope=2
# On x86_64 this adds some bits to userspace ASLR
vm.mmap_rnd_bits=32
vm.mmap_rnd_compat_bits=16
# This only permits symlinks to be followed when outside of a world-writable
# sticky directory, when the owner of the symlink and follower match, or when the
# directory owner matches the symlink's owner. This also prevents hardlinks
# from being created by users that do not have read/write access to the source
# file. Both of these prevent many common TOCTOU races.
fs.protected_symlinks=1
fs.protected_hardlinks=1
# These prevent creating files in potentially attacker-controlled environments,
# such as world-writable directories, to make data spoofing attacks more difficult.
fs.protected_fifos=2
fs.protected_regular=2
Hinsichtlich der Einträge in
/etc/default/grub.d/01_hardening.cfg stellte ich fest, dass sie eventuell mit (doppelten?) Einträgen in
/etc/default/grub in der Zeile
GRUB_CMDLINE_LINUX_DEFAULT="" konfligieren. Einige von mir gesetzten Einträge in
/etc/default/grub wurden nach Systemstart vom System plötzlich nicht mehr umgesetzt, was ich erfuhr über die Ausgabe von:
Ich habe mich daher - auch der Übersichtlichkeit halber - dazu entschieden, alle Kernel-Boot-Paraemter in
/etc/default/grub.d/01_hardening.cfg und nicht mehr in
/etc/default/grubeinzutragen.
Bei den Vorschlägen auf der obigen Internetseite zu Einträgen in
/usr/lib/sysctl.d/10-hardening.conf zur Härtung der Netzwerkeinstellungen habe ich mich zurückgehalten, da ich ausschließlich über virtuelle Maschinen das Internet benutze und auf dem Host vorerst alles bei den automatischen Voreinstellungen durch Debian bzw durch die installierten Pakete für qemu/kvm belasse. Letztere Komplexitätsschicht lässt vermutlich nicht zu, die vorgeschlagenen Konfigurationseinträge einfach per Copy&Paste in die Konfigurationsdatei zu übernehmen.
@mcb
Danke für den Tip
@fossonly
Ok, ich muss dann noch herausfinden, welche Änderungen genau der durch secure boot aktivierte kernel-lockdown bzw die Einträge
lockdown={integrity|confidentiality} und
systemd.volatile=yes am Linux-System vornehmen.
Wie ich Dich verstanden habe, werden meine individuell und manuell gesetzten Einträge - die stringenter sein können - möglicherweise durch weniger strenge Parameter - gesetzt durch secure boot bzw.
lockdown={integrity|confidentiality} und/oder
systemd.volatile=yes - lediglich verdrängt (oder umgekehrt). Soweit es derart klar hierarchisch bleibt und keine schwereren Konflikte eintreten können, kann ich damit leben, bis ich mehr weiß. In allen Fällen bliebe das System nämlich gehärtet.
Zumindest was die Modifizierungen durch das Paket
hardening-runtime angeht, vertraue ich darauf, dass der Maintainer um diese möglichen Hierarchiekonflikte - insbesondere bei eingeschaltetem secure boot - weiß.