gvx: Linux Containers, Docker és Kubernetes futtatása egyetlen unprivileged folyamatban

Bevezetés: Biztonsággal megerősített konténerek root jogosultság és host daemonok nélkül

Linux konténerek, docker build vagy Kubernetes futtatása fejlesztői gépen, CI futtatón vagy többbérlős felhőcsomóponton általában kényelmetlen biztonsági kompromisszumra kényszerít:

• Linuxon a szabványos OCI futtatókörnyezetek (runc, crun, runsc) vagy root jogosultságot igényelnek, vagy a host /var/run/docker.sock elérhetővé tételét, vagy --privileged (CAP_SYS_ADMIN) használatát, vagy olyan felhasználói névtereket (unshare(CLONE_NEWUSER)), amelyek kibővítik a host kernel támadási felületét.
• Windowson és macOS-en a konténermotorok (Docker Desktop, Podman Machine, Lima, OrbStack) teljes Linux virtuális gépkernelt indítanak a WSL2, a Hyper-V vagy a Virtualization.framework keretében, és ebben a virtuális gépben állandó háttérfolyamatot (daemont) futtatnak.

gvx (a rungv CLI és a z.gfire.dev/gvx/pkg/gvx Go SDK) biztonságos, nulla jogosultságot igénylő alternatívát nyújt. A Google gVisor felhasználói térben futó Linux kerneljének (Sentry) és felhasználói térben futó hálózati veremének (netstack) upstreamből követhető elágazásaként felépítve a gvx módosítatlan linux/amd64 és linux/arm64 ELF64 binárisokat és OCI konténereket futtat közvetlenül egyetlen, jogosultság nélküli, saját magát zároló host folyamaton belül Windowson, macOS-en és Linuxon.

Biztonsági garancia (háromgyűrűs mélységi védelem): A gvx soha nem gyengíti a host operációs rendszer biztonsági határait, soha nem telepít kernel-illesztőprogramot, és soha nem igényel root, sudo, --privileged jogot a hoston vagy CLONE_NEWUSER használatát. Mielőtt egyetlen vendég utasítást végrehajtana, a gvx lezárja saját host folyamatát Windows Restricted Tokens és Job Objects, macOS Seatbelt (deny default), vagy Linux PR_SET_NO_NEW_PRIVS + BPF seccomp segítségével. Minden vendég rendszerhívás, a virtuális UID 0 jogosultságok, a csatolások (VFS2) és a hálózati táblák (netstack) szigorúan a memóriabiztos Go Sentry kernelen belül vannak korlátozva.

Linux VM kernel nem indul el Windowson vagy macOS-en. Nem fut háttérfolyamat a hoston. A host operációs rendszeren nincs szükség root, sudo, felhasználói névterekre (CLONE_NEWUSER), mount(2), TUN/TAP illesztőprogramokra vagy CAP_NET_ADMIN jogosultságokra. Ebben a jogosultság nélküli folyamatban a gvx futtatja a Docker-in-Docker (docker:dind), a docker build, a docker compose és a többcsomópontos, magas rendelkezésre állású Kubernetes (k3s beágyazott etcd-vel és Calico CNI-vel) rendszert.

Konténer életciklus és háromgyűrűs host-lezárás

Minden gvx sandbox egy jogosultság nélküli host folyamaton belül fut, és háromfázisú életciklust érvényesít: előzetesen megnyitja az összes szükséges host fájlleírót és socketet, lezárja a host OS folyamatát a pkg/hostlockdown segítségével, majd belép a folyamaton belüli Sentry végrehajtási ciklusba.

Mielőtt a vezérlést átadná az első vendég utasításnak, a gvx előzetesen megnyitja a gyorsítótárazott .erofs image réteg-fájlleírókat, az .ext4 kötetfájl-fájlleírókat, a /workspace *os.Root kezelőt és a host hálózati socketeket, majd meghívja a hostlockdown.Apply() függvényt:

