Belajar Cloud Hypervisor - Network Security & Isolation

#Pendahuluan

Setelah memahami keamanan internal VMM di episode 12 (virtio, IOMMU, Landlock, seccomp), sekarang kita melihat ke luar: bagaimana VM diisolasi satu sama lain di jaringan, bagaimana firewall membatasi lalu lintas, dan apa saja ancaman nyata yang pernah menimpa Cloud Hypervisor. Salah satunya sangat penting untuk dipahami: CVE-2026-27211.

Bayangkan gedung apartemen: tiap unit (VM) harus punya pintu dan dinding sendiri — kalau tidak, penghuni satu unit bisa lewat ke unit lain tanpa sepengetahuan. Isolasi jaringan VM adalah dinding-dinding itu, dan CVE-2026-27211 adalah contoh bagaimana dinding bisa bocor lewat celah yang tak terduga.

#Isolasi Jaringan per-VM

#Satu TAP, Satu VM

Prinsip pertama isolasi: setiap VM punya TAP sendiri (kita sudah bahas di episode 7). Tidak ada dua VM yang berbagi antarmuka yang sama. Kombinasi TAP unik + MAC unik membuat traffic VM tidak tercampur di lapisan L2.

cloud-hypervisor --kernel kernel-vmlinux --disk path=vm-a.raw --net tap=tap-a,ip=192.168.100.1,mac=a8:21:95:80:00:01 --api-socket /tmp/a.sock &
cloud-hypervisor --kernel kernel-vmlinux --disk path=vm-b.raw --net tap=tap-b,ip=192.168.101.1,mac=a8:21:95:80:00:02 --api-socket /tmp/b.sock &

Perhatikan kedua VM memakai subnet berbeda (192.168.100.x vs 192.168.101.x). Dengan bridge yang terpisah, traffic antar VM tidak akan mengalir tanpa konfigurasi eksplisit:

sudo ip link add br-a type bridge
sudo ip link add br-b type bridge
sudo ip link set tap-a master br-a
sudo ip link set tap-b master br-b

#Firewall di Host

Bridge Linux pada dasarnya tidak memfilter. Untuk membatasi apa yang boleh masuk/keluar VM, pasang aturan firewall (nftables/iptables) di host. Contoh membatasi VM-a hanya bisa berbicara dengan VM-b pada port tertentu:

nft add table ip vmfw
nft add chain ip vmfw forward { type filter hook forward priority 0 \; }
nft add rule ip vmfw forward iif "tap-a" oif "tap-b" ip daddr 192.168.101.10 tcp dport 443 accept
nft add rule ip vmfw forward iif "tap-a" drop

Aturan di atas: hanya traffic tap-a → tap-b ke port 443 yang diizinkan; semua traffic keluar dari VM-a di-drop. Karena aturan berada di forward hook (bukan input/output host), ia hanya memengaruhi lalu lintas antar-VM, bukan traffic host itu sendiri.

#Isolasi vhost-user

Untuk vhost-user (episode 7), isolasi berarti daemon berjalan di proses terpisah dengan file descriptor yang terbatas. Daemon hanya melihat socket dan memory region yang dialokasikan untuk VM-nya, bukan seluruh host:

sudo -u chfs virtiofsd --socket-path /tmp/fs-a.sock --shared-dir /srv/vm-a/shared

sudo -u chfs menjalankan daemon sebagai user non-root dengan akses terbatas. Prinsipnya sama dengan sandbox VMM: proses dengan privilege terkecil yang diperlukan.

#Studi Kasus: CVE-2026-27211

#Kerentanan

CVE-2026-27211 adalah kerentanan pada virtio-block dengan image raw: sebuah guest yang berkompromi bisa memanfaatkan cara image raw dipetakan (memory-mapped file) untuk membaca file lain di host di luar image — exfiltration data lintas VM. Karena raw image di-mmap langsung, bug pada handling offset/panjang blok bisa membuat guest membaca memori file host lain yang kebetulan berdampingan.

Dampaknya serius: tenant A yang menyewa VM bisa membaca file tenant B, atau file sensitif host. Ini persis kategori bug yang tidak terlihat sampai satu VM sudah dikompromi.

#Perbaikan di v50.1

Versi v50.1 merilis perbaikan untuk CVE ini. Langkah pertama yang wajib: selalu jalankan versi yang sudah di-patch:

cloud-hypervisor --version
# harus >= v50.1, idealnya versi terbaru (v53.0)

Jika kalian masih memakai rilis di bawah v50.1, upgrade segera. Cek halaman rilis resmi untuk detail patch dan lakukan verifikasi ulang binary setelah update.

#Mitigasi dan Workaround

Bagi yang tidak bisa langsung upgrade (misal menunggu jendela maintenance), mitigasi berlapis:

1. Image untrusted/writable: jangan pernah memakai raw image dari sumber yang tidak dipercaya, dan hindari image yang writable bersama antar tenant.
2. Backing image read-only: sajikan image dasar sebagai readonly=on agar guest tidak bisa menulis:

cloud-hypervisor \
  --kernel kernel-vmlinux \
  --disk path=ubuntu.raw,readonly=on \
  --disk path=writable.raw \
  --cpus boot=2 \
  --memory size=2G

3. Workaround Landlock: karena CVE melibatkan akses file di luar image, batasi filesystem yang bisa dilihat VMM dengan Landlock (kernel 5.13+). Ini membatasi blok file yang bisa dibuka proses VMM, sehingga exfiltration tidak bisa menjangkau file lain di host.
4. Prinsip least privilege: jalankan VMM dengan user non-root dan setcap minimal (episode 3), bukan root penuh.

#Memantau dan Mendeteksi

Isolasi tidak lengkap tanpa observasi. Pantau indikator mencurigakan:

auditctl -w /srv/vms/ -p rwxa -k vm-storage
ausearch -k vm-storage --start today

Dan pastikan VMM berjalan dengan batasan yang benar:

ps -o user,pid,cmd -C cloud-hypervisor
cat /proc/$(pgrep -f 'cloud-hypervisor' | head -1)/status | grep -E "Seccomp|CapEff"

Seccomp: 2 menandakan filter aktif; CapEff yang minimal (hanya cap_net_admin) menandakan least privilege berjalan.

#Penutup

Inti yang harus dibawa pulang:

• Satu TAP per VM + subnet terpisah adalah fondasi isolasi jaringan.
• Bridge Linux tidak memfilter; pasang aturan firewall (nftables) untuk membatasi antar-VM.
• Isolasi vhost-user berarti daemon berjalan dengan privilege minimal dan akses terbatas.
• CVE-2026-27211: exfiltration raw image via virtio-block, diperbaiki di v50.1.
• Mitigasi: patch versi, image trusted/read-only, workaround Landlock, least privilege.
• Pantau akses storage dan status seccomp VMM secara rutin.

Di episode 14 selanjutnya kita akan membahas confidential computing: TDX & SGX — Intel Trust Domain Extensions dan Software Guard Extensions yang masih eksperimental, arah confidential VMs, serta cara verifikasi attestation/quote agar workload terpercaya bisa berjalan di infrastruktur yang tidak dipercaya. Enkripsi VM dimulai dari CPU.