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