Kernel Hardening - security-misc

Patrick · November 6, 2023, 2:12am

This was merged.

Patrick · November 6, 2023, 2:44am

How about Speculative Return Stack Overflow (SRSO) — The Linux Kernel documentation?

Quote https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt

	spec_rstack_overflow=
			[X86] Control RAS overflow mitigation on AMD Zen CPUs

			off		- Disable mitigation
			microcode	- Enable microcode mitigation only
			safe-ret	- Enable sw-only safe RET mitigation (default)
			ibpb		- Enable mitigation by issuing IBPB on
					  kernel entry
			ibpb-vmexit	- Issue IBPB only on VMEXIT
					  (cloud-specific mitigation)

`Depends:` vs `Recommends:` vs none

opened 04:28AM - 19 Nov 23 UTC

adrelanos

* `libpam-tmpdir` * https://github.com/Kicksecure/security-misc/pull/147 * …`usbguard` * https://github.com/Kicksecure/security-misc/pull/166 Do we really need `Depends:`? This makes it difficult to remove the package for users. Perhaps `Recommends:` is sufficient? Not ideal. Or nothing. Why? Because security-misc shouldn't be attempting to be a Linux distribution such as Kicksecure that installs by a number of pre-installed applications. references: * https://github.com/Kicksecure/kicksecure-meta-packages * https://github.com/Kicksecure/kicksecure-meta-packages/debian/control

Patrick · November 20, 2023, 1:10pm

github.com/Kicksecure/security-misc

Small systemd hardening

Kicksecure:master ← monsieuremre:patch-6

opened 07:32PM - 19 Nov 23 UTC

monsieuremre

+6 -0

Just allow native architecture calls. From what I understand, 32 bit binaries wo…uld not benefit from ASLR due to the incredibly small address space and might cause other programs to have less effective ASLR too. Apparently this can also cause other security issues and it is in general recommended not to execute anything non-native. Also once again core dump.

Patrick · November 20, 2023, 1:26pm

Patrick · December 1, 2023, 5:46am

TODO: Need to check if secureblue has hardening settings that we lack that would be applicable here too.

Patrick · December 5, 2023, 9:43am

github.com/Kicksecure/security-misc

use SRSO spec_rstack_overflow kernel setting?

opened 09:42AM - 05 Dec 23 UTC

adrelanos

To test: cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_over…flow https://kernel.org/doc/html/latest/admin-guide/hw-vuln/srso.html ``` spec_rstack_overflow= [X86] Control RAS overflow mitigation on AMD Zen CPUs off - Disable mitigation microcode - Enable microcode mitigation only safe-ret - Enable sw-only safe RET mitigation (default) ibpb - Enable mitigation by issuing IBPB on kernel entry ibpb-vmexit - Issue IBPB only on VMEXIT (cloud-specific mitigation) ``` Best to use `spec_rstack_overflow=ibpb`? Or not needed because we're already using `spec_store_bypass_disable=on`?

Patrick · January 9, 2024, 6:18am

github.com/Kicksecure/security-misc

MAC randomization breaks root server and VirtualBox DHCP / IPv6PrivacyExtensions might be problematic

opened 01:11PM - 06 Jan 24 UTC

adrelanos

https://github.com/Kicksecure/security-misc/blob/master/usr/lib/NetworkManager/c…onf.d/80_randomize-mac.conf ``` [device-mac-randomization] wifi.scan-rand-mac-address=yes [connection-mac-randomization] ethernet.cloned-mac-address=random wifi.cloned-mac-address=random ``` 1) Breaks root servers, namely broke kicksecure.com. This is what the server provide sent by e-mail. ``` We have detected that your server is using different MAC addresses from those allowed by your Robot account. Please take all necessary measures to avoid this in the future and to solve the issue. We also request that you send a short response to us. This response should contain information about how this could have happened and what you intend to do about it. In the event that the following steps are not completed successfully, your server can be locked at any time after 2024-01-17 16:51:11 +0100. How to proceed: - Solve the issue - Please note, in case you have fixed the problem, please wait at least 10 minutes before rechecking: ... - After successfully testing that the issue is resolved, send us a statement by using the following link:... Please visit our FAQ here, if you are unsure how to proceed: https://docs.hetzner.com/robot/dedicated-server/faq/error-faq/#mac-errors Important note: When replying to us, please leave the abuse ID [...] unchanged in the subject line. Manual replies will only be handled in the event of a lock. Please note that we do not provide telephone support in our department. If you have any questions, please send them to us by responding to this email. Kind regards Network department ``` 2) Breaks VirtualBox DHCP when using Network Manger (in Kicksecure) after VM reboot (`sudo reboot`). It is functional for the first start after powering off and powering on the VM. [1] Might be related: https://forums.virtualbox.org/viewtopic.php?t=86753 Could be a Network Manager issue: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1116421 https://askubuntu.com/questions/307717/networkmanager-problem-with-cloned-mac-address ---- [1] Before someone says that's a VirtualBox issue, no, I mean, maybe, but that doesn't matter. VirtualBox is a valid environment. If that breaks, other environments will break as well. Broken networking is extremely frustrating. MAC randomization would be suitable for Kicksecure, but only if stable. It's not important enough to break common network configurations in common environments. ---- TODO: This bug has to be reported to Network Manager (NM) as above bug reports apparently never have reached upstream NM.

raja · January 29, 2024, 1:02pm

Patrick · March 20, 2024, 2:30pm

github.com/Kicksecure/security-misc

/lib/sysctl.d/990-security-misc.conf - log_martians

opened 09:35PM - 19 Mar 24 UTC

the-moog

