{"uuid": "428d72ff-62a6-4103-90e6-390dfee30e7b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-53359", "type": "seen", "source": "https://gist.github.com/mherrera782-rgb/259992523a664f7f49b2364767207041", "content": "---\ntitle: \"Thelio Mira Multi-Tenant Client VM Hosting - Phase 1 Pablo Independent Research\"\ntask_slug: \"THELIO-MULTITENANT-RD-P1\"\nauthor: \"Senor Pablo\"\ncreated_at_utc: \"2026-09-12T16:13:26Z\"\nphase: \"Joint R&D Rigor Phase 1\"\nstatus: \"independent findings, not final policy\"\n---\n\n# Thelio Mira Multi-Tenant Client VM Hosting - Phase 1 Pablo Independent Research\n\n## 0. Boundary\n\nThis is an independent Phase 1 research packet for the standing policy question:\n\n> Thelio Mira multi-tenant client-VM hosting: durable isolation-management architecture and policy.\n\nIt is not implementation authority. It does not authorize VM creation, runtime/config changes, service changes, bridge changes, source activation, credential movement, client onboarding, or production hosting. Later phases should compare this with CF and Fable-5 findings before hardening into a Matthis-facing policy.\n\nMy evidence should be treated as current as of 2026-09-12. Where vendor docs were scraped live, I cite them directly. Where search summaries were used, I label them as lower confidence.\n\n## 1. Bottom Line\n\nThe strongest near-term policy is not \"install one VM per client and call it isolated.\" It is a small multi-tenant hypervisor operating policy with admission gates, patch gates, per-tenant network/storage/control-plane separation, and explicit residual-risk disclosure.\n\nFor Thelio Mira, the practical strongest path is:\n\n1. Continue with KVM/libvirt only if it is wrapped in a durable host admission checklist and per-tenant build template.\n2. Require host-native kernel/CVE verification before any client VM is admitted.\n3. Put every client VM on a separate virtual network or bridge, never shared `virbr0`.\n4. Disable or remove convenience channels: guest Tailscale, shared folders, qemu guest agent, clipboard, virtiofs/9p, ballooning, KSM, broad serial/log sharing.\n5. Treat the host/hypervisor as trusted by design, because Ryzen 9 9950X3D-class consumer hardware does not provide AMD SEV-SNP confidential VM isolation.\n6. Use a \"cloud-API-only\" rule for OpenClaw clones and client agents unless a separate GPU/isolation design is authorized.\n7. Adopt patch automation and monitoring as a gate, not a best-effort hygiene note.\n\nProxmox VE is worth serious consideration if Matthis wants Thelio Mira to become a recurring client-VM host rather than a one-off workstation running a few VMs. Proxmox adds a real management plane, roles, pools, VM firewalling, backup semantics, and SDN concepts that raw libvirt will otherwise require Pablo/CF to recreate by convention. OpenStack is too heavy for a single workstation-scale host. Firecracker/crosvm are worth watching for future narrow Linux agent sandboxes, but they are not a clean replacement for ordinary full-OS client VMs this week.\n\n## 2. YT Corpus Preflight\n\n```yaml\nYT_CORPUS_PREFLIGHT:\n  query_terms:\n    - multi-tenant\n    - hypervisor\n    - KVM\n    - VM escape\n    - Proxmox\n    - OpenStack\n    - Firecracker\n    - crosvm\n    - Livepatch\n    - libvirt\n  corpus_last_ingest:\n    date: 2026-07-15\n    generated_at_utc: \"2026-07-16T03:00:54.640118+00:00\"\n    source_path: \"docs/youtube/nightly-catchup/2026-07-15/youtube-catchup-manifest.json\"\n  result: NO_MATCH\n  matches: []\n  unsurfaced_match_count: 0\n  caveat: \"Corpus items are curated creator content - prior context, not verified evidence.\"\n```\n\n## 3. Phase 1 Brainstorm Evidence\n\n```yaml\nphase_1_brainstorm_evidence:\n  brainstorm_required: true\n  brainstorm_protocol_completion: true\n  brainstorm_mode: full\n  task_class: \"Hardware / Infra + Protocol / Governance\"\n  method_lenses:\n    - decision_matrix\n    - assumption_storming\n    - pre_mortem\n    - adversarial_security_review\n  divergent_generation:\n    competing_threads:\n      - \"Raw KVM/libvirt with strict Pablo-authored policy templates and verification gates.\"\n      - \"Proxmox VE as small-ops virtualization management plane.\"\n      - \"OpenStack/Nova/Neutron as cloud-like tenant model.\"\n      - \"Firecracker/crosvm microVMs for future lightweight Linux-only agent sandboxes.\"\n      - \"Separate physical hardware for higher-assurance client isolation.\"\n      - \"Hosted cloud confidential-compute alternative for clients needing stronger hardware-backed isolation.\"\n    alternative_framings:\n      - \"This is less a clone-install problem than a tenant admission-control problem.\"\n      - \"VM isolation is an operating discipline, not a one-time topology.\"\n      - \"Cloud providers accept residual hypervisor risk, but they pair it with fleet patching, detection, hardware choices, and abuse controls.\"\n    failure_modes_or_tensions:\n      - \"A VM exists but is attached to shared NAT/default L2, leaking hostnames or exposing broadcasts.\"\n      - \"Patch automation installs a fixed kernel package but the host has not rebooted into it.\"\n      - \"Guest convenience features silently create host-guest channels.\"\n      - \"A client interprets 'isolated' as host-admin-proof confidential computing.\"\n      - \"An agent clone is isolated at filesystem level but shares Discord bridge, model key, or tailnet visibility.\"\n      - \"A single-host design accumulates too much manual state to audit under time pressure.\"\n  known_unknowns:\n    open_questions:\n      - \"What exact Ubuntu release/kernel/package stream will Thelio Mira run as the KVM host?\"\n      - \"Will Matthis give any client direct VM console or SSH access, or are all client VMs agent-operated only?\"\n      - \"Will client data require contractual security language beyond Matthis-owned-risk disclosure?\"\n      - \"Will Thelio Mira remain a workstation with Sunshine/desktop workload, or become a dedicated client-VM host?\"\n    visibility_limits:\n      - \"Current local shell is WSL and cannot certify Thelio Mira bare-metal kernel, libvirt state, CPU topology, KSM, AppArmor, or VM configuration.\"\n      - \"No CF/Fable-5 independent packet was read before authoring this Phase 1 artifact.\"\n  convergence_boundary:\n    conclusions_deferred: true\n    cross_analysis_or_design_deferred_to_later_phase: true\n```\n\n## 4. Research Threads\n\n### Thread A - Threat Model And Honest Isolation Language\n\nClient VMs on one host can be strongly separated from each other by KVM, per-VM QEMU processes, mandatory access control, virtual network separation, per-disk file permissions, resource quotas, and patch discipline. They cannot be honestly described as \"totally isolated\" in the physical or hypervisor-compromise sense.\n\nThe honest language should be:\n\n> Thelio Mira provides hardened logical VM isolation on Matthis-owned shared hardware. The host/hypervisor remains a trusted component. A host compromise, hypervisor escape, firmware compromise, malicious administrator action, or severe hardware side channel can break tenant isolation.\n\nThis is similar in category to public-cloud multi-tenancy, but not equal in assurance. AWS/GCP/Azure pair shared-host virtualization with dedicated security teams, custom hardware/firmware chains, confidential computing SKUs, fleet-wide telemetry, live migration, automated patch rollouts, and formal incident processes. Thelio Mira can borrow operating patterns, not claim cloud-provider-grade guarantees.\n\nPolicy implication: every client admission should classify whether \"host owner can technically access or disrupt the VM\" is acceptable. If not, Thelio Mira is the wrong substrate; use dedicated hardware or cloud confidential compute.\n\n### Thread B - KVM/Libvirt Baseline\n\nRaw KVM/libvirt is a viable substrate only if we make implicit host controls explicit. The required baseline is:\n\n- one tenant/client per VM unless Matthis explicitly accepts same-client grouping\n- no shared libvirt `default` network for unrelated clients\n- one virtual network/bridge per tenant, with no L2 sharing between tenants\n- no guest VPN/tailnet membership by default\n- no host-shared folders, virtiofs, 9p, shared clipboard, broad virtio-serial, qemu guest agent, or SPICE convenience channels\n- AppArmor/sVirt confinement enabled and verified per QEMU process\n- QEMU running unprivileged under the distro libvirt user model\n- KSM disabled and masked\n- memory ballooning disabled for client VMs\n- fixed memory reservations; avoid overcommit for client workloads\n- CPU topology policy: avoid cross-tenant SMT sibling sharing, or disable SMT/core-schedule if threat model requires it\n- nested virtualization disabled unless a client workload explicitly requires it and Matthis accepts increased risk\n- `/dev/kvm` limited to trusted virtualization users/groups, not world-writable\n- separate VM images, backup targets, serial logs, cloud-init seed ISOs, and metadata\n- separate secrets, model-provider keys/projects, Discord bot identities, and bridge scope\n\nLibvirt can do most of this, but it does not force Pablo/CF to remember it. That is the danger. If raw libvirt stays the approach, Thelio Mira needs a \"client VM admission checklist\" plus machine-readable config audit script before first client launch.\n\n### Thread C - Proxmox VE As Small-Ops Management Plane\n\nProxmox VE is the most plausible alternative to hand-managed libvirt for a single-node or small-node client VM host. It provides a web/API management plane over KVM/QEMU, storage, backup, firewall, permissions, and SDN concepts. The attractive part is not magic isolation; it is that tenancy controls become visible objects: users/groups, pools, network definitions, VM firewall flags, backup jobs, and storage allocation.\n\nLikely advantages:\n\n- resource pools and ACLs reduce accidental cross-tenant operator access\n- SDN/VLAN/VXLAN/VNet concepts make per-tenant network separation less ad hoc\n- VM firewall and anti-spoofing settings are first-class operational controls\n- snapshots/backups are native operational concepts\n- easier audit/readback for \"which VM belongs to which tenant\"\n- better fit if Matthis expects recurring VM lifecycle work\n\nLikely costs:\n\n- changes the host operating model and may conflict with Thelio Mira workstation/desktop-stack goals\n- adds a large management plane that itself needs patching and access control\n- may require reinstall/migration or careful coexistence decisions\n- web UI exposure becomes a new attack surface if not tailnet/localhost/admin-only\n- still not confidential computing; hypervisor remains trusted\n\nPreliminary position: adopt/watch. Proxmox is worth a decision gate if Thelio Mira is truly becoming a standing client-VM host. It is too big to casually install as a side effect of clone provisioning.\n\n### Thread D - OpenStack Nova/Neutron\n\nOpenStack has the right conceptual model for multi-tenant VM hosting: projects, RBAC, Nova placement, Neutron networks/security groups, host aggregates, provider network RBAC, anti-spoofing, and cloud-style operational separation. It also has the wrong scale for this immediate problem.\n\nOpenStack makes sense when the operational goal is a cloud with multiple compute nodes, API-driven tenant self-service, live migration, image services, block/object storage, quotas, and mature operator staffing. Thelio Mira is a single workstation-class host with desktop-stack work landing in parallel. Running OpenStack to protect one or a few local client VMs likely creates more failure modes than it removes.\n\nPreliminary position: skip for Thelio Mira Phase 1/2. Borrow concepts: projects/tenants, network RBAC, security groups, host aggregate ideas, anti-spoofing, and explicit compute placement. Do not deploy OpenStack.\n\n### Thread E - Firecracker / Crosvm / MicroVMs\n\nFirecracker is built for secure, multi-tenant function/container-style services. Its own docs say it is purpose-built for secure multi-tenant container and function services, uses KVM, has a minimal device model, supports very low VM overhead, includes a jailer, applies seccomp filters, cgroups, namespaces, and rate limiting, and expects host-level network filtering. It is an alternative to general-purpose QEMU for narrow Linux workloads.\n\nImportant source facts:\n\n- Firecracker is \"purpose-built for creating and managing secure, multi-tenant container and function-based services.\"\n- It exposes only a minimal device model and is written in Rust.\n- Production use should start Firecracker via the `jailer`.\n- It explicitly says it does not perform network filtering and guest egress should be filtered at the host level.\n- Each Firecracker process encapsulates one microVM.\n\nThis is attractive for future OpenClaw worker/agent sandboxes if we can standardize immutable images and API-driven boot. It is not a drop-in replacement for full client Ubuntu desktops or arbitrary VMs. It also adds a custom image-building and orchestration problem.\n\nCrosvm has similar minimal-VMM appeal, but Firecracker has stronger production proof in serverless/container multi-tenancy and clearer public docs for jailer/seccomp/resource limits.\n\nPreliminary position: watch/pilot later for narrow Linux agent runtimes. Do not block current Thelio Mira client VM policy on adopting microVMs.\n\n### Thread F - Patch Management And VM Escape Reality\n\nThe Januscape/CVE pair makes the guest-to-host risk concrete. Ubuntu tracks CVE-2026-53359 as a High priority, CVSS 8.8, \"guest to host escape in KVM,\" fixed for Ubuntu 26.04 generic `linux` at `7.0.0-29.29` and Ubuntu 24.04 generic `linux` at `6.8.0-137.137`; patch detail references `81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb`. Ubuntu tracks CVE-2026-46113 as CVSS 8.8 for KVM shadow paging UAF, fixed for Ubuntu 26.04 generic `linux` at `7.0.0-28.28` and 24.04 generic `linux` at `6.8.0-136.136`, with patch `0cb2af2ea66ad8ff195c156ea690f11216285bdf`.\n\nGoogle's kvmCTF rules are also useful calibration: Google pays up to $250,000 for full KVM VM escapes, $100,000 for arbitrary memory writes, $50,000 for arbitrary memory reads, and $20,000 for host DoS. That is not compliance theater. It is a live research market around exactly this boundary.\n\nThe policy should separate three patch states:\n\n- `SAFE_TO_ADMIT`: running kernel and installed kernel packages meet current CVE floor; no reboot-required mismatch; libvirt/qemu package status current.\n- `PATCHED_ON_DISK_ONLY`: fixed kernel package installed but host has not rebooted; no new client VM admission.\n- `UNKNOWN_OR_VULNERABLE`: cannot prove fixed version; no new client VM admission.\n\nCanonical Livepatch should be considered an exposure-window reducer, not a reboot substitute. Ubuntu's Livepatch page says it patches high/critical kernel vulnerabilities while the system runs and reduces unplanned work; it also says Livepatch is not a replacement for upgrade and reboot. Ubuntu unattended-upgrades applies security updates automatically and has explicit reboot and service restart behavior, including default `Automatic-Reboot \"false\"`.\n\nPreliminary patch policy:\n\n- enable security unattended-upgrades, but no automatic host reboot\n- enable Ubuntu Pro Livepatch if license/accounting is acceptable\n- monitor livepatch status, `/var/run/reboot-required`, installed-vs-running kernel, qemu/libvirt pending restarts, and Ubuntu CVE status for KVM packages\n- set a hard maximum exposure SLA for High/Critical KVM guest-host CVEs\n- require scheduled reboot maintenance when Livepatch cannot cover a CVE or when fixed packages are only installed on disk\n\n## 5. Tooling And Platform Candidate Scan\n\n### Raw KVM/libvirt\n\nLicense/maturity: mature OSS, standard Linux virtualization stack.\n\nIntegration cost: low near-term, high policy burden.\n\nAdopt/watch/skip: adopt only with policy wrapper and audit script.\n\nWhy: best near-term compatibility; weak default ergonomics for recurring multi-tenant operation.\n\n### Proxmox VE\n\nLicense/maturity: mature OSS/commercial support ecosystem.\n\nIntegration cost: medium to high depending on whether Thelio Mira can become Proxmox-first rather than Ubuntu-desktop-first.\n\nAdopt/watch/skip: watch/decision-gate; possible adopt if Matthis wants recurring VM hosting.\n\nWhy: turns tenant resources, backups, firewalling, pools, and permissions into visible managed objects.\n\n### OpenStack\n\nLicense/maturity: mature OSS cloud platform.\n\nIntegration cost: very high.\n\nAdopt/watch/skip: skip for single-host Thelio Mira; borrow concepts only.\n\nWhy: right abstraction at wrong scale.\n\n### Firecracker\n\nLicense/maturity: Apache 2.0, production lineage via AWS Lambda/Fargate class services.\n\nIntegration cost: medium/high because it requires image, network, jailer, API, and lifecycle tooling.\n\nAdopt/watch/skip: watch/pilot later for narrow Linux API-agent sandboxes.\n\nWhy: excellent attack-surface story for small Linux microVMs; not a general VM/desktop replacement.\n\n### Crosvm\n\nLicense/maturity: mature in ChromiumOS/ChromeOS virtualization lineage.\n\nIntegration cost: medium/high, fewer obvious small-ops recipes than libvirt/Proxmox.\n\nAdopt/watch/skip: watch.\n\nWhy: useful reference point for minimal VMM design; Firecracker looks more directly relevant for multi-tenant agent workloads.\n\n### Ubuntu Pro Livepatch\n\nLicense/maturity: Canonical product, mature.\n\nIntegration cost: low if Ubuntu Pro account/token available.\n\nAdopt/watch/skip: adopt candidate for hypervisor host, subject to Matthis account/license decision.\n\nWhy: reduces urgent reboot pressure for high/critical kernel CVEs but does not replace reboots.\n\n### Canonical Landscape\n\nLicense/maturity: Canonical systems management.\n\nIntegration cost: medium.\n\nAdopt/watch/skip: watch unless Thelio Mira grows into several hosts.\n\nWhy: overkill for one host but useful if patch/compliance reporting becomes a client-facing obligation.\n\n## 6. Phase 1 Toolkit Audit\n\n### Toolkit Inventory\n\n```yaml\ntoolkit_inventory:\n  local_shell_inventory: partial\n  reason: \"Current Pablo shell is WSL; cannot certify Mira bare-metal host.\"\n  web_search: strong\n  firecrawl_scrape: strong\n  pablo_joint_rd_rigor_skill: strong\n  clone_provisioning_skill: strong\n  clone_service_safety_skill: strong\n  current_libvirt_host_access: missing\n  host_native_kernel_readback: missing\n  host_native_libvirt_readback: missing\n  vm_config_audit_script: missing\n  per_tenant_manifest_template: missing\n  patch_sla_monitor: missing\n  CVE_floor_registry: missing\n  backup_restore_test_fixture: missing\n```\n\n### Gap / Cost Analysis\n\n```yaml\ngap_cost_analysis:\n  - gap: \"No host-native Mira evidence surface in current Pablo shell.\"\n    cost: \"Low if Matthis/CF can run read-only host commands; high if access path remains unclear.\"\n    risk_if_open: \"False security claims and wrong sizing/gating.\"\n  - gap: \"No durable client VM admission checklist.\"\n    cost: \"Medium documentation plus command-readback schema.\"\n    risk_if_open: \"Ad hoc VM creation misses a bridge, shared folder, qga, KSM, or patch gate.\"\n  - gap: \"No automated libvirt/domain/network audit.\"\n    cost: \"Medium script development and test fixtures.\"\n    risk_if_open: \"Config drift silently weakens tenant isolation.\"\n  - gap: \"No KVM CVE floor monitor.\"\n    cost: \"Medium; combine Ubuntu CVE pages/package versions/reboot-required checks.\"\n    risk_if_open: \"Host admits clients while vulnerable or patched-on-disk-only.\"\n  - gap: \"No client-facing residual-risk disclosure template.\"\n    cost: \"Low/medium; needs Matthis/legal/commercial judgment.\"\n    risk_if_open: \"Overpromising isolation.\"\n  - gap: \"No backup/restore drill policy per tenant.\"\n    cost: \"Medium ongoing operational burden.\"\n    risk_if_open: \"Backups exist but cannot be safely restored or are cross-tenant contaminated.\"\n```\n\n### Needed Enablement\n\n```yaml\nneeded_enablement:\n  - \"THELIO_HOST_READBACK.v1: host-native kernel, CPU topology, RAM, disk, GPU, firmware, KVM/libvirt, AppArmor, KSM, nested virt, qemu package versions.\"\n  - \"CLIENT_VM_ADMISSION_CHECKLIST.v1: pre-admission gates, build constraints, forbidden features, disclosure state, operator signoff.\"\n  - \"CLIENT_VM_CONFIG_AUDIT.v1: read-only script comparing libvirt XML/network definitions against policy.\"\n  - \"KVM_CVE_PATCH_GATE.v1: Ubuntu CVE fixed-version registry plus running/installed kernel comparison.\"\n  - \"TENANT_NETWORK_TEMPLATE.v1: separate libvirt network or bridge per tenant, no default virbr0.\"\n  - \"TENANT_BACKUP_RESTORE_POLICY.v1: separate destinations, encryption ownership, restore drills.\"\n  - \"BRIDGE_SCOPE_AUDIT.v1: ensure Discord/OpenClaw bridges cannot cross tenant boundaries.\"\n```\n\n### Prioritized Gap Registry\n\n```yaml\nprioritized_gap_registry:\n  - rank: 1\n    gap: \"Host-native Mira readback missing.\"\n    owner: \"CF/Matthis/Pablo when proper surface exists\"\n    next_gate: \"CF-AUTH for host-native read-only verification\"\n  - rank: 2\n    gap: \"KVM CVE patch gate missing.\"\n    owner: \"Pablo proposal, CF/Matthis approval\"\n    next_gate: \"Joint Phase 3/4 synthesis\"\n  - rank: 3\n    gap: \"Client VM admission checklist missing.\"\n    owner: \"Pablo/CF co-authored policy\"\n    next_gate: \"Joint Phase 5 Matthis decision\"\n  - rank: 4\n    gap: \"Read-only libvirt isolation audit script missing.\"\n    owner: \"Pablo after CF-AUTH\"\n    next_gate: \"Implementation authorization\"\n  - rank: 5\n    gap: \"Client residual-risk disclosure language missing.\"\n    owner: \"Matthis/CF with Pablo technical input\"\n    next_gate: \"Matthis business/legal judgment\"\n```\n\n## 7. Source Review Forced Adjacency Scan\n\n```yaml\nsource_review_forced_adjacency_scan:\n  methodology:\n    finding: \"Treat VM hosting as admission-control and continuous assurance, not one-time build.\"\n    staged_action: \"Create durable checklist and audit artifact after joint synthesis.\"\n  tooling:\n    finding: \"Raw libvirt needs wrappers; Proxmox may reduce drift for recurring hosting; Firecracker is future-specialized.\"\n    staged_action: \"Decision gate: raw libvirt now vs Proxmox migration/pilot.\"\n  governance:\n    finding: \"Client admission requires explicit residual-risk language and patch gate.\"\n    staged_action: \"Matthis/CF decide client-facing language before onboarding.\"\n  market_structure:\n    finding: \"Cloud providers accept shared-hypervisor risk but compensate with hardware, telemetry, and dedicated security ops.\"\n    staged_action: \"Do not imply cloud-equivalent assurance on Thelio Mira.\"\n  source_discovery:\n    finding: \"Useful ongoing sources: Ubuntu CVE tracker/USNs, kernel stable releases, libvirt/qemu advisories, Google kvmCTF/security-research, Proxmox advisories.\"\n    staged_action: \"Build CVE source list into patch monitor if authorized.\"\n  watch_project_cross_reference:\n    finding: \"Impacts Thelio desktop-stack VM, OpenClaw clone provisioning, Discord bridge scoping, model routing, backup/Drive relay boundaries.\"\n    staged_action: \"Cross-analysis must include these surfaces.\"\n  sme_domain_routing:\n    finding: \"Security SME review should gate implementation.\"\n    staged_action: \"Require Security SME before first client VM if policy becomes operational.\"\n```\n\n## 8. Joint R&D Adjacency Map\n\n```yaml\njoint_rd_adjacency_map_v0:\n  triggered: true\n  trigger_basis: security_governance\n  independent_author: Pablo\n  adjacency_candidates:\n    - surface_name: \"clone-provisioning/SKILL.md\"\n      surface_type: skill\n      direct_effect: \"Future clone readiness must distinguish Matthis-owned clone VMs from client tenant VMs.\"\n      risk_if_missed: \"A client-facing clone could inherit Matthis-owned Option C assumptions.\"\n      confidence: high\n    - surface_name: \"clone-spawning-service-safety/SKILL.md\"\n      surface_type: skill\n      direct_effect: \"Clone services must remain tenant-scoped and never mutate canonical gateway/bridge units.\"\n      risk_if_missed: \"One clone service change could affect another tenant or main Pablo.\"\n      confidence: high\n    - surface_name: \"Discord bridge / OpenClaw bridge configuration\"\n      surface_type: service\n      direct_effect: \"Bridge scope must be per-clone/per-tenant, not globally subscribed.\"\n      risk_if_missed: \"Messaging stream becomes a cross-tenant data path.\"\n      confidence: high\n    - surface_name: \"Thelio desktop-stack runbook\"\n      surface_type: doc\n      direct_effect: \"Desktop VM GPU/Sunshine choices compete with client VM isolation and resource policy.\"\n      risk_if_missed: \"GPU passthrough or remote-access convenience features weaken tenant boundary.\"\n      confidence: medium\n    - surface_name: \"CF_STATUS.md / CF_SESSION_MEMORY task gates\"\n      surface_type: governance\n      direct_effect: \"Client VM admission needs explicit patch/readback gates before build CF-AUTH.\"\n      risk_if_missed: \"Queue movement could look like implementation approval before host safety is proven.\"\n      confidence: high\n  exchanged_at_phase_2: false\n  raw_findings_reference: \"pending_gist\"\n  forbidden_actions:\n    - \"no implementation authority\"\n    - \"no runtime/config/cron/service mutation\"\n    - \"no source activation or scoring/model-feed change\"\n    - \"no portfolio or trading action\"\n```\n\n## 9. Expert In Loop Thread\n\n```yaml\nexpert_in_loop_thread:\n  triggered: true\n  trigger_basis: security\n  reviewed_roles:\n    - Security SME\n    - Authority Reviewer\n  required_gate_role: Security SME\n  implementation_gate: SME_REVIEW_REQUIRED\n  rationale: \"The design affects client data isolation, hypervisor escape risk, host/guest channels, credentials, bridge scoping, and patch gates.\"\n  risk_if_omitted: \"A plausible-looking VM setup could overclaim tenant isolation or miss a known escape/side-channel class.\"\n  forbidden_actions:\n    - \"no implementation before required gate\"\n    - \"no runtime/config/cron/service mutation\"\n    - \"no source activation or scoring/model-feed change\"\n    - \"no portfolio or trading action\"\n```\n\n## 10. Candidate Policy Skeleton For Later Phases\n\nThis skeleton is included as Phase 1 raw material, not a final recommendation.\n\n### Client VM Admission Gate\n\nEach client VM requires:\n\n- client classification: Matthis-owned, internal, client-facing, regulated/sensitive, or high-risk untrusted\n- explicit acceptance of shared-host residual risk\n- host-native kernel and package readback\n- current KVM CVE floor pass\n- no reboot-required mismatch for kernel/qemu/libvirt\n- AppArmor/sVirt pass\n- KSM disabled/masked\n- nested virtualization disabled\n- `/dev/kvm` permissions restricted\n- per-tenant network/bridge pass\n- no default `virbr0` attachment\n- no guest VPN/tailnet unless explicitly justified\n- no qemu guest agent/shared folders/clipboard/virtiofs/9p\n- fixed RAM, no ballooning\n- CPU placement policy pass\n- backup target declared and separated\n- Discord/model/API identity separation where applicable\n\n### Ongoing Assurance\n\nDaily or per-session read-only checks:\n\n- running kernel version\n- installed kernel package candidate\n- reboot-required and reboot-required packages\n- Ubuntu CVE status for KVM/kernel/qemu/libvirt\n- Livepatch status when enabled\n- libvirt VM list and domain XML policy diff\n- network attachment audit\n- KSM state\n- qemu guest agent/channel audit\n- backup freshness\n- failed login/console access log review\n\n### Incident Gate\n\nOn High/Critical KVM guest-to-host CVE:\n\n- freeze new client VM admissions\n- classify running host as patched, patched-on-disk-only, or vulnerable/unknown\n- if livepatch covers it, mark exposure reduced but still schedule reboot if needed\n- if no livepatch or vulnerable running kernel, shut down/suspend client VMs or isolate per Matthis/CF decision\n- document client notification requirement if any client SLA/disclosure requires it\n\n## 11. Recency Check\n\n```yaml\nrecency_check:\n  current_date: \"2026-09-12\"\n  sources:\n    - url: \"https://ubuntu.com/security/CVE-2026-53359\"\n      source_date: \"published 2026-07-04; updated 2026-09-07\"\n      freshness: current\n    - url: \"https://ubuntu.com/security/CVE-2026-46113\"\n      source_date: \"published 2026-05-28; updated 2026-09-07\"\n      freshness: current\n    - url: \"https://ubuntu.com/server/docs/how-to/software/automatic-updates/\"\n      source_date: \"modified 2026-07-15\"\n      freshness: current\n    - url: \"https://ubuntu.com/security/livepatch\"\n      source_date: \"scraped 2026-09-12; page current enough for product posture\"\n      freshness: current\n    - url: \"https://firecracker-microvm.github.io/\"\n      source_date: \"scraped 2026-09-12\"\n      freshness: current\n    - url: \"https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md\"\n      source_date: \"latest visible commit 2026-05-06\"\n      freshness: current\n    - url: \"https://github.com/google/security-research/blob/master/kvmctf/rules.md\"\n      source_date: \"latest visible commit 2026-07-31\"\n      freshness: current\n    - url: \"https://www.amd.com/en/developer/sev.html\"\n      source_date: \"scraped 2026-09-12; page metadata updated 2026-09-08\"\n      freshness: current\n  stale_risk: \"low for cited CVE and vendor product posture; medium for operational advice until validated against Mira host.\"\n```\n\n## 12. What CF Should Challenge\n\n- Whether Proxmox is worth the host-operating-model disruption, or whether raw libvirt plus audit script is sufficient for the next 30 days.\n- Whether \"client-facing\" should always require a client notification/disclosure artifact before admission.\n- Whether no guest Tailscale is too strict for operational recovery.\n- Whether qemu guest agent should be entirely forbidden or allowed in tightly bounded internal-only VMs.\n- Whether memory ballooning and KSM should be globally disabled even for Matthis-owned/non-client VMs to reduce drift.\n- Whether Firecracker deserves an early pilot for OpenClaw clones if they are Linux API-only.\n\n## 13. Silent False Success Modes\n\n- Host has fixed kernel package installed but is still running vulnerable old kernel.\n- VM is on a separate subnet but same L2 bridge/dnsmasq as another tenant.\n- Discord bot token is separate but bridge process subscribes to all channels.\n- VM disk paths are separate but backup job stores all tenant backups in one unsegmented location.\n- AppArmor is installed but libvirt domain profiles are unconfined or permissive.\n- KSM is disabled once but re-enabled after reboot or package/service change.\n- No guest Tailscale is configured, but host-side NAT still allows VM-to-VM routing.\n- qemu guest agent absent at install but later added by template inheritance.\n- CPU pinning exists but ignores SMT sibling topology.\n- Client hears \"isolated VM\" and assumes host-admin-proof confidentiality.\n\n## 14. Sources\n\n- Ubuntu CVE-2026-53359: https://ubuntu.com/security/CVE-2026-53359\n- Ubuntu CVE-2026-46113: https://ubuntu.com/security/CVE-2026-46113\n- Ubuntu automatic updates documentation: https://documentation.ubuntu.com/server/how-to/software/automatic-updates/\n- Ubuntu Livepatch: https://ubuntu.com/security/livepatch\n- Firecracker homepage/docs: https://firecracker-microvm.github.io/\n- Firecracker design doc: https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md\n- Google kvmCTF rules: https://github.com/google/security-research/blob/master/kvmctf/rules.md\n- AMD SEV overview: https://www.amd.com/en/developer/sev.html\n- Proxmox VE administration guide: https://pve.proxmox.com/pve-docs/pve-admin-guide.html\n- OpenStack Security Guide: https://docs.openstack.org/security-guide/\n\n## 15. Phase 1 Closeout\n\n```yaml\nphase_1_closeout:\n  artifact_type: independent_research_packet\n  conclusion_status: preliminary_findings_only\n  recommended_next_phase: \"Phase 2 exchange raw findings; Phase 3 cross-analysis after Drive/Gist relay verification.\"\n  implementation_authority: false\n  runtime_mutation_authority: false\n  client_vm_admission_authority: false\n```\n", "creation_timestamp": "2026-09-12T16:21:16.361270Z"}