gvx: Linux Containers, Docker ve Kubernetes'i Tek Bir Unprivileged Process İçinde Çalıştırma

Giriş: Root veya Ana Makine Daemon'ı Gerektirmeden Güvenlik Sertleştirilmiş Konteynerler

Bir geliştirme makinesinde, CI runner'ında veya çok kiracılı bir bulut düğümünde Linux konteynerlerini, docker build komutunu veya Kubernetes'i çalıştırmak genellikle rahatsız edici bir güvenlik ödünleşimine zorlar:

• Linux üzerinde standart OCI çalışma zamanları (runc, crun, runsc), root ayrıcalıkları, ana makinedeki /var/run/docker.sock dosyasının açığa çıkarılması, --privileged (CAP_SYS_ADMIN) veya ana makine çekirdeğinin saldırı yüzeyini genişleten kullanıcı ad alanları (unshare(CLONE_NEWUSER)) gerektirir.
• Windows ve macOS üzerinde konteyner motorları (Docker Desktop, Podman Machine, Lima, OrbStack), WSL2, Hyper-V veya Virtualization.framework içinde tam bir Linux sanal makine çekirdeği başlatır ve bu sanal makine içinde kalıcı bir arka plan daemon'ı çalıştırır.

gvx (rungv CLI ve z.gfire.dev/gvx/pkg/gvx Go SDK), güvenli, sıfır ayrıcalıklı bir alternatif sunar. Google'ın gVisor kullanıcı alanı Linux çekirdeğinin (Sentry) ve kullanıcı alanı ağ yığınının (netstack) upstream ile izlenebilir bir çatalı olarak geliştirilen gvx, Windows, macOS ve Linux üzerinde değiştirilmemiş linux/amd64 ve linux/arm64 ELF64 ikililerini ve OCI konteynerlerini tek bir ayrıcalıksız, kendini kilitleyen ana makine süreci içinde doğrudan çalıştırır.

Güvenlik Garantisi (Üç Halkalı Derinlemesine Savunma): gvx ana makine işletim sistemi güvenlik sınırlarını asla zayıflatmaz, çekirdek sürücüleri asla yüklemez ve ana makinede asla root, sudo, --privileged veya CLONE_NEWUSER gerektirmez. Tek bir konuk talimatını yürütmeden önce gvx, kendi ana makine sürecini Windows Restricted Tokens ve Job Objects, macOS Seatbelt (deny default) veya Linux PR_SET_NO_NEW_PRIVS ile BPF seccomp kullanarak kilitler. Tüm konuk sistem çağrıları, sanal UID 0 ayrıcalıkları, bağlantılar (VFS2) ve ağ tabloları (netstack), bellek güvenli Go Sentry çekirdeği içinde sıkı biçimde sınırlandırılır.

Windows veya macOS üzerinde hiçbir Linux VM çekirdeği başlatılmaz. Ana makinede hiçbir arka plan daemon'ı çalışmaz. Ana makine işletim sistemi üzerinde root, sudo, kullanıcı ad alanları (CLONE_NEWUSER), mount(2), TUN/TAP sürücüleri veya CAP_NET_ADMIN ayrıcalıkları gerekmez. Bu ayrıcalıksız süreç içinde gvx, Docker-in-Docker (docker:dind), docker build, docker compose ve çok düğümlü Yüksek Erişilebilirlikli Kubernetes (k3s ile gömülü etcd ve Calico CNI) çalıştırır.

Konteyner Yaşam Döngüsü ve Üç Halkalı Ana Makine Kilitlemesi

Her gvx sandbox'ı tek bir ayrıcalıksız ana makine süreci içinde çalışır ve üç aşamalı bir yaşam döngüsü uygular: gerekli tüm ana makine dosya tanımlayıcılarını ve soketlerini önceden açmak, pkg/hostlockdown aracılığıyla ana makine işletim sistemi sürecini kilitlemek ve süreç içi Sentry yürütme döngüsüne girmek.

