Kernel Hardening - security-misc

Patrick · October 10, 2025, 10:49am

Docs detailing future improvements to `slab_debug`

master ← raja-grewal:hash_pointers

opened 02:43AM - 08 Oct 25 UTC

This pull request adds details about future improvements to the current flaws of… `slab_debug` discussed in https://github.com/Kicksecure/security-misc/issues/253#issuecomment-3376730611. ## Changes There are no changes to the functionality of the codebase. ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

Patrick · October 10, 2025, 12:17pm

Patrick · October 13, 2025, 2:07pm

github.com/Kicksecure/security-misc

Provide more useful comments

master ← colleirose:comments

opened 07:29PM - 09 Oct 25 UTC

colleirose

+53 -40

## Changes This provides more useful and up-to-date comments for some options, …and only disables SMT in three different areas to make it simpler to remove if desired (`mitigations=auto,nosmt`, `nosmt=force`, `l1tf=full,force`). ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [ ] I have tested it locally - [ ] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

Patrick · October 19, 2025, 8:16am

github.com/Kicksecure/security-misc

enable Kernel Lockdown Mode / `lockdown=confidentiality` / `echo confidentiality > /sys/kernel/security/lockdown`

opened 08:16AM - 19 Oct 25 UTC

adrelanos

Reason why the kernel parameter `lockdown=confidentiality` got disabled in the p…ast: @adrelanos > Have to disable kernel lockdown. Unfortunately. Because that enforces kernel module signature verification. Which we don’t have yet. Should we be enabling kernel lockdown during the boot process? After the kernel modules (tirdad; VirtualBox guest additions, if applicable) have been load, we could enable lockdown mode. Thanks to @ArrayBolt3 for suggesting this! ---- How to enable lockdown mode during the boot process? Requires root. echo confidentiality > /sys/kernel/security/lockdown ---- How does that work? cat /sys/kernel/security/lockdown > [none] integrity confidentiality Kernel boots with `lockdown` mode `none`. Let's enable `lockdown=confidentiality`. echo confidentiality > /sys/kernel/security/lockdown Done. Let's see if that worked. cat /sys/kernel/security/lockdown > confidentiality Yes, `lockdown=confidentiality` has been enabled. Once enabled, it cannot be reset, see: echo none > /sys/kernel/security/lockdown > echo: write error: operation not permitted > zsh: exit 1 ---- older discussions: * https://forums.whonix.org/t/kernel-hardening-security-misc/7296/315 * https://forums.whonix.org/t/activating-lockdown/18740 related: * https://forums.whonix.org/t/enforce-kernel-module-software-signature-verification-module-signing-disallow-kernel-module-loading-by-default/7880 ---- todo: * APT trigger to point out that unsigned kernel modules which have been updated cannot be re-load without a reboot * `needrestart` would be great in theory but had LPE (https://forums.whonix.org/t/add-package-needrestart/19078)

Patrick · November 2, 2025, 11:44am

Patrick · December 4, 2025, 10:48am

github.com/Kicksecure/security-misc

Should disabled kernel modules (`modprobe`) exit error (non-zero) or exit success (zero)?

opened 07:20AM - 14 Mar 25 UTC

closed 09:26AM - 15 Mar 25 UTC

adrelanos