Defaulting ether of ```text net.ipv4.conf.all.log_martians net.ipv4.c…onf.default.log_martians ``` to a 'on'/1 value breaks thing and makes the machine very slow, even crashing it... TL;DR; See *** at the bottom. Join me, for a moment, in my pain and sympathise with the hours of frustration and lost sleep in getting to the bottom of this one... I found this while fighting with Network Manager to bring a host and it's VMs up in a predictable and repeatable way, this is where the VMs are bridged to a VLAN and then to the same network, no NAT here. This worked fine until I did the in-place upgrade/switch to KickSecure. After than networking went bad big time. On all occasions to date I backed off and resorted to manual configuration though that is not without issues. So even when not being obviously broken the machine seemed to come with an 'odd' feeling. In trying to resolve this I found I could often take the network connection down and even hang it up for no apparent reason. ..techy bit.. ...hopefully the way I understand this is correct, happy to be informed otherwise .... A Martian is an IP packet somehow arriving through an interface where it was not expected, regardless of transport. I.e. One that is outside of the interfaces current IP+Subnet mask ('s - pleural) defined for that interface. And, indeed from a security perspective this would be packet spoofing, ARP poisoning or a rogue DHCP. The default state of most unconfigured Ethernet adapters is receive all broadcasts until configured or disabled. Some adapters have built in tables other's simply turn on a receive all flag and let the downstream systems handle it. Without that convention, booting over LANs would be rather unreliable. From an IP perspective a valid or invalid packet is one of many perfectly fine Ethernet broadcast frames i.e. groupcasts, non-ip Ethernet payloads, multicasts, DHCP, ICMP, ARP,... So, logically, an unconfigured adapter has an IP address of "NONE" (I don't think that is even 0.0.0.0/0 as that is still a unicast IP address despite meaning 'this host') If the IP is only expecting 'NONE' packets, any unicast, broadcast or multicast data arriving is..... A Martian!!! Yikes, better tell somebody.... ---- Techy bit out of the way, textbooks down please... With the sysconfig log_martians setting enabled, this results in kernel `dmesg` log getting spammed (almost literally) to death. It seems (and this is new to me) the Kernel has some sort of rate timer and de-configures interfaces that spam it. I guess so as to remove the offending interface, making the assumption that there is a hardware, configuration or external issue, e.g. a packet storm. Now when you setup bridging, you don't want the bridge port interface `UP` or `configured` as that prevents you from adding it to the bridge, but obviously it must exist (i.e. have a driver) or you would also not be able to add it.. (Side note about another issue, that compounds and makes this occur frequently... It seems that even for any unconfigured interface, if it is 'up' then Network Manager gets all excited and kindly takes over and 'configures' it for you... and any other interfaces it comes across while it's there. It does that even if told not to (unless made "strictly unmanaged") and will happily remove any settings (i.e. IP address) that you have added that it's unaware of. But that's that's a but for somebody else, so I'll moan about that elsewhere.... I set network manager to explicitly own but *not configure* the interface, so that it can build the bridge without tripping itself up, but in doing that is was still failing. So, to investigate, when I took over and activated the bridge or, if for any reason, the LAN connection breaks momentarily then NM 'reconfigures' it and.... - BOOM! No up with no IP, so the Martians arrive.... On this last occasion I was piping the dmesg log to another console, and I saw the issue occur in real time. *** Suggestion. I can understand the reasons for enabling log_martians, i.e. that we want to log_martians for the benefit of detecting eves-dropping, but we must only do that on configured interfaces, perhaps as part of the if-up and if-down (i.e. those that have a valid IP connection and are up) and not just by default. It probably needs some sort of watchdog or hook that ensures a broken interfaces that does not go down through ifup/down is reset properly. Otherwise typing `ip addr delete....` will still blow up. BTW: While tracking this down to and looking at 990-security-misc.conf, I noticed a few other settings that could/will have undesirable effects in certain use cases. Perhaps there needs to be some sort of Wizard that at least lets the user be aware of what is going on under the hood without making assumptions and generalisation, allowing them to accept or mitigate the risks?

raja · April 12, 2024, 8:55am

Patrick · April 13, 2024, 4:50am

Thank you! Merged.

Patrick · April 13, 2024, 11:22am

github.com/Kicksecure/security-misc

Blacklist other GPS modules like GNSS (Global Navigation Satellite System)

opened 09:18PM - 12 Apr 24 UTC

souchikjoardar201

## Blacklist other GPS modules like GNSS (Global Navigation Satellite System) … `garmin_gps` is another gps driver but that is already blacklisted in *30_security-misc.conf* https://github.com/Kicksecure/security-misc/blob/a9886a3119f9b662b15fc26d28a7fedf316b72c4/etc/modprobe.d/30_security-misc.conf#L107 ``` ls /lib/modules/`uname -r`/kernel/drivers/gnss | sed "s/\.ko//" ``` ``` blacklist gnss blacklist gnss-serial blacklist gnss-sirf blacklist gnss-ubx ``` This might be unnecessary but to be *"just to be safe"* type of thing in the case a malicious actor trys to load them or etc. I dont know of any other GPS modules that are included? But this might be something to look into further.

raja · May 1, 2024, 4:06am

Update on CPU mitigations.

One area of discussion is the inclusion of gather_data_sampling=force which will disable AVX if the system does not have a suitable microcode update.

Given that we are already disabling SMT, also disabling AVX may potentially cripple older processors if the instruction set is utilised by users.

The exact performance implications of this parameter on older EOL CPUs depends on workloads but I personally do not have any suitable physical hardware to test this myself.

Similarly the impact of VMs may also be significant for the same reasons.