1. Windows NT (lockdown_windows.go): Meghívja az AdjustTokenPrivileges függvényt SE_PRIVILEGE_REMOVED jelzővel, hogy a jogosultságokat helyben eltávolítsa, majd DISABLE_MAX_PRIVILEGE korlátozott megszemélyesítési tokent köt Low integritási szinten (S-1-16-4096), a folyamatot egy névtelen Job Objecthez rendeli JOB_OBJECT_LIMIT_ACTIVE_PROCESS = 1 beállítással (ami blokkolja bármely gyermekfolyamat létrehozását), és a SetProcessMitigationPolicy segítségével engedélyezi a DisallowWin32kSystemCalls = 1 beállítást.
2. macOS XNU (lockdown_darwin.go): Beállítja az RLIMIT_NPROC = 0 értéket, és alkalmaz egy Seatbelt profilt (sandbox_init_with_parameters), amely a (version 1)(deny default) profilból indul, és blokkolja a process-fork, process-exec* műveleteket és minden új host fájlmegnyitást.
3. Linux (lockdown_linux.go + pkg/gvx/syscallfilter_linux.go): Beállítja a PR_SET_NO_NEW_PRIVS értéket, és telepíti a Sentry BPF seccomp engedélyezési listáját minden szálra (SECCOMP_FILTER_FLAG_TSYNC), explicit EPERM szabályokkal a execve, execveat, clone, openat és socket hívásokhoz.

Platformfüggetlen rendszerhívás-elfogás és 4 KB-os lapozás (pkg/sentry/platform)

A Linux ELF64 binárisok 4 KB (0x1000) memórialap-szemcsézettséget feltételeznek a mmap(MAP_FIXED) szegmensleképezésekhez. Ezzel szemben a Windows VirtualAlloc és MapViewOfFile3 64 KB (0x10000) igazítást kényszerít ki, az Apple Silicon macOS (darwin/arm64) pedig 16 KB (0x4000) host lapokat használ. Ráadásul minden operációs rendszernek más mechanizmusra van szüksége ahhoz, hogy elfogja a Linux SYSCALL (amd64) és SVC #0 (arm64) utasításokat Linux virtuális gép indítása nélkül.

A gvx mindkét problémát megoldja négy végrehajtási háttérrendszeren keresztül, amelyek a pkg/sentry/platform.Context interfészt valósítják meg:

1. Windows hardveres motor: platform/whpx (WinHvPlatform.dll)

windows/amd64 és windows/arm64 esetén a platform/whpx könnyű hypervisor partíciót hoz létre a WHvCreatePartition segítségével anélkül, hogy vendég OS kernelt indítana:

• 64 KB-ról 4 KB-ra váltó leválasztó: A whpx a pgalloc.MemoryFile minden 64 MiB-os arénáját egyszer regisztrálja a partícióval a WHvMapGpaRange segítségével. A későbbi MapFile és Unmap hívások csak a partíción belüli vendég lapTáblákat módosítják, így a Windows 64 KB-os allokációs szemcsézettsége ellenére pontos 4 KB-os R/W/X jogosultságokat érvényesítenek.
• Nulla API-s regiszterkiegyenlítés a CommPage segítségével:
  • amd64 esetén a vendég Ring-3 SYSCALL egy partíción belüli Ring-0 MSR_LSTAR csonkba (stubgen_x86.go) lép, amely a gyorsúti rendszerhívás GPR-jait (RAX, RDI, RSI, RDX, R10, R8, R9, RIP, RSP) egy megosztott 4 KB-os CommPage-be menti, majd végrehajtja a HLT utasítást, hogy kilépjen a WHvRunVirtualProcessor függvényből.
  • arm64 esetén a vendég EL0 SVC #0 az EL1 vektorokba lép (stubgen_a64.go), a X0..X8, SP_EL0, ELR_EL1, PSTATE regisztereket a CommPage-be menti, majd a nulla GPA-ról, amelyhez nincs memória rendelve, tölt be adatot, hogy memóriakilépést váltson ki a Sentryhez való visszatéréshez.

2. macOS hardveres motor: platform/hvf (Hypervisor.framework)

Apple Silicon (darwin/arm64) gépeken a platform/hvf a konténerszálakat a Hypervisor.framework vCPU-jaiban (hv_vm_create, hv_vcpu_run) futtatja:

• Kétszintű, 4 KB-os lapokon át történő 16 KB-os MMU fordítás: A Stage-2 (hv_vm_map) egyszer, 16 KB-os host lap szemcsézettséggel képezi le az 1 GiB-os memóriafájl-darabokat az Intermediate Physical Address (IPA) térbe, HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC jogosultságokkal. A vCPU-n belül az EL1 bluepill csonk (bluepill_arm64.go) beállítja a TCR_EL1.TG0 = 0b00 értéket (4 KB-os granula) a TTBR0_EL1-ben, és pontos R-X vagy RW- (UXN=1) jogosultságú 4 KB-os Stage-1 lapTábla-bejegyzéseket tölt fel. Mivel az ARM64 MMU a Stage-1 és Stage-2 jogosultságok metszetét érvényesíti, a hardver pontos 4 KB-os határokon csapdába ejti a jogosultsági hibákat.
• Rendszerhívás-csapda: A vendég EL0 SVC #0 az EL1 VBAR_EL1-hez kerül, a regisztereket a megosztott 4 KB-os CommPage-be menti, és végrehajtja a HVC #0 utasítást, hogy a hv_vcpu_run függvényből visszatérjen a Go Sentry szálhoz.

