Fedora systemd hardening

Ask Fedora
, , ,
1

All the VMs (KVM, Gnome Boxes, VirtualBox) I had created for compartmentalization following part of the security strategy of Qubes OS have been corrupted and compromised by intrusions. Fedora is considered a reasonably secure OS host by Whonix developers, preferable only to Kicksecure and Qubes. Windows and Mac are not considered optimal.

But, clearly, further security enhancements have to be implemented in Fedora Workstation. So I started looking into security auditing tools like lynis (systemd-analyze security).

What is the best way to harden NetworkManager.service [Medium] → [Protected], for example, while preserving functionality? Options for hardening systemd service units such as (there are several and which unit stops desired functionality and which unit improves security against a particular threat model is the question)
. . .
[Service]
ProtectSystem=strict
ProtectKernelTunables=yes
ProtectProc=noaccess
. . .
can change the lynis audit results to [Protected] but then the service is no longer functional. Wifi modules go unrecognized, connections can’t be established, VPNs won’t connect, etc.

I got lynis up to a 74 score but VMs still get pwned. What should I focus on to improve host security? Thanks.

2

How much is too much? I’m currently attempting to compile a series of tweaks from various projects for system hardening. I believe there are some tweaks that are easy (using NTS instead of NTP, Kicksecure’s kernel hardening, blocking GNOME from automounting drives), but there are some that could be disruptive (enabling DNSSEC or private /home/ for some).

3

Hey there, I’m doing a review of Qubes OS right now and searching the Internet this is one response that seems to address Qubes and systemd…or not. Could you clarify that you were creating VM’s in Qubes OS which is running Fedora and those got pwned?

I guess the confusing part for me is “following part of the security strategy for Qubes OS”. QOS uses Xen only? I guess even if you aren’t testing Qubes OS VM’s but vanilla Fedora I have some questions if you don’t mind.

  1. Are you a System76 Dev or Security Analyst?
  2. Can you shed some light on how you pwned those VM’s?
  3. Did you ever figure out any hardening steps that proved a mitigation?
  4. Have you tried Secureblue and if so what were the results?

Thanks,
Elias

4

I haven’t looked into systemd script sandboxing in a few years, but have notes here about the options I messed with.

I didn’t try applying that to any existing system services, but only to custom stuff I made. I don’t recall what ReadOnlyPaths and ReadWritePaths were about. I’m thinking PrivateNetwork was for service daemons that ran locally.

1 Like
5

Nice, I appreciate this.

Reading that quickly it seems the one stand out tunable is ProtectProc=noaccess or ProtectProc=invisible for system services. The man says that most system services should be set to “Invisible” but the default is default and provides no hardening which is kinda…an odd choice for me.

Does anyone have or know of a list or template for fundamental services in which noaccess or invisible resulted in a stable high function OS, especially in regards to mitigating exploits, vulnerabilities, vectors to systemd itself, perhaps even from a VM or podman?

Or perhaps if I were to start with one process to noaccess possibly related to systemd hardening to start out with for testing, what would you choose?

EDIT: And yeah, as in the OP, NetworkManager.service is off the list, at least for noaccess.