[Quote](https://forums.whonix.org/t/systemcheck-fails-for-unclear-reason/21424/1…5) @marmarek: > As for Intel PMT, when looking at bigger context, it actually looks like intentional error: > > ``` > [2025-03-12 21:38:51] [ 3.358990] systemd-udevd[408]: /usr/bin/disabled-intelpmt-by-security-misc: ALERT: This Intel Platform Monitoring Technology (PMT) Telemetry kernel module is disabled by package security-misc by default. See the configuration file /etc/modprobe.d/30_security-misc_disable.conf for details. | args: > [2025-03-12 21:38:51] [ 3.359266] systemd-udevd[409]: /usr/bin/disabled-intelpmt-by-security-misc: ALERT: This Intel Platform Monitoring Technology (PMT) Telemetry kernel module is disabled by package security-misc by default. See the configuration file /etc/modprobe.d/30_security-misc_disable.conf for details. | args: > [2025-03-12 21:38:51] [ 3.359879] (udev-worker)[351]: Error running install command '/usr/bin/disabled-intelpmt-by-security-misc' for module pmt_class: retcode 1 > [2025-03-12 21:38:51] [ 3.360172] (udev-worker)[342]: Error running install command '/usr/bin/disabled-intelpmt-by-security-misc' for module pmt_class: retcode 1 > ``` > > Is `exit 1` in `/usr/bin/disabled-firewire-by-security-misc` actually needed? Man page of `modprobe.conf` says the install command is run instead of loading the module, so it looks like exit 1 isn’t needed to prevent loading. Or is the intention to have modprobe exit with 1 too? [...] I guess the intention of `exit 1` (error) was to make these failures obvious failing closed rather than failing non-obvious and open?

github.com/Kicksecure/security-misc

Disable support for all 32-bit x86 processes and syscalls?

opened 03:09AM - 16 Aug 25 UTC

closed 02:15PM - 20 Aug 25 UTC

raja-grewal

Now that Debian 13 has been released and the port to it is in the works, there i…s new area of hardening that is now possible thanks to upgrading to Linux kernel 6.12. In Linux kernel 6.7 the option to disable support for all 32-bit x86 processes and syscalls was provided via the kernel boot parameter `ia32_emulation=0`, see the provided option in the GRUB [configs](https://github.com/Kicksecure/security-misc/blob/master/etc/default/grub.d/40_kernel_hardening.cfg). Other distributions have dropped direct support for this architecture including now Debian 13. Many distributions do not provide 32-bit multilib packages by default and others are every now and then proposing to stop packaging them all together. See for example the recent Fedora [proposal](https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support-system-wide/156324) and [withdrawal](https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support-system-wide/156324/400). On any sort of modern architecture, 32-bit processes and syscalls require emulation and the kernel parameter allows us to outright disable them. Next, as far as I can tell, the only commonly cited use case of this support is gaming and emulation. These includes programs such as Steam, Proton, and WINE. There is also the often cited use case of "legacy" applications but I am unaware of any specific examples with broadspread use. The question is then how many users of Kicksecure/Whonix are using it to play video games? I would guess not that many. If there are some, they can undo the config while the everyone else benefits by default with a substantial attack surface reduction. Therefore, given our security hardening focus, should we consider disabling 32-bit x86 support by default? Note doing this would also bring us into compliance with KSPP recommendations.

github.com/Kicksecure/security-misc

Force disable usage of `ptrace()` until reboot / Increase `kernel.yama.ptrace_scope`: `2` → `3`

opened 03:06AM - 28 Sep 25 UTC

closed 07:38AM - 19 Oct 25 UTC

raja-grewal

Given the large amounts of new security hardening settings that are being incorp…orated into the upcoming Debian 13 port, there is another `sysctl` setting we should consider revisiting for two reasons, one to reopen the discussion, and two in order to adhere to KSPP requirements. This is again regarding the use use of process trace `ptrace()` which is currently set to `kernel.yama.ptrace_scope=2` inside the [configs](https://github.com/Kicksecure/security-misc/blob/master/usr/lib/sysctl.d/990-security-misc.conf%23security-misc-shared). As per the kernel [docs](https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html#ptrace-scope) I previously proposed increasing this to the KSPP recommenced `kernel.yama.ptrace_scope=3` in https://github.com/Kicksecure/security-misc/pull/242 but we decided to keep it as is since it was at the time considered outside the scope of security-misc. The question is whether the same logic still hold now over 15 months later? Note that several other projects focused on security hardening such as [Brace](https://github.com/divestedcg/Brace/blob/master/brace/usr/lib/sysctl.d/60-restrict.conf), [nix-mineral](https://github.com/cynicsketch/nix-mineral/blob/main/nix-mineral.nix), and [secureblue](https://github.com/secureblue/secureblue/blob/live/files/system/etc/sysctl.d/60-hardening.conf) all utilise the strictest setting by default. Just like we decided in https://github.com/Kicksecure/security-misc/pull/313 to enable `kernel.panic=-1` forcing instant reboots when previously we allowed the system to hang forever, maybe we should also consider tightening up this loose bolt? I am happy to submit a draft PR if there are no objections. @adrelanos @ArrayBolt3

github.com/Kicksecure/security-misc

Update various docs

master ← raja-grewal:docs

opened 01:44AM - 19 Oct 25 UTC

raja-grewal

+100 -43

This pull request improves documentation around several pre-existing areas. T…he update on the not credited nature of `extra_latent_entropy` was thanks to https://github.com/Kicksecure/security-misc/pull/326. ## Changes There are no changes to the functionality of the codebase. ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Add another method to disable 32-bit legacy vsyscalls

master ← raja-grewal:vsyscall32

opened 06:20AM - 02 Nov 25 UTC

raja-grewal

+18 -0

This pull request adds another method to disable 32-bit legacy vsyscalls. This i…s done purely as a form of defence-in-depth on top of https://github.com/Kicksecure/security-misc/pull/260. As per suggested in https://github.com/Kicksecure/security-misc/issues/329. ## Changes Set `sysctl abi.vsyscall32=0` ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Restrict processes from modifying their own memory mappings

master ← raja-grewal:limit_full_force

opened 12:53AM - 03 Nov 25 UTC

raja-grewal

+16 -0

This pull request restrict processes from modifying their own memory mappings un…less actively done via `ptrace()` in order to limit self-modification which can trigger exploits. As per suggested in https://github.com/Kicksecure/security-misc/issues/330. Note that this can be futher hardened by never allowing overrides using `proc_mem.force_override=never` instead. ## Changes Set the `proc_mem.force_override=ptrace` kernel boot parameter. ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Force enable PTI on ARM64 CPUs

master ← raja-grewal:kpti

opened 04:44AM - 03 Nov 25 UTC

raja-grewal

+22 -4

This pull request force enables PTI of user and kernel address spaces on ARM64 C…PUs mitigating the Meltdown vulnerability. This was previously missed as the already used `pti=on` parameter only applies to X86_64 CPUs. See the kernel [docs](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) for details. In various other areas documentation has been approved making the applicability to different architectures clearer. ## Changes Set the `kpti=1` kernel boot parameter. Update documentation in other areas relating to ARM64. ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Prevent runaway privileged processes from writing to block devices

master ← raja-grewal:limit_bdev_writes

opened 05:50AM - 03 Nov 25 UTC

raja-grewal

+15 -0

This pull request prevents processes from writing to block devices that are moun…ted by filesystems to protect against runaway privileged processes causing filesystem corruption and kernel crashes. Credit to the [kernel-hardening-checker](https://github.com/a13xp0p0v/kernel-hardening-checker) tool for bringing this to my attention. Note this is also now only possible using Debian 13 and so should be included in our upcoming port. ## Changes Set the `bdev_allow_write_mounted=0` kernel boot parameter. ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Disable reuse of `TIME_WAIT` sockets

master ← raja-grewal:stop_tw_reuse

opened 06:17AM - 10 Nov 25 UTC

raja-grewal

+13 -0

This pull request disable reuse of `TIME_WAIT` sockets for new outgoing connecti…ons as the safety of this feature is reliant on TCP timestamps which we have disabled. TCP timestamps have been disabled since 01/04/2016 as per https://github.com/Kicksecure/security-misc/pull/1, that is, the very first pull request or issue on GitHub. Note that this setting currently defaults to `net.ipv4.tcp_tw_reuse=2` which permits reuse only for loopback connections. This is still broken as there are no associated timestamps to ensure the new connection is not a duplicate segment from an older connection. ## Changes Set `sysctl net.ipv4.tcp_tw_reuse=0` setting. ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Provide the option to panic upon receiving NMIs

master ← raja-grewal:panic_nmi

opened 11:44AM - 11 Nov 25 UTC

raja-grewal

+25 -0

This pull request provide the option to panic upon receiving NMIs. All three …must first be tested to ensure there are no pre-existing issues on user hardware. After confirming stability of each they can then be used and prevent data corruption from hardware sources. These are valuable for high-reliability systems where data integrity is critical. Given this is a comment-only PR, I do not see anything controversial with this as all it does is tell users that such a feature is available if they are first willing to test there are no problems prior to them being used as hardening features. Please see references inside the commits and also the kernel [docs](https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html). ## Changes There are no changes to the functionality of the codebase. Provide the disabled by default options: ``` kernel.panic_on_io_nmi=1 kernel.panic_on_unrecovered_nmi=1 kernel.unknown_nmi_panic=1 ``` ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Provide the option to enable AMD SME and SEV

master ← raja-grewal:amd_encrypt_ram

opened 03:21AM - 15 Nov 25 UTC

raja-grewal

+25 -0

This pull request provides the options to enable AMD Secure Memory Encryption (S…ME) and Secure Encrypted Virtualization (SEV). For users running compatible AMD CPUs, SME allow them to enable hardware-based encryption of physical memory to protect against cold boot attacks. Then for users who also have SEV functionality, this also extend SME to VMs by encrypting the memory of each with a unique key for guest isolation. These are both generally features of professional and server CPUs. Users of consumer-grade AMD CPUs can generally instead enable TSME in their BIOS/UEFI to achieve the same protection as SME. Note that this was enabled by default prior to kernel 5.15 but was disabled due to issues relating to DMA masks and IOMMU this can cause boot failure on certain hardware. Hence, these are included here also disabled by default and require users to test themselves prior to enabling. Please see references inside the commits and also the kernel [docs](https://www.kernel.org/doc/html/next/x86/amd-memory-encryption.html). ## Changes There are no changes to the functionality of the codebase. Provide the disabled by default options: ``` mem_encrypt=on kvm_amd.sev=1 ``` ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Re-enable the Logging of Martian Packets

master ← raja-grewal:log_martians

opened 04:56AM - 11 Nov 25 UTC

raja-grewal

+3 -3

This pull request re-enables the logging of martian packets Currently a draft… PR as per https://github.com/Kicksecure/security-misc/issues/214#issuecomment-3509646182. ## Changes Re-sets `sysctl net.ipv4.conf.*.log_martians=1` setting. ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Provide the option to panic upon the kernel becoming tainted

master ← raja-grewal:panic_taint

opened 01:18AM - 19 Nov 25 UTC

raja-grewal

+24 -0

This pull request provides the option to panic upon the kernel becoming tainted.… After first testing, this can be used to enforce strict user-defined kernel operation and security at runtime. The exact subset selected is up to the user but in the presented default I have included panicking upon using out of specification hardware, bad page states, severe firmware bugs, and kernel live patching. Given this is a comment-only PR, I do not see anything controversial with this as all it does is tell users that such a feature is available if they are first willing to test there are no problems prior to them being used as hardening features. Please see references inside the commits and also the kernel [docs](https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html). ## Changes There are no changes to the functionality of the codebase. Provide the disabled by default option: ``` panic_on_taint=0x8824 ``` ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

github.com/Kicksecure/security-misc

Refresh `/etc/modprobe.d/*` blacklisting and disabling

master ← raja-grewal:modprobe_refresh

opened 01:55PM - 21 Nov 25 UTC

raja-grewal

+93 -54

This pull request updates our list of blacklisted and disabled kernel modules. … The last major updates were done by us around July 2024 in https://github.com/Kicksecure/security-misc/pull/230, https://github.com/Kicksecure/security-misc/pull/232, https://github.com/Kicksecure/security-misc/pull/234, https://github.com/Kicksecure/security-misc/pull/236, https://github.com/Kicksecure/security-misc/pull/237, https://github.com/Kicksecure/security-misc/pull/238, and https://github.com/Kicksecure/security-misc/pull/245. There were also numerous updates by others not using the GitHub PR system and so harder to link. This current refresh updates documentation, relocates a few things under better headings, moves some modules from blacklisted to disabled, and adds more disabled modules. The biggest change is incorporating more disabled file systems form secureblue's [config](https://github.com/secureblue/secureblue/blob/live/files/system/usr/lib/modprobe.d/secureblue.conf). These have all been used for a lengthy period sometime and so should be considered free of any obvious breakages. ## Changes Primarily disables more uncommon and legacy file systems. ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

Patrick · February 15, 2026, 1:26pm

bdev_allow_write_mounted=0 revert?

github.com/Kicksecure/security-misc

Comment by ArrayBolt3 - Prevent runaway privileged processes from writing to block devices

master ← raja-grewal:limit_bdev_writes

@raja-grewal, @adrelanos This option renders it impossible to mount NTFS volumes… at least when using the `mount` command. By default, this uses the ntfs-3g FUSE driver, but this option prevents that driver from working since now a userspace application has to write to a block device the system sees as mounted. This means that if one does `sudo mkfs.ntfs -Q /dev/sda1`, then `sudo mount /dev/sda1 /mnt`, the mount command will fail with a "Device or resource busy" error. Removing this option from the kernel command line configuration resolves the issue. This has also caused problems with zerofree, and telling users how to disable it has proven rather tricky in at least one situation. See https://forums.whonix.org/t/how-to-compress-and-prevent-vdi-from-ballooning-after-each-update-deleting-large-files/22675/9 and the conversation below. Since this provides no theoretical security enhancements in most situations (as explained above), and runaway root processes are likely rare, I think this should be reverted. Edit: This seems to also be causing some issues with fwupd, with messages like `Feb 12 10:56:36 host fwupd[8963]: 10:56:36.047 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:0d.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1: failed to subclass open: failed to open /dev/sda1: Device or resource busy`.

Patrick · February 17, 2026, 4:04pm

github.com/Kicksecure/security-misc

Add CD-ROM/DVD hardening settings

master ← raja-grewal:cdrom

opened 07:43AM - 17 Feb 26 UTC

raja-grewal

+42 -0

This pull request adds CD-ROM/DVD hardening `sysctl` settings As discussed i…n https://github.com/Kicksecure/security-misc/issues/348. ## Changes Sets the following `sysctl` settings: ``` dev.cdrom.autoclose=0 dev.cdrom.autoeject=0 dev.cdrom.debug=0 ``` Provides the following optional `sysctl` settings: ``` dev.cdrom.check_media=0 dev.cdrom.lock=1 ``` ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [x] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

Patrick · February 23, 2026, 11:25am

github.com/Kicksecure/security-misc

CDROM Hardening and User Experience

opened 10:57PM - 08 Feb 26 UTC

BasiruAbdul1992

Can we as in Kicksecure have CDROM hardening while still keeping user functional…ity of CD/DVD Drives? \ I want to propose that we reevaluate or look into the handling of CD/DVD's in Kicksecure for users. Example of a drop in: `/etc/sysctl.d/99-cdrom-controls.conf`: ``` ## CDROM controls # Disable auto-close dev.cdrom.autoclose=0 # Disable auto-eject dev.cdrom.autoeject=0 # Locks the CD-ROM tray against being opened via the hardware button - UNCOMMENT ONLY IF NEEDED #dev.cdrom.lock = 1 # Disable CDROM debuging dev.cdrom.debug=0 ``` --- `dev.cdrom.autoclose=0` # Default is 1 (enabled) > Disables automatic tray closure after media access, prevents scripted tray cycling attacks or unexpected behavior in automated environments. This one alone I feel is a must when having them enabled for two reasons I have experienced. Pressure load if users cd_rom is using more watts then their rated PSU is rated for (example: Power Supply rated for 1000 wats but setup with CD tray is more then there setup) leads to autoclose of drive. `dev.cdrom.autoeject=0` > Ensures tray doesn't auto-eject on media removal/unmount, avoids physical DoS via repeated ejects. `dev.cdrom.debug=0` > Prevents verbose logging that could leak drive info or aid reconnaissance. I see none set in the drop in files: > https://github.com/Kicksecure/security-misc/tree/master/usr/lib/sysctl.d Normally I have only seen cdrom being used not sr_mod due to usage on legacy desktops or laptops that have one built in. Maybe just disabling autoclose, autoeject, and debug via systctl.d would be sufficient enough rather then blacklist the full functionality. --- Basically what would be best for CDROM handling is: - No auto-eject/close - Read/Write data access with secure mount - No desktop interference popups - Physical button eject working at hardware/firmware level --- ## Wanted outcome Still have CD/DVD drive functionality in Kicksecure since DVD-R remains the best option for users who need "Read Only" functionality for security with the Tailored Access/Supply Chain Threat Model. > CD/DVD-R are available world wide in person in stores (though future trends may or may not move away, heading towards legacy media) > SD cards write protect switch does not fully provide protection > Once data is burned to DVD/CD-R media it is Read Only (not RW) > Provides a way for users to store LUKS Headers, Private Keys, or Password Manager key files for authentication/unlocking on CD/DVD. --- ### Middle ground: - Keep blacklist for cdrom/sr_mod - Disable autoclose, autoeject, and debug for CD/DVD drives - Provide plugin in sysmaint panel that comments or uncomments the line in the GUI --- Notes for checking: ```shell ls /proc/sys/dev/cdrom/ ``` ```shell sysctl -a | grep cdrom ```

Patrick · March 29, 2026, 3:42pm

github.com/Kicksecure/security-misc

Consider disabling syncookies

opened 03:38PM - 29 Mar 26 UTC

ArrayBolt3

`/usr/lib/sysctl.d/990-security-misc.conf#security-misc-shared` currently has th…is: ``` ## Enable TCP SYN cookie protection to assist against SYN flood attacks. ## ## https://en.wikipedia.org/wiki/SYN_flood ## https://cateee.net/lkddb/web-lkddb/SYN_COOKIES.html ## ## KSPP=yes ## KSPP sets CONFIG_SYN_COOKIES=y. ## net.ipv4.tcp_syncookies=1 ``` Syncookies rely on [embedding special information](https://en.wikipedia.org/wiki/SYN_cookies) into into a TCP initial sequence number, which [tirdad](https://github.com/Kicksecure/tirdad) completely destroys.

Patrick · April 9, 2026, 12:18pm

github.com/Kicksecure/security-misc

Make bdev_allow_write_mounted kernel parameter optional

master ← assisted-by-ai:claude/comment-bdev-allow-write-aYEla

opened 12:10PM - 09 Apr 26 UTC

assisted-by-ai

+9 -3

## Summary This change makes the `bdev_allow_write_mounted=0` kernel hardening …parameter optional by commenting it out in the default GRUB configuration, while updating documentation to reflect potential compatibility issues. ## Key Changes - Commented out the `bdev_allow_write_mounted=0` kernel parameter in `etc/default/grub.d/40_kernel_hardening.cfg` - Added references to related discussions documenting issues with disk management operations - Updated README.md to clarify that this is an optional hardening measure - Added documentation of known breakages with disk resizing and VDI compaction in virtual machines ## Details The `bdev_allow_write_mounted=0` parameter prevents privileged processes from writing to mounted block devices, protecting against filesystem corruption and kernel crashes. However, this parameter can interfere with legitimate disk management operations such as: - Disk resizing in virtual machines - VDI compaction operations By making this parameter optional (disabled by default), users can choose to enable it based on their security requirements and use case compatibility. The documentation now clearly indicates this is an optional hardening feature with potential operational trade-offs. * https://github.com/Kicksecure/security-misc/pull/334 https://claude.ai/code/session_01Cd9ka8sC7zLUvB31V4kxMk

Patrick · April 9, 2026, 1:39pm

github.com/Kicksecure/security-misc

Update README with comprehensive documentation improvements

master ← assisted-by-ai:claude/audit-readme-docs-YaAJV

opened 01:38PM - 09 Apr 26 UTC

assisted-by-ai

+162 -27

## Summary This PR updates the README.md documentation to reflect recent implem…entation changes, add missing feature documentation, and improve clarity on various security hardening features. ## Key Changes ### Documentation Updates - Marked Speculative Return Stack Overflow (SRSO) mitigation as optional - Added comprehensive documentation for kernel console output suppression during boot - Added documentation for recovery mode restrictions - Expanded Bluetooth configuration details with specific settings and rationale - Added detailed faillock configuration documentation with specific parameters - Updated SSH client/server hardening descriptions with specific cryptographic restrictions - Added git configuration hardening documentation - Added comprehensive USBGuard section documenting USB device authorization rules - Added new "Systemd preset defaults" section documenting disabled-by-default services ### File Path Updates - Updated references from `debian/security-misc.postinst` to `debian/security-misc-shared.postinst` - Updated systemd paths from `/lib/systemd/` to `/usr/lib/systemd/` - Updated permission-hardener paths from `/etc/permission-hardener.d` to `/usr/lib/permission-hardener.d` ### New Features Documented - Kernel console output suppression via `loglevel=0` and `quiet` parameters - Recovery mode restrictions preventing physical attacks - Detailed Bluetooth controller restrictions and privacy settings - Faillock configuration with 7-day failure tracking window and manual unlock requirement - Emergency shutdown service with dracut module integration and udev rules - Thunar file manager hardening (thumbnails, volume management, network bookmarks) - Multiple new helper scripts and utilities: - `virusforget` for detecting unauthorized shell startup file changes - `askpass` for GUI password prompts - `check-for-usb-controller` for conditional USBGuard activation - `pam_only_if_login` and `pam_only_if_su` for PAM conditional helpers - `block-unsafe-logins` for privileged account protection - AppArmor tunable for config-package-dev displaced files - Custom `sysinit-post.target` for boot synchronization - Systemd drop-in for sysfs supplementary group access - LKRG VirtualBox compatibility management ### Removed Content - Removed "Access rights relaxations" section (pkexec/lxqt-sudo workaround) as it's no longer applicable ### Notable Implementation Details - Emergency shutdown service is disabled by default and requires manual enablement - Default panic key sequence changed from Ctrl+Alt+Delete to Ctrl+Alt+End - USBGuard uses implicit block policy with specific device class restrictions - Multiple systemd services are explicitly disabled by default in the preset - Faillock is skipped for remote services (sshd, dovecot) to prevent remote lockout attacks https://claude.ai/code/session_0125G25dF8DVff618hmCMMNw

efol · May 5, 2026, 11:14am

“efi_pstore.pstore_disable=1” is set. Why “lsmod | grep pstore” shows that efi_pstore is loaded? The same issue persists on Tails.

Is efi_pstore.pstore_disable=1 not working since kernel 6.12?

efi_pstore /bin/false works. I think a boot parameter is better solution

efol · May 5, 2026, 12:23pm

Tails developers say that everything is working. It is not a problem that the module loads

arraybolt3 · May 5, 2026, 11:19pm

That’s not really surprising to me. efi_pstore.pstore_disable=1 is a parameter to the kernel module, which implies that the module is being loaded and is then obeying the parameter.

efol · May 23, 2026, 1:58pm

Tails are blocking new kernel modules. Related to recent LPEs. Will Kicksecure block them too? Do it bring problems with VM networking when they are applied on host?

algif_aead
esp4
esp6
rxrpc

Patrick · May 23, 2026, 5:16pm

Quote oss-sec: Re: CVE-2026-31431: CopyFail: linux local privilege scalation

Related:
Kicksecure wiki - copy.fail: Mitigation

efol · May 23, 2026, 5:31pm

Great to see Whonix is active in oss-sec discussions. Aaron, what do you think about blocking rxrpc? Only “Andrew File System” use this module? Any opinions on esp4/esp6? It is used by IPSec. It could be added to sysctl but with a comment?

arraybolt3 · May 24, 2026, 1:56am

In general, we have to be careful what we block because of the damage it could cause. That being said, we already block quite a few rare network protocols (in security-misc/etc/modprobe.d/30_security-misc_disable.conf), so if rxrpc is really used by almost nothing except AFS, I definitely think it’s a good idea to disable it (especially since the same config file already disables AFS).

IPSec feels too important to want to block. Tails might get away with it since they’re a primarily portable OS, Whonix is more persistent and I can imagine someone having a legitimate use for IPSec there.