3. Windows felhasználói módú tartalék: platform/systrap (winsystrap)

Ha a hardveres virtualizáció nem érhető el (például beágyazott felhőgépeken), a winsystrap a vendégkódot felhasználói módban futtatja windows/amd64 és windows/arm64 esetén:

• Hardveres CR3 / TTBR0_EL1 izoláció: A vendégszálak izolált csonk-alfolyamatokban futnak, amelyeket egy generált 1 KB-os végrehajtható fájlból (stubimage_xplat.go) indítanak, és amelyeket Low-Integrity token és Job Object korlátoz.
• Helyben történő bináris javítás és winSysmsg IPC: amd64 esetén a javító (patcher_amd64_xplat.go) a 2 bájtos syscall (0f 05) utasításokat 5 bájtos jmp rel32 ugrásokra cseréli (vagy CC 90 töréspont-csapdákra, ha nem áll rendelkezésre 5 bájtos ablak), amelyek egy gyorsúti szigetre mutatnak. arm64 esetén az svc #0 utasítást egy B elágazással javítja egy szigetrés felé. A sziget a regisztereket a megosztott winSysmsg lapra menti, és a WaitOnAddress és WakeByAddressSingle segítségével szinkronizál a Sentryvel, míg a nem javított csapdák és lapHibák egy Windows Debug Objecten (WaitForDebugEventEx) állnak meg.

4. Linux felhasználói módú motor: platform/systrap

linux/amd64 és linux/arm64 esetén a systrap olyan vendégszálakat (sysmsg) futtat, amelyek a vendég rendszerhívásokat a SECCOMP_RET_TRAP (SIGSYS) segítségével csapdába ejtik, és a syscall helyeket bináris javítással egy SYS_FUTEX-szel szinkronizált, megosztott memóriás trampolinba (sysmsg) irányítják, míg egy csonk syscallThread (syscall_thread.go) a SECCOMP_RET_USER_NOTIF (_RUN_SECCOMP_LOOP) segítségével hajtja végre a címtér-műveleteket (mmap, munmap, clone). Amikor a gvx egy külső gVisor (runsc) sandboxon belül fut, ahol az egyetlen SECCOMP_FILTER_FLAG_NEW_LISTENER hely EBUSY értéket ad vissza, a gvx automatikusan átvált a syscallThread-re egy megosztott memóriás futex ciklusra (_RUN_SYSCALL_LOOP), ahogy azt a sorozat 3. része részletezi.

Hogyan képezi le a gvx a vendég Linux rendszerhívásokat virtuális alrendszerekre és host handle-ökre

Miután a platformmotor elfogta a vendég SYSCALL (amd64) vagy SVC #0 (arm64) utasítást, és a vendég regisztereket a 4 KB-os megosztott lapra (CommPage, sysmsg vagy winSysmsg) írta, a vezérlés visszatér a Go Sentry task goroutine-hoz (pkg/sentry/kernel/task_syscall.go). Ahelyett, hogy a Linux rendszerhívásokat a mögöttes host OS kernelnek továbbítaná, a Task.doSyscall() elmenti az eredeti regiszterállapotot (SyscallSaveOrig()), kiértékeli a vendégen belüli BPF seccomp szűrőket és ptrace megállásokat, majd a linux.AMD64 vagy linux.ARM64 (pkg/sentry/syscalls/linux/linux64.go, mintegy 370 Linux rendszerhívást lefedve) segítségével a rendszerhívás számát négy belső tartományba irányítja:

Amikor a kezelő (rval, ctrl, err) értéket ad vissza, a Task.doSyscallInvoke() minden hibát negatív Linux errno értékké alakít (-ExtractErrno(err, sysno)), visszaírja a visszatérési értéket a megosztott regiszterlapra (amd64-on RAX, arm64-on X0), és folytatja a vendég végrehajtását.

