This commit is contained in:
raja-grewal 2025-11-15 17:30:43 +11:00 committed by GitHub
commit 033f8ada74
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
4 changed files with 100 additions and 43 deletions

View file

@ -50,11 +50,12 @@ configuration file and significant hardening is applied to a myriad of component
and thwart certain kernel exploitation attempts) and kernel warnings in the `WARN()` path. and thwart certain kernel exploitation attempts) and kernel warnings in the `WARN()` path.
- Force immediate system reboot on the occurrence of a single kernel panic, reducing the - Force immediate system reboot on the occurrence of a single kernel panic, reducing the
risk and impact of denial of service attacks and both cold and warm boot attacks. risk and impact of denial-of-service attacks and both cold and warm boot attacks.
- Optional - Force immediate kernel panic on OOM. This is to avoid security features such as the screen - Optional - Force immediate kernel panic on OOM (out of memory) which with the above setting
locker, kloak, emerg-shutdown from being arbitrarily terminated when the system starts will force an immediate system reboot as opposed to placing any reliance on the oom_killer
running out of memory. to avoid arbitrarily terminating security features based on their OOM score. Note this
creates the risk of userspace-based denial-of-service attacks that maliciously fill memory.
- Disable the use of legacy TIOCSTI operations which can be used to inject keypresses. - Disable the use of legacy TIOCSTI operations which can be used to inject keypresses.
@ -218,10 +219,11 @@ Kernel space:
- Restrict access to debugfs by not registering the file system since it can - Restrict access to debugfs by not registering the file system since it can
contain sensitive information. contain sensitive information.
- Force kernel panics on "oopses" to potentially indicate and thwart certain - Force the kernel to immediately panic on both "oopses" (which can potentially indicate
kernel exploitation attempts. and thwart certain kernel exploitation attempts) and kernel warnings in the `WARN()` path.
- Optional - Modify the machine check exception handler. - Force immediate system reboot on the occurrence of a single kernel panic, reducing the
risk and impact of denial-of-service attacks and both cold and warm boot attacks.
- Prevent sensitive kernel information leaks in the console during boot. - Prevent sensitive kernel information leaks in the console during boot.
@ -248,12 +250,21 @@ Direct memory access:
Entropy: Entropy:
- Do not credit the CPU or bootloader as entropy sources at boot in order to - Do not credit the CPU seeds as an entropy sources at boot in order to maximize the
maximize the absolute quantity of entropy in the combined pool. absolute quantity of entropy in the combined pool. This is desirable for all
cryptographic operations reliant proprietary on RDRAND and RDSEED CPU instructions
for random number generation that have long history of being defective.
- Do not credit the bootloader seeds as an entropy sources at boot to maximize the
absolute quantity of entropy in the combined pool. This is desirable for all
cryptographic operations as seeds passed by the bootloader could be tampered.
- Obtain more entropy at boot from RAM as the runtime memory allocator is - Obtain more entropy at boot from RAM as the runtime memory allocator is
being initialized. being initialized.
- Obtain more entropy at boot from RAM as the runtime memory allocator is being
initialized to maximize the absolute quantity of entropy in the combined pool.
Networking: Networking:
- Optional - Disable the entire IPv6 stack to reduce attack surface. - Optional - Disable the entire IPv6 stack to reduce attack surface.
@ -295,6 +306,14 @@ feasible due to compatibility issues with Firefox.
* [security-misc pull request #249](https://github.com/Kicksecure/security-misc/pull/249) * [security-misc pull request #249](https://github.com/Kicksecure/security-misc/pull/249)
* [security-misc issue #267](https://github.com/Kicksecure/security-misc/issues/267) * [security-misc issue #267](https://github.com/Kicksecure/security-misc/issues/267)
3. Kernel boot parameter `hash_pointers=always`
Force all exposed pointers to be hashed and must be used in combination with the already enabled
`slab_debug=FZ` kernel boot parameter. Currently is not possible as requires Linux kernel >= 6.17.
* [security-misc issue #253](https://github.com/Kicksecure/security-misc/issues/253)
* [security-misc pull request #325](https://github.com/Kicksecure/security-misc/pull/325)
### Kernel Modules ### Kernel Modules
#### Kernel Module Signature Verification #### Kernel Module Signature Verification

View file

@ -38,13 +38,17 @@ kver="$(dpkg-query --show --showformat='${Version}' "$kpkg")" 2>/dev/null || tru
## ##
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX slab_nomerge" GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX slab_nomerge"
## Enable sanity checks and red zoning of slabs via debugging options to detect corruption. ## Enable sanity checks and red zoning of slabs via debugging options to detect memory corruption.
## Sanity checks force additional verification steps on every memory allocation and free operation.
## Red zoning adds extra metadata to each object to detect writes beyond the object's boundaries.
## As a by product of debugging, this will implicitly disabling kernel pointer hashing unless manually re-enabled. ## As a by product of debugging, this will implicitly disabling kernel pointer hashing unless manually re-enabled.
## Enabling this (for now) will therefore leak exact and all kernel memory addresses to root. ## Enabling this (for now) will therefore leak exact and all kernel memory addresses to root.
## Has the potential to cause a noticeable performance decrease. ## Introduces a noticeable performance overhead during all memory allocation and deallocation operations.
## ##
## https://www.kernel.org/doc/html/latest/mm/slub.html ## https://www.kernel.org/doc/html/latest/mm/slub.html
## https://www.kernel.org/doc/Documentation/vm/slub.txt
## https://lore.kernel.org/all/20210601182202.3011020-5-swboyd@chromium.org/T/#u ## https://lore.kernel.org/all/20210601182202.3011020-5-swboyd@chromium.org/T/#u
## https://blogs.oracle.com/linux/post/linux-slub-allocator-internals-and-debugging-2
## https://gitlab.tails.boum.org/tails/tails/-/issues/19613 ## https://gitlab.tails.boum.org/tails/tails/-/issues/19613
## https://github.com/Kicksecure/security-misc/issues/253 ## https://github.com/Kicksecure/security-misc/issues/253
## ##
@ -122,33 +126,40 @@ GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX vsyscall=none"
## ##
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX debugfs=off" GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX debugfs=off"
## Force the kernel to immediately panic on "oopses". ## Force the kernel to immediately panic on "oopses" and kernel warnings in the WARN() path.
## Panics may be due to false-positives such as bad drivers. ## Panics may be due to false-positives such as bad drivers.
## Both allowed limits are set to one so that panics occur on the single first instance of either scenario.
## Oopses are serious but non-fatal errors. ## Oopses are serious but non-fatal errors.
## Certain "oopses" can sometimes indicate and thwart potential kernel exploitation attempts. ## Certain "oopses" can sometimes indicate and thwart potential kernel exploitation attempts.
## Note that by forcing kernel panics on oopses, this exposes the system to targeted denial of service attacks. ## Warnings are messages generated by the kernel to indicate unexpected conditions or errors.
## By default, code execution continues regardless of warnings emitted by macros like WARN() and WARN_ON().
## Note that by forcing kernel panics on oopses and warnings, this exposes the system to targeted denial of service attacks.
## ##
## https://en.wikipedia.org/wiki/Kernel_panic#Linux ## https://en.wikipedia.org/wiki/Kernel_panic#Linux
## https://en.wikipedia.org/wiki/Linux_kernel_oops ## https://en.wikipedia.org/wiki/Linux_kernel_oops
## https://forums.whonix.org/t/set-oops-panic-kernel-parameter-or-kernel-panic-on-oops-1-sysctl-for-better-security/7713 ## https://lwn.net/Articles/876209/
## https://git.sr.ht/~gregkh/presentation-security/tree/3fdaf81a2f8b2c8d64cdb2f529cc714624868aa8/item/security-stuff.pdf
## https://forums.whonix.org/t/set-oops-panic-kernel-parameter-or-kernel-panisc-on-oops-1-sysctl-for-better-security/7713
## ##
## KSPP=yes ## KSPP=yes
## KSPP sets CONFIG_PANIC_ON_OOPS=y and CONFIG_PANIC_TIMEOUT=-1. ## KSPP sets CONFIG_PANIC_ON_OOPS=y.
## ##
## See /usr/libexec/security-misc/panic-on-oops for implementation. ## See /usr/libexec/security-misc/panic-on-oops for implementation.
## ##
#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX oops=panic" #GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX oops=panic"
#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX panic_on_warn=1"
## Modify machine check exception handler. ## Force immediate system reboots on the occurrence of a single kernel panic.
## Can decide whether the system should panic or not based on the occurrence of an exception. ## Increases resilience and limits impact of denial of service attacks as system automatically restarts.
## Ensures the system does not hang forever if a panic occurs, reducing susceptibility to both cold and warm boot attacks.
## Immediate rebooting also prevents persistent information disclosure on panic details that were dumped to screen.
## ##
## https://www.kernel.org/doc/html/latest/arch/x86/x86_64/machinecheck.html ## KSPP=yes
## https://www.kernel.org/doc/html/latest/arch/x86/x86_64/boot-options.html#machine-check ## KSPP sets CONFIG_PANIC_TIMEOUT=-1.
## https://forums.whonix.org/t/kernel-hardening/7296/494
## ##
## The default kernel setting will be utilized until provided sufficient evidence to modify. ## See /usr/libexec/security-misc/panic-on-oops for implementation.
## ##
#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX mce=0" #GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX panic=-1"
## Prevent sensitive kernel information leaks in the console during boot. ## Prevent sensitive kernel information leaks in the console during boot.
## Must be used in combination with the kernel.printk sysctl. ## Must be used in combination with the kernel.printk sysctl.
@ -282,32 +293,48 @@ GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX efi=disable_early_pci_dma"
## ##
## https://madaidans-insecurities.github.io/guides/linux-hardening.html#rdrand ## https://madaidans-insecurities.github.io/guides/linux-hardening.html#rdrand
## Do not credit the CPU or bootloader seeds as entropy sources at boot. ## Do not credit the CPU seeds as an entropy sources at boot.
## The RDRAND CPU (RNG) instructions are proprietary and closed-source. ## The RDRAND and RDSEED CPU (RNG) instructions are proprietary and closed-source.
## Numerous implementations of RDRAND have a long history of being defective. ## Numerous implementations of RDRAND and RDSEED have a long history of being defective.
## The RNG seed passed by the bootloader could also potentially be tampered.
## Maximizing the entropy pool at boot is desirable for all cryptographic operations. ## Maximizing the entropy pool at boot is desirable for all cryptographic operations.
## These settings ensure additional entropy is obtained from other sources to initialize the RNG. ## This ensures additional entropy is obtained from other sources to initialize the Linux CRNG.
## Note that distrusting these (relatively fast) sources of entropy will increase boot time. ## Note that distrusting this (relatively fast) source of entropy will increase boot time.
## ##
## https://en.wikipedia.org/wiki/RDRAND#Reception ## https://en.wikipedia.org/wiki/RDRAND
## https://systemd.io/RANDOM_SEEDS/ ## https://systemd.io/RANDOM_SEEDS/
## https://www.kicksecure.com/wiki/Dev/Entropy#RDRAND ## https://www.kicksecure.com/wiki/Dev/Entropy#RDRAND
## https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/
## https://x.com/pid_eins/status/1149649806056280069
## https://archive.nytimes.com/www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html ## https://archive.nytimes.com/www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html
## https://forums.whonix.org/t/entropy-config-random-trust-cpu-yes-or-no-rng-core-default-quality/8566 ## https://forums.whonix.org/t/entropy-config-random-trust-cpu-yes-or-no-rng-core-default-quality/8566
## https://lkml.org/lkml/2022/6/5/271
## https://lwn.net/Articles/961121/
## https://lore.kernel.org/lkml/aPFDn-4Cm6n0_3_e@gourry-fedora-PF4VCD3F/
## https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7055.html
##
## KSPP=yes
## KSPP sets CONFIG_RANDOM_TRUST_CPU=y.
##
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX random.trust_cpu=off"
## Do not credit the bootloader seeds as an entropy source at boot.
## The RNG seed passed by the bootloader could potentially be tampered.
## Maximizing the entropy pool at boot is desirable for all cryptographic operations.
## This ensures additional entropy is obtained from other sources to initialize the Linux CRNG.
## Note that distrusting this (relatively fast) source of entropy will increase boot time.
##
## https://systemd.io/RANDOM_SEEDS/
## https://github.com/NixOS/nixpkgs/pull/165355 ## https://github.com/NixOS/nixpkgs/pull/165355
## https://lkml.org/lkml/2022/6/5/271 ## https://lkml.org/lkml/2022/6/5/271
## ##
## KSPP=yes ## KSPP=yes
## KSPP sets CONFIG_RANDOM_TRUST_BOOTLOADER=y and CONFIG_RANDOM_TRUST_CPU=y. ## KSPP sets CONFIG_RANDOM_TRUST_BOOTLOADER=y.
## ##
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX random.trust_bootloader=off" GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX random.trust_bootloader=off"
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX random.trust_cpu=off"
## Obtain more entropy during boot as the runtime memory allocator is being initialized. ## Obtain more entropy during boot as the runtime memory allocator is being initialized.
## Entropy will be extracted from up to the first 4GB of RAM. ## Entropy will be extracted from up to the first 4GB of RAM as another source.
## Note that entropy extracted this way is not cryptographically secure and so is not credited.
## Maximizing the entropy pool at boot is desirable for all cryptographic operations.
## This will increase boot time due to interrupting the boot process.
## Requires the linux-hardened kernel patch. ## Requires the linux-hardened kernel patch.
## ##
## https://www.kicksecure.com/wiki/Hardened-kernel#linux-hardened ## https://www.kicksecure.com/wiki/Hardened-kernel#linux-hardened

View file

@ -171,7 +171,7 @@ kernel.perf_event_paranoid=3
## Certain "oopses" can sometimes indicate and thwart potential kernel exploitation attempts. ## Certain "oopses" can sometimes indicate and thwart potential kernel exploitation attempts.
## Warnings are messages generated by the kernel to indicate unexpected conditions or errors. ## Warnings are messages generated by the kernel to indicate unexpected conditions or errors.
## By default, code execution continues regardless of warnings emitted by macros like WARN() and WARN_ON(). ## By default, code execution continues regardless of warnings emitted by macros like WARN() and WARN_ON().
## Note that by forcing kernel panics on oopses and warnings, this exposes the system to targeted denial of service attacks. ## Note that by forcing kernel panics on oopses and warnings, this exposes the system to targeted denial-of-service attacks.
## ##
## https://en.wikipedia.org/wiki/Kernel_panic#Linux ## https://en.wikipedia.org/wiki/Kernel_panic#Linux
## https://en.wikipedia.org/wiki/Linux_kernel_oops ## https://en.wikipedia.org/wiki/Linux_kernel_oops
@ -188,7 +188,7 @@ kernel.perf_event_paranoid=3
#kernel.warn_limit=1 #kernel.warn_limit=1
## Force immediate system reboots on the occurrence of a single kernel panic. ## Force immediate system reboots on the occurrence of a single kernel panic.
## Increases resilience and limits impact of denial of service attacks as system automatically restarts. ## Increases resilience and limits impact of denial-of-service attacks as system automatically restarts.
## Ensures the system does not hang forever if a panic occurs, reducing susceptibility to both cold and warm boot attacks. ## Ensures the system does not hang forever if a panic occurs, reducing susceptibility to both cold and warm boot attacks.
## Immediate rebooting also prevents persistent information disclosure on panic details that were dumped to screen. ## Immediate rebooting also prevents persistent information disclosure on panic details that were dumped to screen.
## ##
@ -199,12 +199,20 @@ kernel.perf_event_paranoid=3
## ##
#kernel.panic=-1 #kernel.panic=-1
## Force immediate kernel panic on OOM. ## Force immediate kernel panic on OOM (out of memory) scenarios.
## This is to avoid security features such as the screen locker, kloak, emerg-shutdown ## Registers a kernel panic whenever the oom_killer is triggered to kill some rouge process based on their OOM score.
## from being arbitrarily terminated when the system starts running out of memory. ## This prevents security features such as the screen locker, kloak, and emerg-shutdown from being arbitrarily terminated.
## Enabling these two together creates a risk of userspace-based denial-of-service attacks that maliciously fill memory.
## This forces immediate system reboot rather than placing any reliance on the oom_killer.
## Known to cause extreme user experience problems with certain applications as the Tor Browser.
## Enabling by default requires improved upstream handling of user space OOM better accounting for desktop users.
##
## https://en.wikipedia.org/wiki/Out_of_memory
## https://forums.whonix.org/t/screen-locker-in-security-can-we-disable-these-at-least-4-backdoors/8128/14 ## https://forums.whonix.org/t/screen-locker-in-security-can-we-disable-these-at-least-4-backdoors/8128/14
## https://github.com/KSPP/kspp.github.io/issues/9
## https://github.com/Kicksecure/security-misc/issues/324 ## https://github.com/Kicksecure/security-misc/issues/324
## Needs more work. ##
## Note that this must be used with kernel.panic=-1 for it to function as intended.
## ##
#vm.panic_on_oom=2 #vm.panic_on_oom=2
@ -526,7 +534,7 @@ net.ipv6.conf.*.accept_source_route=0
## Do not accept IPv6 router advertisements (RAs) and solicitations. ## Do not accept IPv6 router advertisements (RAs) and solicitations.
## RAs are unsecured and unauthenticated and any device on the local link can send and accept them without verification. ## RAs are unsecured and unauthenticated and any device on the local link can send and accept them without verification.
## Malicious RAs can activate IPv6 connectivity on dormant hosts leading to unauthorized access. ## Malicious RAs can activate IPv6 connectivity on dormant hosts leading to unauthorized access.
## Flooding the network with malicious RAs can lead to denial of service attacks. ## Flooding the network with malicious RAs can lead to denial-of-service attacks.
## Rogue RAs can lead to interception of all network traffic by setting the attacker's system as the default gateway. ## Rogue RAs can lead to interception of all network traffic by setting the attacker's system as the default gateway.
## ##
## https://datatracker.ietf.org/doc/html/rfc6104 ## https://datatracker.ietf.org/doc/html/rfc6104
@ -572,6 +580,8 @@ net.ipv4.tcp_timestamps=0
## Known to cause performance issues, especially on systems with multiple interfaces. ## Known to cause performance issues, especially on systems with multiple interfaces.
## ##
## https://wiki.archlinux.org/title/Sysctl#Log_martian_packets ## https://wiki.archlinux.org/title/Sysctl#Log_martian_packets
## https://www.cyberciti.biz/faq/linux-log-suspicious-martian-packets-un-routable-source-addresses/
## https://support.scc.suse.com/s/kb/Martian-sources-errors-showing-in-messages-log?language=en_US
## https://github.com/Kicksecure/security-misc/issues/214 ## https://github.com/Kicksecure/security-misc/issues/214
## ##
## The logging of martian packets is currently disabled. ## The logging of martian packets is currently disabled.

View file

@ -24,7 +24,8 @@ sysctl kernel.oops_limit=1
sysctl kernel.warn_limit=1 sysctl kernel.warn_limit=1
## Makes the system immediately reboot on the occurrence of a single ## Makes the system immediately reboot on the occurrence of a single
## kernel panic. This reduces the risk and impact of denial of ## kernel panic. This reduces the risk and impact of denial-of-service
## service attacks and both cold and warm boot attacks. ## attacks and both cold and warm boot attacks.
##
## https://docs.kernel.org/admin-guide/sysctl/kernel.html#panic ## https://docs.kernel.org/admin-guide/sysctl/kernel.html#panic
sysctl kernel.panic=-1 sysctl kernel.panic=-1