Kontrolü ilk konuk talimatına devretmeden önce gvx, önbelleğe alınmış .erofs imaj katmanı tanımlayıcılarını, .ext4 birim dosya tanımlayıcılarını, /workspace *os.Root tutamacını ve ana makine ağ soketlerini önceden açar, ardından hostlockdown.Apply() fonksiyonunu çağırır:

1. Windows NT (lockdown_windows.go): Ayrıcalıkları yerinde kaldırmak için SE_PRIVILEGE_REMOVED ile AdjustTokenPrivileges çağırır, Low bütünlük seviyesinde (S-1-16-4096) bir DISABLE_MAX_PRIVILEGE kısıtlı taklit (impersonation) belirteci bağlar, süreci JOB_OBJECT_LIMIT_ACTIVE_PROCESS = 1 ile anonim bir Job Object'e atar (herhangi bir alt süreç oluşturulmasını engeller) ve SetProcessMitigationPolicy ile DisallowWin32kSystemCalls = 1 değerini etkinleştirir.
2. macOS XNU (lockdown_darwin.go): RLIMIT_NPROC = 0 değerini ayarlar ve (version 1)(deny default) ile başlayan, process-fork, process-exec* ve yeni tüm ana makine dosya açmalarını engelleyen bir Seatbelt profili (sandbox_init_with_parameters) uygular.
3. Linux (lockdown_linux.go + pkg/gvx/syscallfilter_linux.go): PR_SET_NO_NEW_PRIVS değerini ayarlar ve execve, execveat, clone, openat ve socket için açık EPERM kuralları içeren Sentry BPF seccomp izin listesini tüm iş parçacıklarında (SECCOMP_FILTER_FLAG_TSYNC) kurar.

Platformlar Arası Sistem Çağrısı Yakalama ve 4 KB Sayfalama (pkg/sentry/platform)

Linux ELF64 ikilileri, mmap(MAP_FIXED) segment eşlemeleri için 4 KB (0x1000) bellek sayfa ayrıntı düzeyi varsayar. Ancak Windows VirtualAlloc ve MapViewOfFile3 64 KB (0x10000) hizalaması uygular, Apple Silicon macOS (darwin/arm64) ise 16 KB (0x4000) ana makine sayfaları kullanır. Ayrıca her işletim sistemi, bir Linux VM başlatmadan Linux SYSCALL (amd64) ve SVC #0 (arm64) komutlarını yakalamak için farklı bir mekanizma gerektirir.

gvx, pkg/sentry/platform.Context arayüzünü uygulayan dört yürütme arka ucunda bu iki sorunu çözer:

1. Windows Donanım Motoru: platform/whpx (WinHvPlatform.dll)

windows/amd64 ve windows/arm64 üzerinde platform/whpx, bir konuk işletim sistemi çekirdeği başlatmadan WHvCreatePartition aracılığıyla hafif bir hipervizör bölümü oluşturur:

• 64 KB'den 4 KB'ye Sayfalama Ayrıştırıcısı: whpx, pgalloc.MemoryFile içindeki her 64 MiB arenayı WHvMapGpaRange aracılığıyla bölüme bir kez kaydeder. Sonraki MapFile ve Unmap çağrıları yalnızca bölüm içindeki konuk sayfa tablolarını değiştirir ve Windows'un 64 KB tahsis ayrıntı düzeyine rağmen tam 4 KB R/W/X izinlerini uygular.
• CommPage Üzerinden Sıfır API Kayıt Değişimi:
  • amd64 üzerinde, konuk Ring-3 SYSCALL komutu, bölüm içindeki bir Ring-0 MSR_LSTAR kesim noktasına (stubgen_x86.go) girer; bu kesim noktası hızlı yol sistem çağrısı GPR'lerini (RAX, RDI, RSI, RDX, R10, R8, R9, RIP, RSP) paylaşılan 4 KB CommPage alanına yazar ve WHvRunVirtualProcessor işleminden çıkmak için HLT komutunu yürütür.
  • arm64 üzerinde, konuk EL0 SVC #0 komutu EL1 vektörlerine (stubgen_a64.go) girer, X0..X8, SP_EL0, ELR_EL1, PSTATE değerlerini CommPage alanına yazar ve Sentry'ye bellek çıkışını tetiklemek için sıfır GPA'daki arka planı olmayan adresten yükleme yapar.