Tárolás (VFS2) és kétsávos felhasználói térbeli hálózat (netstack)

Minden vendég fájl- és hálózati művelet a Go Sentryn belül történik, három VFS2 fájlrendszeren és két pkg/netbackend sávon keresztül:

Miért fontos az ext4lite Docker, adatbázisok és csomagkezelők számára

Tízezer számra menő konténerfájlok kibontása vagy írása közvetlenül Windows NTFS-re vagy macOS APFS-re antivírus minifilter vizsgálatokat (WdFilter.sys), kis- és nagybetű-ütközéseket és hiányzó POSIX bővített attribútumokat eredményez.

A pkg/sentry/fsimpl/ext4lite egy tisztán Go nyelvű ext4 fájlrendszert valósít meg egyetlen előzetesen megnyitott host fájlban (%LOCALAPPDATA%\gvx\cache\volumes\<name>.ext4 Windowson, ~/Library/Caches/gvx/volumes/<name>.ext4 macOS-en vagy ~/.cache/gvx/volumes/<name>.ext4 Linuxon), a következőkkel:

• 4 KiB-os blokkok és 16 MiB-os dinamikus blokkcsoportok (meta_bg): Dinamikusan nő anélkül, hogy ritka fájl allokációs torlódás lépne fel (fallocate Linuxon, fcntl(F_PREALLOCATE) macOS-en, FileAllocationInfo Windowson), és tisztán leválasztáskor tömöríti a használaton kívüli végső csoportokat.
• JBD2 rendezett módú napló (inode 8): Atomi tranzakció-véglegesítés CRC-32 ellenőrző összegekkel és visszavonási blokkokkal, valamint fsckLite helyreállítás.
• overlayfs felső réteg támogatás: Implementálja a trusted.overlay.* és security.capability bővített attribútumokat, a karakter-eszköz törléseket (0:0), a d_type könyvtárbejegyzés-jelentést és a RENAME_EXCHANGE műveletet.

Gyakorlati munkafolyamatok: Docker Engine, Kubernetes (k3s + Calico) és Go SDK

A rungv telepítése: SLSA-attesztált előre fordított kiadások vagy go install

Letölthet egy előre fordított rungv archívumot a linux/amd64, linux/arm64, darwin/arm64, windows/amd64 vagy windows/arm64 platformokhoz a GitHub Releases oldalról (mindegyiket a SLSA kiadási folyamat építette, Sigstore eredetigazoló csomaggal és SHA256SUMS fájllal), vagy közvetlenül telepítheti a forráskódból a go install segítségével:

1# A lehetőség: Előre fordított kiadás letöltése és a SLSA build eredet ellenőrzése
2gh attestation verify rungv-v0.2.0-linux-amd64.tar.gz --repo gfire-sigs/gvx \
3  --signer-workflow gfire-sigs/gvx/.github/workflows/release.yml \
4  --source-ref refs/tags/v0.2.0 --deny-self-hosted-runners
5shasum -a 256 -c SHA256SUMS --ignore-missing
6tar -xzf rungv-v0.2.0-linux-amd64.tar.gz
7
8# B lehetőség: Közvetlen telepítés Go-val (Linux / Windows)
9CGO_ENABLED=0 go install z.gfire.dev/gvx/cmd/rungv@latest

macOS-en (darwin/arm64) az előre fordított kiadási archívum már alá van írva a com.apple.security.hypervisor jogosultsággal (az xattr -d com.apple.quarantine rungv parancs törli a böngészős karantént). Ha helyben, go install vagy go build segítségével építi a binárist macOS-en, írja alá a bináris fájlt a codesign --sign - --entitlements entitlements.plist --force $(which rungv) paranccsal.

1. Jogosultság nélküli Docker Engine futtatása (docker:dind)

A docs/docker-engine.md útmutatót követve egy módosítatlan docker:dind konténert futtathat a rungv alatt Windowson, macOS-en vagy Linuxon, és a host docker CLI-vel vezérelheti:

 1# 1. Hozza létre a host könyvtárat az átirányított Unix socket számára
 2mkdir -p ~/.gvx
 3
 4# 2. Indítsa el a docker:dind konténert egy gvx sandboxban ext4lite kötettel
 5rungv run \
 6  -p unix:~/.gvx/docker.sock:2375 \
 7  -p 127.0.0.1:9000-9019:9000-9019 \
 8  -v gvx-docker:/var/lib/docker \
 9  -e DOCKER_TLS_CERTDIR= \
10  docker:dind --tls=false

Egy második terminálban irányítsa a host docker CLI-t a sandbox socketre:

1docker context create gvx --docker host=unix://$HOME/.gvx/docker.sock
2docker context use gvx
3
4docker info --format '{{.Driver}} {{.OperatingSystem}}'
5# Kimenet: overlayfs Alpine Linux ... (konténerizált)
6
7docker build -t myapp ./app
8docker compose up -d

2. Kubernetes (k3s + Calico) futtatása jogosultság nélküli sandboxokban

Mivel a gvx implementálja a /dev/kmsg, a cgroup v2 eszközt (memory.max OOM gyilkos és cpu.max sávszélesség-korlátozás), a /proc/diskstats, a wireguard és vxlan netlink eszközöket, az ipset-et és az iptables-legacy-t (addrtype, conntrack, statistic, recent), egy módosítatlan rancher/k3s image eléri a Ready állapotot egyetlen rungv folyamaton belül:

 1mkdir -p ~/.gvx/k3s
 2
 3rungv run \
 4  -e IPTABLES_MODE=legacy \
 5  -p 127.0.0.1:6443:6443 \
 6  -p 127.0.0.1:30000-30019:30000-30019 \
 7  -v k3s:/var/lib/rancher \
 8  --mount type=bind,src=$HOME/.gvx/k3s,dst=/output \
 9  rancher/k3s:v1.31.4-k3s1 server \
10  --disable=traefik,servicelb \
11  --write-kubeconfig=/output/kubeconfig.yaml \
12  --write-kubeconfig-mode=644

Több gvx csomópontot is csatlakoztathat WireGuard-on keresztül (flannel-backend=wireguard-native vagy wg0 háló) beágyazott etcd magas rendelkezésre állással, vagy futtathatja a Calico-t (calico-vxlan.yaml a FELIX_IPTABLESBACKEND=Legacy beállítással), hogy a Kubernetes NetworkPolicy szabályokat teljes egészében felhasználói térben érvényesítse.

3. Linux konténerek beágyazása Go-ba a z.gfire.dev/gvx/pkg/gvx csomaggal

Go alkalmazások külső konténerdémon nélkül, közvetlenül beágyazhatnak Linux konténereket:

 1package main
 2
 3import (
 4	"context"
 5	"fmt"
 6	"os"
 7
 8	"z.gfire.dev/gvx/pkg/gvx"
 9)
10
11func main() {
12	ctx := context.Background()
13	sb, err := gvx.New(ctx, gvx.Config{
14		Platform:      gvx.PlatformAuto,
15		NetworkMode:   gvx.NetModeNAT,
16		OCIImage:      "alpine:3.20",
17		WorkspacePath: "./repo",
18		Argv:          []string{"/usr/bin/git", "status"},
19		Stdout:        os.Stdout,
20		Stderr:        os.Stderr,
21	})
22	if err != nil {
23		fmt.Fprintf(os.Stderr, "init sandbox: %v\n", err)
24		os.Exit(1)
25	}
26	defer sb.Close()
27
28	exitCode, err := sb.Run(ctx)
29	if err != nil {
30		fmt.Fprintf(os.Stderr, "run sandbox: %v\n", err)
31		os.Exit(1)
32	}
33	os.Exit(exitCode)
34}

További olvasnivaló ebben a sorozatban

1. gvx: Linux konténerek, Docker és Kubernetes futtatása egyetlen jogosultság nélküli folyamatban (ez a bejegyzés)
2. Docker, docker build és docker compose futtatása root vagy felhasználói névterek nélkül: Hogyan indítsuk el a docker:dind környezetet olyan lezárt sandboxokban, ahol a sudo, unshare(CLONE_NEWUSER), mount(2) és /dev/fuse le van tiltva.
3. Docker-in-Docker futtatása gVisoron belül és beágyazott sandboxokban a gvx segítségével: Miért hibásodik meg az apt-get install docker.io és a beágyazott runsc a gVisor belsejében öt kernelkorláton át, és hogyan futtatja a gvx a beágyazott docker:dind környezetet megosztott memóriás futex ciklussal.
4. Gyors, izolált Docker környezetek AI-ügynökök RL futtatásaihoz a gvx segítségével: SWE-bench és ügynök-megerősítéses tanulási futtatások skálázása több száz párhuzamos, jogosultság nélküli docker:dind példánnyal és 100 milliszekundumos copy-on-write .ext4 kötetvisszaállításokkal.