Hypervisor Hardening Console
A hostile tenant shares your KVM/QEMU host. Harden it. Confine the emulator with sVirt, a seccomp sandbox and a per-VM non-root user; cut the device surface by dropping the VENOM floppy controllerand running a minimal machine model; close the multi-tenant channels by disabling KSMand turning on L1TF/MDS mitigations; and restrict — don’t remove — access to /dev/kvm. The catch: not every switch should be on. Some “lockdown” moves break the host or undo a stronger control, and the lab scores you on telling the difference.
The real job. More noise, a tighter clock.
Host hardening console
An untrusted, multi-tenant KVM/QEMU host: strangers' workloads share this box. Harden for a hostile guest, without breaking the virtualization the host exists to provide.
Set each control. Not every switch should be on — some would break the host.
Process confinement
sVirt (SELinux/AppArmor) per-VM confinement
Mandatory-access-control labels that confine each QEMU process so a compromised VM cannot touch another VM's resources or the host.
not applied: QEMU runs unconfined — a process escape has free rein of whatever the user can reach.
seccomp syscall sandbox (-sandbox on)
Restricts the set of host syscalls the QEMU process may make, shrinking what a hijacked emulator can do to the host kernel.
not applied: QEMU may issue any syscall, so an escape has the full host-kernel attack surface.
Run each VM's QEMU as its own non-root UID
Dynamic per-VM ownership so each QEMU runs as a distinct unprivileged user, not root and not a shared account.
not applied: QEMU runs as root (or a single shared user) for every VM.
Device & machine model
Remove the emulated floppy controller (FDC)
The virtual floppy disk controller was present in default machine models and is the device behind VENOM — reachable even with no floppy drive attached.
not applied: The legacy floppy controller stays in the model, exposing the VENOM attack surface.
Use a minimal machine type (q35 / microvm)
Modern, slim machine models expose far fewer legacy emulated devices than the old i440fx/pc profile.
not applied: VMs use the legacy i440fx profile with its full set of legacy devices present.
Multi-tenant isolation
Disable KSM (kernel same-page merging)
KSM deduplicates identical memory pages ACROSS guests to save RAM — which creates a cross-tenant timing/dedup side-channel.
not applied: KSM runs, merging identical pages across tenants to reclaim RAM.
Disable nested virtualization (unused here)
Nested virt lets guests run their own hypervisors; it widens the VMX/SVM attack surface and these workloads do not use it.
not applied: Guests can expose and exercise nested VMX/SVM paths they do not need.
Enable L1TF/MDS mitigations + core scheduling / SMT off
Microarchitectural side-channels (L1TF/Foreshadow, MDS/ZombieLoad) leak across VMs that share a physical core.
not applied: Default scheduling lets untrusted tenants land on sibling hyperthreads with no buffer-clear discipline.
Patch & access hygiene
Automatic security patching for QEMU + host kernel
Unattended security updates so device-model and host-kernel/KVM fixes land quickly.
not applied: Patching is manual and lags — known device and host-kernel bugs stay exploitable for weeks.
Restrict /dev/kvm to the kvm group
The /dev/kvm device node is the gateway to the virtualization interface; it should not be world-accessible.
not applied: /dev/kvm is world-accessible (0666), so any local user can drive KVM ioctls.
Posture so far
0/10 controls at best posture. 10 still exposed.
How it is scored
Each control is judged against hardening best practice for a hostile multi-tenant host.
Most controls should be On — but harder tiers add traps where the “lock it down harder” move breaks virtualization or defeats a stronger control. Falling for a trap takes an extra bite.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based hypervisor-hardening console: configure a KVM/QEMU host's security posture one control at a time and get scored against established hardening best practice.
- Controls span process confinement (sVirt/SELinux, seccomp sandbox, per-VM non-root QEMU), the device and machine model (drop the VENOM floppy controller, use a minimal q35/microvm model), multi-tenant isolation (disable KSM, enable L1TF/MDS mitigations and SMT discipline) and patch/access hygiene (restrict /dev/kvm, auto-patch).
- It is not a checklist you can blanket-enable: harder tiers add traps where "lock it down harder" is the wrong move — disabling virtio, blocking /dev/kvm outright, or sharing one QEMU user all break the host or defeat a stronger control.
- Every VM starts un-hardened, so you apply each control deliberately and see the exact rationale after grading.
- Runs entirely in your browser — no account, no install, nothing sent anywhere.
Frequently asked questions
What is the Hypervisor Hardening Console?
A free, in-browser lab where you harden a KVM/QEMU host by setting each security control to on or off, then get scored against the hardened posture a hostile multi-tenant host demands. Controls include sVirt/SELinux per-VM confinement, the seccomp syscall sandbox, running QEMU as a per-VM non-root user, removing the legacy floppy controller behind VENOM, using a minimal q35/microvm machine model, disabling KSM memory dedup, enabling L1TF/MDS mitigations, and restricting access to /dev/kvm.
Why can't I just turn every control on?
Because hardening means reducing attack surface without breaking the thing you are hardening. Several controls are traps: disabling the virtio paravirtual drivers forces slower, larger legacy device emulation; blocking /dev/kvm entirely stops the host from running VMs at all; running every VM under one shared account collapses the per-VM isolation you built. The lab penalises falling for these, so you have to read what each switch actually does.
Is this specific to KVM and QEMU?
Yes — the controls map to real KVM/QEMU/libvirt hardening: sVirt labels, -sandbox on, libvirt dynamic ownership, dropping the FDC device, q35/microvm machine types, KSM (/sys/kernel/mm/ksm), the kvm group on /dev/kvm, and host CPU-mitigation flags. The concepts (confine the process, shrink the device surface, close cross-tenant channels, patch fast) transfer to any Type-1 or Type-2 hypervisor.
Who is it for?
Virtualization and cloud platform engineers who run hypervisor hosts, security engineers reviewing a virtualization build, and anyone who wants the judgement to tell a real hardening win from a lockdown that breaks the host. It is free and runs entirely client-side.