2. macOS Donanım Motoru: platform/hvf (Hypervisor.framework)

Apple Silicon (darwin/arm64) üzerinde platform/hvf, konteyner iş parçacıklarını Hypervisor.framework vCPU'ları (hv_vm_create, hv_vcpu_run) içinde çalıştırır:

• Çift Aşamalı 16 KB Üzerinde 4 KB MMU Çevirisi: Aşama 2 (hv_vm_map), 1 GiB bellek dosyası parçalarını Ara Fiziksel Adres (IPA) alanına bir kez, 16 KB ana makine sayfa ayrıntı düzeyinde HV_MEMORY_READ | HV_MEMORY_WRITE | HV_MEMORY_EXEC izinleriyle eşler. vCPU içinde EL1 bluepill kesim noktası (bluepill_arm64.go), TTBR0_EL1 içinde TCR_EL1.TG0 = 0b00 (4 KB granül) değerini yapılandırır ve tam R-X veya RW- (UXN=1) izinlerine sahip 4 KB Aşama 1 sayfa tablosu girişlerini doldurur. ARM64 MMU, Aşama 1 ve Aşama 2 izinlerinin kesişimini uyguladığından, donanım izin hatalarını tam 4 KB sınırlarında yakalar.
• Sistem Çağrısı Tuzağı: Konuk EL0 SVC #0 komutu EL1 VBAR_EL1 değerine tuzaklanır, kayıtları paylaşılan 4 KB CommPage alanına yazar ve Go Sentry iş parçacığına dönmek için hv_vcpu_run içinden HVC #0 komutunu yürütür.

3. Windows Kullanıcı Modu Yedeği: platform/systrap (winsystrap)

