mirror of
https://github.com/Kicksecure/security-misc.git
synced 2025-11-25 12:56:23 -05:00
Merge 29176d2ed2 into d267cf6761
This commit is contained in:
raja-grewal
GitHub
commit
033f8ada74
4 changed files with 100 additions and 43 deletions
37
README.md
37
README.md
|
|
@ -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.
|
||||
|
||||
- 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
|
||||
locker, kloak, emerg-shutdown from being arbitrarily terminated when the system starts
|
||||
running out of memory.
|
||||
- Optional - Force immediate kernel panic on OOM (out of memory) which with the above setting
|
||||
will force an immediate system reboot as opposed to placing any reliance on the oom_killer
|
||||
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.
|
||||
|
||||
|
|
@ -218,10 +219,11 @@ Kernel space:
|
|||
- Restrict access to debugfs by not registering the file system since it can
|
||||
contain sensitive information.
|
||||
|
||||
- Force kernel panics on "oopses" to potentially indicate and thwart certain
|
||||
kernel exploitation attempts.
|
||||
- Force the kernel to immediately panic on both "oopses" (which can potentially indicate
|
||||
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.
|
||||
|
||||
|
|
@ -248,12 +250,21 @@ Direct memory access:
|
|||
|
||||
Entropy:
|
||||
|
||||
- Do not credit the CPU or bootloader as entropy sources at boot in order to
|
||||
maximize the absolute quantity of entropy in the combined pool.
|
||||
- Do not credit the CPU seeds as an entropy sources at boot in order to maximize the
|
||||
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
|
||||
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:
|
||||
|
||||
- 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 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 Module Signature Verification
|
||||
|
|
|
|||
|
|
@ -38,13 +38,17 @@ kver="$(dpkg-query --show --showformat='${Version}' "$kpkg")" 2>/dev/null || tru
|
|||
##
|
||||
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.
|
||||
## 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/Documentation/vm/slub.txt
|
||||
## 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://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"
|
||||
|
||||
## 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.
|
||||
## 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.
|
||||
## 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/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 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.
|
||||
##
|
||||
#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX oops=panic"
|
||||
#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX panic_on_warn=1"
|
||||
|
||||
## Modify machine check exception handler.
|
||||
## Can decide whether the system should panic or not based on the occurrence of an exception.
|
||||
## 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.
|
||||
## 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
|
||||
## https://www.kernel.org/doc/html/latest/arch/x86/x86_64/boot-options.html#machine-check
|
||||
## https://forums.whonix.org/t/kernel-hardening/7296/494
|
||||
## KSPP=yes
|
||||
## KSPP sets CONFIG_PANIC_TIMEOUT=-1.
|
||||
##
|
||||
## 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.
|
||||
## 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
|
||||
|
||||
## Do not credit the CPU or bootloader seeds as entropy sources at boot.
|
||||
## The RDRAND CPU (RNG) instructions are proprietary and closed-source.
|
||||
## Numerous implementations of RDRAND have a long history of being defective.
|
||||
## The RNG seed passed by the bootloader could also potentially be tampered.
|
||||
## Do not credit the CPU seeds as an entropy sources at boot.
|
||||
## The RDRAND and RDSEED CPU (RNG) instructions are proprietary and closed-source.
|
||||
## Numerous implementations of RDRAND and RDSEED have a long history of being defective.
|
||||
## 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.
|
||||
## Note that distrusting these (relatively fast) sources of entropy will increase boot time.
|
||||
## 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://en.wikipedia.org/wiki/RDRAND#Reception
|
||||
## https://en.wikipedia.org/wiki/RDRAND
|
||||
## https://systemd.io/RANDOM_SEEDS/
|
||||
## 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://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://lkml.org/lkml/2022/6/5/271
|
||||
##
|
||||
## 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_cpu=off"
|
||||
|
||||
## 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.
|
||||
##
|
||||
## https://www.kicksecure.com/wiki/Hardened-kernel#linux-hardened
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ kernel.perf_event_paranoid=3
|
|||
## Certain "oopses" can sometimes indicate and thwart potential kernel exploitation attempts.
|
||||
## 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.
|
||||
## 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/Linux_kernel_oops
|
||||
|
|
@ -188,7 +188,7 @@ kernel.perf_event_paranoid=3
|
|||
#kernel.warn_limit=1
|
||||
|
||||
## 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.
|
||||
## 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
|
||||
|
||||
## Force immediate kernel panic on OOM.
|
||||
## This is to avoid security features such as the screen locker, kloak, emerg-shutdown
|
||||
## from being arbitrarily terminated when the system starts running out of memory.
|
||||
## Force immediate kernel panic on OOM (out of memory) scenarios.
|
||||
## Registers a kernel panic whenever the oom_killer is triggered to kill some rouge process based on their OOM score.
|
||||
## 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://github.com/KSPP/kspp.github.io/issues/9
|
||||
## 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
|
||||
|
||||
|
|
@ -526,7 +534,7 @@ net.ipv6.conf.*.accept_source_route=0
|
|||
## 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.
|
||||
## 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.
|
||||
##
|
||||
## 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.
|
||||
##
|
||||
## 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
|
||||
##
|
||||
## The logging of martian packets is currently disabled.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,8 @@ sysctl kernel.oops_limit=1
|
|||
sysctl kernel.warn_limit=1
|
||||
|
||||
## Makes the system immediately reboot on the occurrence of a single
|
||||
## kernel panic. This reduces the risk and impact of denial of
|
||||
## service attacks and both cold and warm boot attacks.
|
||||
## kernel panic. This reduces the risk and impact of denial-of-service
|
||||
## attacks and both cold and warm boot attacks.
|
||||
##
|
||||
## https://docs.kernel.org/admin-guide/sysctl/kernel.html#panic
|
||||
sysctl kernel.panic=-1
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue