Is it pointless to harden quadlets if you use krun?

[user451421541757324]

Hi, I'm switching to krun and was wondering if hardening the quadlets is pointless since they're virtual machines.

By "hardening" I mean:

[Unit]
After=network-online.target demo.network
Wants=network-online.target

[Container]
ContainerName=redlib
Image=ghcr.io/silvenga/redlib:0
Network=demo.network

User=101
ReadOnly=true
NoNewPrivileges=true
DropCapability=ALL
#UserNS=auto:size=1024

[Service]
AmbientCapabilities=
#CapabilityBoundingSet=
IPAddressAllow=any
KeyringMode=private
LockPersonality=true
MemoryDenyWriteExecute=true
NoNewPrivileges=true
ProcSubset=pid
RemoveIPC=true

DevicePolicy=closed
#PrivateDevices=true
#PrivateNetwork=true
#PrivateTmp=true
#PrivateUsers=true

#ProtectClock=true
#ProtectControlGroups=true
#ProtectHome=true
#ProtectHostname=true
#ProtectKernelLogs=true
#ProtectKernelModules=true
#ProtectKernelTunables=true
ProtectProc=invisible
#ProtectSystem=strict

RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
#RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true

SystemCallArchitectures=native
#SystemCallFilter=~@clock

[Install]
WantedBy=default.target

[mg1986jp]

Not pointless, but the priority changes.

With krun, each container runs inside a lightweight VM (libkrun/libkrunfw), so you already have hardware-level isolation — the container process can't touch the host kernel directly. That makes most of the kernel-hardening directives (ProtectKernelModules, ProtectKernelTunables, SystemCallFilter, etc.) redundant in terms of host protection, since the guest kernel is separate.

What's still useful:

• User=101 / NoNewPrivileges — defense in depth. If there's a VM escape (unlikely but not impossible), running as non-root inside the guest means the attacker lands with fewer privileges
• ReadOnly=true — protects the container's own filesystem, which matters regardless of isolation model (e.g., preventing a compromised app from modifying its own binaries)
• RestrictAddressFamilies — still limits what the process inside the VM can do network-wise
• DropCapability=ALL — minimal impact but also minimal cost, no reason to remove it

What you can probably drop:

• ProtectProc, ProtectClock, ProtectControlGroups, ProtectHostname, ProtectKernelLogs — these protect the host kernel's interfaces, which the guest can't reach anyway through krun
• MemoryDenyWriteExecute — the VM boundary already prevents code execution on the host
• LockPersonality, RestrictRealtime, RestrictSUIDSGID — same reasoning, these restrict syscall behavior that's already sandboxed by the VM

TL;DR: keep the stuff that hardens the process within its own environment (User, ReadOnly, NoNewPrivileges). The kernel protection directives are mostly redundant with krun but also cost nothing to leave in, so it's your call whether the clean config is worth removing them.

[user451421541757324]

A very exhaustive answer, thanks a lot!