Donanım sanallaştırması kullanılamadığında (iç içe bulut VM'lerinde olduğu gibi), winsystrap windows/amd64 ve windows/arm64 üzerinde konuk kodunu kullanıcı modunda çalıştırır:

• Donanım CR3 / TTBR0_EL1 İzolasyonu: Konuk iş parçacıkları, Low bütünlük belirteci ve bir Job Object ile sınırlandırılmış, oluşturulmuş 1 KB çalıştırılabilir dosyadan (stubimage_xplat.go) başlatılan izole kesim alt süreçleri içinde çalışır.
• Yerinde İkili Yama ve winSysmsg IPC: amd64 üzerinde yama uygulayıcı (patcher_amd64_xplat.go), 2 baytlık syscall (0f 05) komutlarını 5 baytlık jmp rel32 atlamalarıyla (5 baytlık pencere kullanılamadığında CC 90 kesme noktası tuzakları ile) hızlı yol adasına değiştirir. arm64 üzerinde svc #0, bir ada yuvasına B dallanmasıyla yamalanır. Ada, kayıtları paylaşılan winSysmsg sayfasına yazar ve WaitOnAddress ile WakeByAddressSingle aracılığıyla Sentry ile senkronize olur; yamalanmamış tuzaklar ve sayfa hataları ise bir Windows Debug Object (WaitForDebugEventEx) üzerinde durdurulur.

4. Linux Kullanıcı Modu Motoru: platform/systrap

linux/amd64 ve linux/arm64 üzerinde systrap, konuk iş parçacıklarını (sysmsg) çalıştırır; bu iş parçacıkları konuk sistem çağrılarını SECCOMP_RET_TRAP (SIGSYS) ile yakalar ve syscall noktalarını SYS_FUTEX ile senkronize edilen paylaşılan bellekli bir sıçrama alanına (sysmsg) ikili yama ile yönlendirir. Bu sırada bir kesim syscallThread (syscall_thread.go) iş parçacığı, adres alanı işlemlerini (mmap, munmap, clone) SECCOMP_RET_USER_NOTIF (_RUN_SECCOMP_LOOP) aracılığıyla yürütür. gvx, tek SECCOMP_FILTER_FLAG_NEW_LISTENER yuvasının EBUSY döndürdüğü dış bir gVisor (runsc) sandbox'ı içinde çalıştığında, syscallThread iş parçacığını otomatik olarak paylaşılan bellekli futex döngüsüne (_RUN_SYSCALL_LOOP) geçirir; ayrıntılar bu serinin 3. bölümünde anlatılmaktadır.

gvx'in Konuk Linux Sistem Çağrılarını Sanal Alt Sistemlere ve Ana Makine Tutamaçlarına Eşlemesi

Bir platform motoru konuk SYSCALL (amd64) veya SVC #0 (arm64) komutunu yakaladıktan ve konuk kayıtlarını 4 KB paylaşılan sayfaya (CommPage, sysmsg veya winSysmsg) yazdıktan sonra kontrol, Go Sentry görev goroutine'ine (pkg/sentry/kernel/task_syscall.go) döner. Linux sistem çağrılarını altta yatan ana makine işletim sistemi çekirdeğine iletmek yerine Task.doSyscall(), özgün kayıt durumunu (SyscallSaveOrig()) kaydeder, konuk içi BPF seccomp filtrelerini ve ptrace duraklamalarını değerlendirir ve sistem çağrısı numarasını linux.AMD64 veya linux.ARM64 aracılığıyla (pkg/sentry/syscalls/linux/linux64.go, yaklaşık 370 Linux sistem çağrısını kapsar) dört iç alana yönlendirir:

Işleyici (rval, ctrl, err) döndürdüğünde Task.doSyscallInvoke(), herhangi bir hatayı negatif bir Linux errno değerine dönüştürür (-ExtractErrno(err, sysno)), dönüş değerini paylaşılan kayıt sayfasına yazar (amd64 üzerinde RAX, arm64 üzerinde X0) ve konuk yürütmeyi devam ettirir.

Depolama (VFS2) ve İki İzli Kullanıcı Alanı Ağı (netstack)

Tüm konuk dosya ve ağ işlemleri Go Sentry içinde üç VFS2 dosya sistemi ve iki pkg/netbackend izi aracılığıyla yürütülür:

ext4lite'ın Docker, Veritabanları ve Paket Yöneticileri İçin Neden Önemli Olduğu

On binlerce konteyner dosyasını doğrudan Windows NTFS veya macOS APFS üzerine çıkarmak veya yazmak; antivirüs minifilter taramalarını (WdFilter.sys), büyük-küçük harf duyarlılığı çakışmalarını ve eksik POSIX genişletilmiş öznitelikleri tetikler.

pkg/sentry/fsimpl/ext4lite, önceden açılmış tek bir ana makine dosyasının (Windows'ta %LOCALAPPDATA%\gvx\cache\volumes\<name>.ext4, macOS'ta ~/Library/Caches/gvx/volumes/<name>.ext4 veya Linux'ta ~/.cache/gvx/volumes/<name>.ext4) içinde saf Go ile yazılmış bir ext4 dosya sistemi uygular ve şunları içerir:

• 4 KiB blok ve 16 MiB dinamik blok grupları (meta_bg): Seyrek dosya tahsisi duraklamaları olmadan dinamik olarak büyür (Linux'ta fallocate, macOS'ta fcntl(F_PREALLOCATE), Windows'ta FileAllocationInfo) ve temiz ayırmada kullanılmayan sondaki grupları sıkıştırır.
• JBD2 sıralı mod günlüğü (inode 8): CRC-32 sağlama toplamları ve iptal blokları ile atomik işlem commit'leri, ayrıca fsckLite kurtarması.
• overlayfs üst katman desteği: trusted.overlay.* ve security.capability genişletilmiş öznitelikleri, karakter aygıtı silme işaretleri (0:0), d_type dizin girdisi raporlaması ve RENAME_EXCHANGE uygular.

Uygulamalı İş Yükleri: Docker Engine, Kubernetes (k3s + Calico) ve Go SDK

rungv'nin Kurulumu: SLSA ile Doğrulanmış Hazır Sürümler veya go install

linux/amd64, linux/arm64, darwin/arm64, windows/amd64 veya windows/arm64 için hazır bir rungv arşivini GitHub Releases adresinden indirebilirsiniz (her biri Sigstore kaynak paketi ve SHA256SUMS ile SLSA sürüm hattı tarafından oluşturulmuştur) veya doğrudan kaynaktan go install ile kurabilirsiniz:

1# Seçenek A: Hazır bir sürümü indirin ve SLSA derleme kaynağını doğrulayın
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# Seçenek B: Go ile doğrudan kurun (Linux / Windows)
9CGO_ENABLED=0 go install z.gfire.dev/gvx/cmd/rungv@latest

macOS (darwin/arm64) üzerinde hazır sürüm arşivi zaten com.apple.security.hypervisor yetkisiyle imzalanmıştır (xattr -d com.apple.quarantine rungv komutu tarayıcı karantina işaretini temizler). macOS üzerinde go install veya go build ile yerel olarak derlerseniz, ikiliyi codesign --sign - --entitlements entitlements.plist --force $(which rungv) komutuyla imzalayın.

1. Ayrıcalıksız Bir Docker Engine Çalıştırma (docker:dind)

docs/docker-engine.md belgesini takip ederek, Windows, macOS veya Linux üzerinde rungv içinde değiştirilmemiş bir docker:dind konteyneri çalıştırabilir ve ana makinedeki docker CLI ile kontrol edebilirsiniz:

 1# 1. İletilen Unix soketi için ana makine dizinini oluşturun
 2mkdir -p ~/.gvx
 3
 4# 2. ext4lite birimiyle bir gvx sandbox içinde docker:dind'i başlatın
 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

İkinci bir terminalde, ana makinedeki docker CLI'ı sandbox soketine yönlendirin:

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

2. Ayrıcalıksız Sandbox'larda Kubernetes (k3s + Calico) Çalıştırma

gvx, /dev/kmsg, cgroup v2 (memory.max OOM öldürücüsü ve cpu.max bant genişliği kısıtlaması), /proc/diskstats, wireguard ve vxlan netlink aygıtları, ipset ile iptables-legacy (addrtype, conntrack, statistic, recent) özelliklerini uyguladığı için, değiştirilmemiş bir rancher/k3s imajı tek bir rungv süreci içinde Ready durumuna ulaşır:

 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

Ayrıca birden fazla gvx düğümünü WireGuard üzerinden (flannel-backend=wireguard-native veya bir wg0 ağı) gömülü etcd yüksek erişilebilirliği ile birleştirebilir ya da Kubernetes NetworkPolicy kurallarını tamamen kullanıcı alanında uygulamak için Calico (calico-vxlan.yaml ile FELIX_IPTABLESBACKEND=Legacy) çalıştırabilirsiniz.

3. z.gfire.dev/gvx/pkg/gvx ile Go'da Linux Konteynerlerini Gömme

Go uygulamaları, harici bir konteyner daemon'ı olmadan Linux konteynerlerini doğrudan gömebilir:

 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}

Bu Serinin Devamı

1. gvx: Tek Bir Ayrıcalıksız Süreçte Linux Konteynerlerini, Docker'ı ve Kubernetes'i Çalıştırma (bu yazı)
2. Root veya User Namespace Olmadan Docker, docker build ve docker compose Çalıştırma: sudo, unshare(CLONE_NEWUSER), mount(2) ve /dev/fuse erişiminin engellendiği kilitli sandbox'larda docker:dind nasıl başlatılır.
3. gvx ile gVisor ve İç İçe Sandbox'lar İçinde Docker-in-Docker Çalıştırma: apt-get install docker.io komutu ve iç içe runsc neden gVisor içinde beş çekirdek engelinde başarısız olur ve gvx, paylaşılan bellekli futex döngüsünü kullanarak iç içe docker:dindi nasıl çalıştırır.
4. gvx ile AI Ajanı RL Rollout'ları için Hızlı İzole Docker Ortamları: Yüzlerce paralel ayrıcalıksız docker:dind örneği ve 100 milisaniyelik kopyala-yazma .ext4 birim sıfırlamaları ile SWE-bench ve ajan pekiştirmeli öğrenme rollout'larını ölçeklendirme.