Kernel Hardening - security-misc

raja · December 11, 2022, 10:11am

Anyone had any issues with this?

Patrick · December 18, 2022, 11:25am

Now merged. Thank you!

raja · January 8, 2023, 5:54am

Based on the recently merged:

We are now allowing kexec:

github.com

Kicksecure/security-misc/blob/master/etc/sysctl.d/30_security-misc.conf#L41


      
          net.core.bpf_jit_harden=2
          
          
## Quote https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html
          ##
          ## kexec_load_disabled:
          ##
          ## A toggle indicating if the kexec_load syscall has been disabled. This value defaults to 0 (false: kexec_load enabled), but can be set to 1 (true: kexec_load disabled). Once true, kexec can no longer be used, and the toggle cannot be set back to false. This allows a kexec image to be loaded before disabling the syscall, allowing a system to set up (and later use) an image without it being altered. Generally used together with the "modules_disabled" sysctl.
          
          
## Disables kexec which can be used to replace the running kernel.
          kernel.kexec_load_disabled=1
          
          
## Hides kernel addresses in various files in /proc.
          ## Kernel addresses can be very useful in certain exploits.
          ##
          ## https://kernsec.org/wiki/index.php/Bug_Classes/Kernel_pointer_leak
          kernel.kptr_restrict=2
          
          
## Improves ASLR effectiveness for mmap.
          vm.mmap_rnd_bits=32
          vm.mmap_rnd_compat_bits=16

Are we sure that this is a good idea? Recall, kexec functionality can be abused to replace the existing running kernel and load a malicious kernel (gaining arbitrary code execution).

Sensible hardening guides [1, 2] and security distributions [3] always appear to have it strictly disabled by default.

On the plus side, while having cold boot attack defense is good. The real question is whether the tradeoff of having kexec allowed is worth it knowing the potential downsides?

Patrick · January 8, 2023, 12:34pm

To use kexec, root is required. But if an attack has root access, then it’s game over anyhow.

In a threat model with untrusted root ( Multiple Boot Modes for Better Security: an Implementation of Untrusted Root ) that might be more important.

You could argue that the scope of security-misc should be limited and that cold boot attack defense should be a separate package instead. Then security-misc could disable kexec and cold boot attack defense could re-enable it.

That would allow cold boot attack defense to only be enabled on host operating systems. It would get installed on Kicksecure host operating systems by default but could be omitted in VMs (as it seems it’s not useful there except for development and testing).

raja · January 9, 2023, 6:28am

That makes sense.

Are there any statistics as to the portion of users that install/download Kicksecure to be used on bare metal vs VMs?

Based on my anecdotal evidence most people run it on VMs, though admittedly its a very very small sample size.

Patrick · January 9, 2023, 12:02pm

Patrick · January 9, 2023, 12:03pm

Patrick · January 30, 2023, 11:53am

raja · March 30, 2023, 7:50am

Patrick · June 12, 2023, 9:57am

Patrick · July 15, 2023, 1:04pm

Patrick · July 16, 2023, 9:59am

A post was merged into an existing topic: IO_uring security / vulnerabilties?

HulaHoop · July 24, 2023, 5:14pm

Noted. I’m posting here about more options for reference in case a challenger appears who could and cares to handle such a project.

IO_uring is a new IO subsystem and is a veritable vuln dumpster fire. The Goog has disabled it on its systems and OSs.

A new 6.6 sysctl is developed just to disable it on boot which we should take advantage of ASAP.

Patrick · October 21, 2023, 8:37pm

github.com/Kicksecure/security-misc

Secure Remounting

opened 06:06PM - 20 Oct 23 UTC

monsieuremre

Is there any particular reason to have a systemd service remount partitions rath…er than editing /etc/fstab accordingly? This seems cause extra complexity without any benefit that I could see of. As a reference, the recommended options from the lynis documentation can be used. I have tested this and no application seems to break that a debian user would normally install, let alone any whonix default packages. # --------------------------------------------------------- # Mount point nodev noexec nosuid # /boot v v v # /dev v v # /dev/shm v v v # /home v v # /run v v # /tmp v v v # /var v v # /var/log v v v # /var/log/audit v v v # /var/tmp v v v # --------------------------------------------------------- This can be achieved with a simple bind for those without literal partitions on disk. And for the literal partitions, a basic sed operation can be used on fstab. The old fstab can be backed up to be restored upon package removal. So what would be the reason to use a service here? If this is not necessary, I can create a pull request for modifying the fstab. If there is a reason that I do not know of, the same recommended options can be adapted by the service, I assume.

Patrick · October 21, 2023, 9:02pm

github.com/util-linux/util-linux

Support for Remounting with Secure Options without Modifying `/etc/fstab`

opened 09:01PM - 21 Oct 23 UTC

adrelanos

We are working on a package named [`security-misc`](https://github.com/Kicksecur…e/security-misc) aimed at enhancing miscellaneous security settings on Linux systems. One of the features we are keen on implementing is the ability to remount specific mount points with more secure options (`nosuid`, `nodev`, `noexec`), as discussed in [this issue](https://github.com/Kicksecure/security-misc/issues/128). However, we want to achieve this without altering the user's `/etc/fstab` file to prevent potential conflicts with other packages that might own or manage this file. Direct modifications to `/etc/fstab` using tools like `sed` or [str_replace](https://github.com/Kicksecure/helper-scripts/blob/master/usr/bin/str_replace) are seen as unclean, risky, and fragile, especially when `/etc/fstab` gets updated or overwritten by package upgrades. We explored a potential workaround that does not work at time of writing: * [Systemd Service](https://github.com/Kicksecure/security-misc/blob/master/lib/systemd/system/remount-secure.service) * [Remount Script](https://github.com/Kicksecure/security-misc/blob/master/usr/libexec/security-misc/remount-secure) Is this a feature request that util-linux could help with or do you have other suggestions on how to cleanly implement a easily to switch knob to enable/disable these mount options without having to edit `/etc/fstab`? Would * https://github.com/util-linux/util-linux/issues/790 * https://github.com/systemd/systemd/issues/12506 be a good solution? Do you have other suggestions on how to implement this?

Patrick · October 24, 2023, 5:09pm

github.com/Kicksecure/security-misc

Various Improvement Options

opened 05:24PM - 23 Oct 23 UTC

monsieuremre

Disabling bluetooth is a bold choice. But if we are concerned about even breakin…g some random apps when remounting, we should also be concerned about making the system unusable for ordinary people. We can set bluetooth configurations in a way that it starts turned off on boot, it uses private addresses and times out on discoverability. We can also make a systemd service to automatically turn off bluetooth when there are no devices connected for 10 minutes. This is implemented for example in graphene os. Usb-hardening. We can harden the usage of usb devices with usb-guard. By default blocking everything and whitelisting what was plugged in in the time of install can be a choice. But if we don't want to be that extreme, we can just manually reject some stuff and allow others. For example, as I implemented in my [script](https://github.com/monsieuremre/chainmail/blob/main/chainmail.sh), the following: ``` allow with-interface equals { 08:*:* } # Allow usb devices with mass storage interface reject with-interface all-of { 08:*:* 03:00:* } # These have both storage and keyboard. Suspicious. reject with-interface all-of { 08:*:* 03:01:* } ``` This would for example protect from what is reviewed in this [video](https://www.youtube.com/watch?v=kfaHJwcG2mg). Disabling x11 all together, including via xwayland. This requires, of course, the user being on wayland already. For this I suppose, kicksecure and whonix should first make the move to drop x11. Using wayland also means using pipewire, which much better. This option depends on external factors tho, so this is more of an idea only. I think I can implement these things, considering they are rather simple solutions, If they should be of interest for the maintainers of this repo.

raja · October 25, 2023, 12:06am

Overall, a very interesting set of discussions and suggestions!

I am also trying to catch up on the all details to see whether I can offer any feedback.

Patrick · November 2, 2023, 5:18pm

github.com/Kicksecure/security-misc

Add more hardening options to the default profile in etc

Kicksecure:master ← monsieuremre:profile

opened 01:56PM - 02 Nov 23 UTC

monsieuremre

+8 -0

Disabling coredumps and setting a secure umask value. Comments explain more in d…etail. I am really sorry for the many pull requests, this is the last one. I don't mean to spam the project. They are mostly really small but significant changes. I thought that it would be easier to manage for the maintainer if they are seperated.

Patrick · November 4, 2023, 10:43pm

github.com/Kicksecure/security-misc

Scope of application-specific hardening?

opened 10:42PM - 04 Nov 23 UTC

adrelanos

https://github.com/Kicksecure/security-misc/pull/146 (which looks nice at first …sight) and [1500 AppArmor profiles](https://apparmor.pujol.io/) (impressive scope) woke me up to set the expectations straight for [application-specific hardening](https://github.com/Kicksecure/security-misc#application-specific-hardening). How many applications should be hardened through this repository? Maybe best to limit security-misc to "global" / "system" wide hardening, have a separate repository for application specific hardening? Or I could arbitrarily limit the applications to those pre-installed in Kicksecure, Whonix and perhaps some other popular/important applications (even more arbitrary). However, ~1500 pull requests for all sorts of applications hardening I've never used and reviewing the details of this with DOS the development so this isn't possible. These expectations need to be set straight in the readme to respect contributor's time. For a hypothetical ~1500 application hardening settings a separate repository would need to be maintained by somebody else.

Patrick · November 5, 2023, 7:44pm

github.com/Kicksecure/security-misc

Wifi and Bluetooth Patch | Security and Privacy

Kicksecure:master ← monsieuremre:wifi-and-bluetooth

opened 02:46PM - 27 Oct 23 UTC

monsieuremre

+48 -2

With this patch, the mac address of the device is randomized per wifi connection…. This randomizes all the bits and does not hide the fact that we are randomizing the address. The original mac is not extractable and this does not cause any issue. The same functionality exists in grapheneOS. The privacy extensions for ipv6 addresses are also enabled. These are theoretically not necessary when we randomize the mac address. But they are still harmless and bring privacy. Unlike ip4 addresses, ipv6 addresses can also leak device information and not only network. And also, disabling the kernel bluetooth modules was a little too much for daily usage for most people in this age. So I disabled it and configured bluetooth in a privacy respectin manner. Bluetooth starts disabled on start up. This wasn't the case in a default install. Temporary devices are forgotten immediately. Enforces private addresses. Some legacy devices that don't support private addresses are not accepted. There is a timeout for pairability and discoverability, unlike the default configs. I see this as good enough. Bluetooth is turned off on boot. User has the freedom to enable it using their GUI settings at their own risk. On file was deleted. It is also addressed in the main script. Lines are not deleted, just commented out with the proper explanation.