Podman rootless कंटेनर और Copy Fail exploit

 (garrido.io)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CVE-2026-31431 Copy Fail लोकल non-privileged यूज़र को root shell दिला सकता है, और Podman rootless container के अंदर भी container के भीतर root privilege escalation संभव है
  • Podman rootless container user namespace, UID isolation, और Linux capabilities के संयोजन से container के भीतर के root को host के non-privileged यूज़र से map करता है और host permissions को सीमित करता है
  • टेस्ट में rootless non-root container के foo यूज़र ने Copy Fail चलाने के बाद container के भीतर root बनना तो संभव किया, लेकिन उसकी permissions host के non-privileged यूज़र bar की सीमा तक ही रहीं, और वह host के root स्वामित्व वाली files नहीं पढ़ सका
  • --security-opt=no-new-privileges या --cap-drop=all लागू करने पर Copy Fail चलने के बाद भी shell foo और capabilities none स्थिति में बना रहा, जिससे तुरंत root shell हासिल करना और capability escalation रोका जा सकता है
  • Copy Fail का प्रभाव container lifecycle से आगे भी बना रह सकता है, इसलिए kernel patch और reboot ज़रूरी हैं, और read-only root filesystem, cgroups resource limits, thin runtime images, firewall जैसे defense in depth उपाय भी साथ में लागू करने चाहिए

Copy Fail और Podman rootless container की exposure range

  • CVE-2026-31431 29 अप्रैल को copy.fail पर सार्वजनिक किया गया था, और प्रकाशित Python script चलाने पर लोकल non-privileged यूज़र root shell प्राप्त कर सकता है
  • Copy Fail का दुरुपयोग Linux container के भीतर भी किया जा सकता है, और Podman rootless container में भी container के भीतर root shell हासिल किया जा सकता है
  • टेस्ट में container का root, host स्तर पर container चलाने वाले non-privileged यूज़र bar की permission सीमा तक सीमित रहा
  • Podman का rootless implementation user namespace, UID isolation, और Linux capabilities के संयोजन से container process की host permissions को सीमित करता है
  • Copy Fail दिखाता है कि rootless container भी vulnerability से पूरी तरह immune नहीं हैं, लेकिन Podman configuration के जरिए compromise के बाद attack surface को कम किया जा सकता है

Rootless container कैसे काम करते हैं

  • बुनियादी उदाहरण: non-privileged यूज़र bar द्वारा HTTP server चलाना

    • उदाहरण environment में UID 1001 वाला non-privileged यूज़र bar, Podman से ubuntu:latest आधारित image build करता है और python3 -m http.server चलाता है
    • Host पर ps से देखने पर python3 process, यूज़र bar के स्वामित्व में चलता दिखता है
    • Podman fork/exec model का उपयोग करता है, इसलिए container process, podman run process की descendant बनती है, और सामान्य UID isolation के जरिए container process को host root या अन्य यूज़र्स से अलग किया जा सकता है
    • सामान्य Docker configuration में non-privileged यूज़र docker run चलाए तब भी Docker client, root-privileged daemon से बात करता है, और daemon ही अंततः container process बनाता है, इसलिए host पर container process root के रूप में दिख सकती है

  • Rootless rootful

    • अगर container image में स्पष्ट USER directive या --user flag न हो, तो आमतौर पर container command भीतर के root के रूप में चलती है
    • podman top output में HTTP server process host user 1001 से map होती है, लेकिन container के भीतर user के रूप में root से चलती है
    • यह configuration host पर non-privileged यूज़र के रूप में चलती है, लेकिन container के भीतर root होती है, यानी rootless rootful स्थिति

  • User namespace

    • Podman rootless container, user namespace का उपयोग करके container के भीतर और बाहर UID/GID को अलग-अलग map करता है
    • उदाहरण में container के भीतर UID 0 वाला root, host के UID 1001 वाले bar से map होता है
    • /etc/subuid में bar:165536:65536 setting, bar के namespace process को आवंटित किए जा सकने वाले UID range को तय करती है
    • उदाहरण में bar के UID 1001 के अलावा 165536 से 231072 तक के UID, bar process को आवंटित किए जा सकते हैं
    • Container के भीतर user www-data के रूप में sleep चलाने पर, भीतर वह www-data रहता है लेकिन host पर 165568 के रूप में दिखता है
    • podman unshare से user namespace में जाने पर, host पर bar:bar स्वामित्व वाली home directory, namespace के भीतर root:root के रूप में दिखती है
    • Docker भी user namespace को support करता है, लेकिन उसके लिए अलग configuration चाहिए और केवल एक user namespace की अनुमति होती है, जबकि Podman प्रत्येक UNIX user के rootless container को उसी user namespace में चलाता है

  • Privileged operations और Linux capabilities

    • Podman, Linux capabilities का उपयोग करके container process को granular root permissions देता है
    • Image build के दौरान apt install जैसे काम, chown, dac_override, fowner, setgid, setuid, net_bind_service, sys_chroot जैसी capability के संयोजन से संभव होते हैं
    • podman build --cap-drop=all से सभी capabilities हटाने पर apt, setgroups, setegid, seteuid, chown आदि में fail हो जाता है और image build असफल हो जाती है
    • केवल ज़रूरी capabilities जोड़ने का तरीका भी संभव है, और उदाहरण में CAP_SETUID,CAP_SETGID,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER जोड़कर package install किया गया
    • डिफॉल्ट runtime state में HTTP server, container के भीतर root के रूप में चलता है और CHOWN,DAC_OVERRIDE,FOWNER,FSETID,KILL,NET_BIND_SERVICE,SETFCAP,SETGID,SETPCAP,SETUID,SYS_CHROOT जैसी कई effective capabilities रखता है
    • HTTP server को इन permissions की ज़रूरत नहीं होती, इसलिए podman run --cap-drop=all से सभी capabilities हटाई जा सकती हैं, और इस स्थिति में podman top में effective capabilities none के रूप में दिखती हैं

  • Rootless non-root

    • अगर container के भीतर भी HTTP server को non-privileged यूज़र के रूप में चलाना हो, तो मौजूदा /etc/passwd के user, जैसे www-data, का उपयोग किया जा सकता है या image build के दौरान dedicated user बनाया जा सकता है
    • उदाहरण में UID 1002 वाला foo user और group बनाया गया, /var/www/html पर read permission दी गई, और फिर USER foo:foo सेट किया गया
    • इस image को --cap-drop=all के साथ चलाने पर process, container के भीतर foo, host UID 166537, और effective capabilities none स्थिति में होती है
    • Container process को न्यूनतम आवश्यक permissions के साथ चलना चाहिए; उदाहरण के लिए अगर foo को privileged port 80 पर bind करना हो, तो --cap-add=CAP_NET_BIND_SERVICE जोड़ना होगा
    • Container execution modes को चार भागों में बाँटा जा सकता है
      • root host user + container root: root rootful
      • root host user + container non-privileged user: root non-root
      • non-privileged host user + container root: rootless rootful
      • non-privileged host user + container non-privileged user: rootless non-root
    • Podman, rootless rootful container चलाना आसान बनाता है, और अगर container process को non-privileged यूज़र के रूप में चलाया जा सके, तो rootless non-root configuration भी अपेक्षाकृत आसानी से बनाई जा सकती है

bind mount और UID isolation

  • होस्ट directory को container में mount करने पर, होस्ट root, होस्ट bar, और namespace foo के स्वामित्व वाली फाइलों तक पहुंच UID mapping के अनुसार बदलती है
  • उदाहरण में /var/lib/bar/test directory में होस्ट root की root.txt और होस्ट bar की bar.txt बनाई जाती हैं, और इन्हें container में /test पर read/write mount किया जाता है
  • container को foo के रूप में चलाने पर, होस्ट bar की फाइल container के अंदर root:root के रूप में दिखती है, जबकि होस्ट root की फाइल namespace में map नहीं होने के कारण nobody:nogroup के रूप में दिखती है
  • container के अंदर foo, bar.txt और root.txt को पढ़ नहीं सकता, और rootless non-root, rootless rootful की तुलना में अतिरिक्त isolation देता है
  • mount की गई directory में foo द्वारा बनाई गई foo.txt होस्ट पर UID 166537 के स्वामित्व वाली दिखती है, और होस्ट user bar उसकी सामग्री पढ़ नहीं सकता
  • container को अंदरूनी root के रूप में चलाने पर namespace root, होस्ट bar की फाइल और foo की फाइल पढ़ सकता है, लेकिन होस्ट root की फाइल नहीं पढ़ सकता
  • अंदरूनी root के रूप में चलाते समय --cap-drop=all लागू करने पर foo की फाइल भी नहीं पढ़ी जा सकती, और केवल होस्ट bar की फाइल पढ़ी जा सकती है

Copy Fail टेस्ट

  • टेस्ट शर्तें

    • Copy Fail टेस्ट में मूल रूप से सार्वजनिक किए गए commit 8e918b5 के exploit version का उपयोग किया गया
    • उदाहरण container image मौजूदा HTTP server image में curl जोड़कर बनाई गई है ताकि container के अंदर exploit script डाउनलोड की जा सके
    • image का नाम copyfail बनाकर build किया गया
    • टेस्ट kernel Debian का 6.12.74+deb13+1-amd64 है, और Debian के मानक के अनुसार हाल के versions में 6.12.85 से कम version को अभी तक patch न किए गए kernel के रूप में उपयोग योग्य माना गया
    • सामान्य तौर पर non-privileged user foo यदि su चलाता है, तो root password मांगा जाता है
    • हर टेस्ट में container user /tmp में Copy Fail script डाउनलोड कर उसे चलाता है, और root shell मिल जाने पर sleep चलाता है
    • Copy Fail container lifecycle के बाद भी बना रहता है, इसलिए हर टेस्ट से पहले VM को reboot किया जाता है

  • rootless rootful में परिणाम

    • --user=root के साथ container चलाने पर container के अंदर process पहले से ही root होता है
    • इस स्थिति में Copy Fail script चलाकर su कॉल करने पर uid=0(root) shell मिलता है, लेकिन root user मूल रूप से भी बिना password के su से दूसरा root shell खोल सकता है, इसलिए Copy Fail व्यावहारिक रूप से कुछ अतिरिक्त नहीं देता
    • podman top में /bin/bash, python3 copy_fail_exp.py, su, sleep सभी container के अंदर root और होस्ट user 1001 के रूप में दिखते हैं
    • वही capability set बना रहता है, और CHOWN,DAC_OVERRIDE,FOWNER,FSETID,KILL,NET_BIND_SERVICE,SETFCAP,SETGID,SETPCAP,SETUID,SYS_CHROOT दिखाई देते हैं
    • अंदरूनी root, mounted /test में bar.txt और foo.txt पढ़ सकता है, लेकिन होस्ट root की root.txt नहीं पढ़ सकता

  • rootless non-root में परिणाम

    • container को foo के रूप में चलाने के बाद Copy Fail script चलाकर su कॉल करने पर container के अंदर root तक privilege escalation हो जाता है
    • परिणाम shell का id uid=0(root) gid=1002(foo) groups=1002(foo) के रूप में दिखता है
    • podman top में शुरुआती /bin/bash, exploit चलाने वाली process, और su कॉल होस्ट UID 166537, container user foo, और capabilities none की स्थिति में दिखते हैं
    • privilege escalation के बाद [sh] और sleep होस्ट user 1001 और container user root के रूप में दिखते हैं, और rootless rootful जैसा ही capability set मिल जाता है
    • privilege escalation के बाद का container root भी होस्ट root की root.txt नहीं पढ़ सकता
    • इस स्थिति में container compromise हो चुका है, लेकिन attack surface container और होस्ट के non-privileged user bar की संभावित पहुंच तक सीमित रहती है

  • no-new-privileges लागू करने पर परिणाम

    • Podman --security-opt=no-new-privileges के जरिए container process को startup समय से अधिक privileges हासिल करने से रोक सकता है
    • rootless non-root container पर यह option लागू करके Copy Fail चलाने पर shell खुलता है, लेकिन वह अब भी uid=1002(foo) की स्थिति में रहता है
    • podman top में भी सभी process होस्ट UID 166537, container user foo, और capabilities none पर बने रहते हैं
    • mounted /test में भी foo केवल अपनी फाइल पढ़ सकता है और bar.txt व root.txt नहीं पढ़ सकता
    • container compromise हुआ है, लेकिन यह अंदरूनी non-privileged user foo और बिना capability वाली स्थिति तक सीमित रहता है

  • --cap-drop=all लागू करने पर परिणाम

    • rootless non-root container को --cap-drop=all के साथ चलाने पर भी foo के पास मूल रूप से कोई capability नहीं होती
    • इस स्थिति में Copy Fail चलाकर su कॉल करने पर खुला हुआ shell uid=1002(foo) पर बना रहता है
    • podman top में भी /bin/bash, exploit execution, su, shell, और sleep सभी foo और capabilities none की स्थिति में दिखते हैं
    • exploit root shell हासिल करने में विफल रहता है, और foo /test में केवल अपनी फाइल पढ़ सकता है
    • यह परिणाम no-new-privileges टेस्ट जैसा है, और दोनों उपायों को साथ में इस्तेमाल करके capability exposure को प्रभावी रूप से कम किया जा सकता है

  • exploit की persistence

    • तुरंत root shell और capability हासिल करना no-new-privileges या --cap-drop=all से रोका जा सका, लेकिन exploit का प्रभाव खुद बना रहता है
    • बाद में यदि capability restriction के बिना नया container चलाया जाए, तो non-privileged container user foo केवल su कॉल करके भी container root बन सकता है
    • इसलिए kernel patch और reboot अब भी आवश्यक हैं

रक्षा-में-गहराई रणनीति

  • केवल-पढ़ने योग्य इमेज

    • podman run में --read-only जोड़ने पर कंटेनर root filesystem केवल-पढ़ने योग्य रूप में mount होता है
    • Podman डिफ़ॉल्ट रूप से /tmp, /run, /var/tmp जैसी कुछ directories को writable mount करता है, इसलिए इसे पूरी तरह केवल-पढ़ने योग्य बनाने के लिए --read-only-tmpfs=false भी जोड़ना होगा
    • यदि केवल-पढ़ने योग्य कंटेनर से समझौता हो जाए, तो सिस्टम पर write operations की अनुमति नहीं होगी, जिससे exploit के बाद कुछ हमलों को सीमित किया जा सकता है
    • हालांकि curl के output को python3 में pipe किया जा सकता है, इसलिए केवल-पढ़ने योग्य सेटिंग अकेले exploit के execution को नहीं रोकती
    • उदाहरण में python3 HTTP server को filesystem write की आवश्यकता नहीं है, इसलिए यह option सुरक्षित रूप से इस्तेमाल किया जा सकता है
    • कई pre-built images कुछ खास directories में write access को मानकर चलती हैं, इसलिए वे केवल-पढ़ने योग्य root filesystem पर सही से काम नहीं कर सकतीं
    • केवल-पढ़ने योग्य root filesystem कंटेनर से जुड़े writable volumes से स्वतंत्र होता है, और compromise होने पर उन mount directories में अब भी लिखा जा सकता है

  • संसाधन सीमाएं

    • Docker और Podman cgroups का उपयोग करके कंटेनर को दिए जाने वाले resources को सीमित कर सकते हैं
    • कंटेनर को unlimited memory, CPU, या PID की ज़रूरत नहीं होती
    • podman stats से कंटेनर resource usage देखकर उसके अनुसार limits लागू की जा सकती हैं

  • उपलब्ध binaries को सीमित करना

    • उदाहरण में सरलता के लिए ubuntu image का उपयोग किया गया है, लेकिन ubuntu image में कई binaries शामिल होती हैं जिनका उपयोग compromise होने पर attacker कर सकता है
    • HTTP server चलाने के लिए इन binaries में से अधिकांश की आवश्यकता नहीं होती
    • runtime image को यथासंभव lean रखना बेहतर है
    • multi-stage build का उपयोग करके build-time environment और runtime environment को अलग किया जा सकता है
    • python3 जैसी purpose-built images, Debian के -slim variants, या alpine जैसी छोटी distributions को base के रूप में इस्तेमाल किया जा सकता है
    • यदि कंटेनर process के साथ compatible हो, तो distroless images या scratch का उपयोग करके shell, package manager, और system utilities के बिना runtime बनाया जा सकता है

  • फ़ायरवॉल

    • iptables या nftables का उपयोग करके कंटेनर process को फ़ायरवॉल से सीमित किया जा सकता है
    • कंटेनर process के लिए केवल वही inbound और outbound connections अनुमति देनी चाहिए जो वास्तव में आवश्यक हों
    • HTTP server उदाहरण में DNS या local/remote server से connection की आवश्यकता नहीं है, इसलिए इसे इस तरह सीमित किया जा सकता है कि केवल स्थापित inbound connections से आने वाले tcp packets ही अनुमत हों

परिचालन संबंधी अर्थ

  • मानक Podman rootless कंटेनर डिफ़ॉल्ट रूप से मानक Docker कंटेनर configuration की तुलना में बेहतर isolation प्रदान करते हैं
  • Docker में भी rootless execution और unprivileged user namespaces का उपयोग संभव है, लेकिन इसके लिए Podman की तुलना में अधिक configuration effort चाहिए और architectural differences भी असर डालते हैं
  • Docker अब भी व्यापक रूप से इस्तेमाल होता है, और Dokku, Kamal, Coolify, Dokploy जैसे self-hosting tools भी डिफ़ॉल्ट रूप से Docker का उपयोग करते हैं
  • यदि Docker Hub images को पर्याप्त रूप से review किए बिना चलाया जाए या lockdown measures लागू न किए जाएं, तो service आवश्यकता से बड़े attack surface के साथ चल सकती है
  • कंटेनर image की implementation details को समझना ज़रूरी है
    • यह समझना चाहिए कि कंटेनर process किस user या किन users के रूप में चलती है
    • यह जानना चाहिए कि कंटेनर process root filesystem की किन directories पर निर्भर करती है
    • आवश्यक Linux capabilities और अनावश्यक capabilities में अंतर करना चाहिए
  • Podman और कंटेनर द्वारा उपलब्ध विभिन्न mechanisms को मिलाकर कंटेनर को harden किया जा सकता है और compromise होने पर blast radius को कम किया जा सकता है
  • workload के आधार पर कंटेनर को अकेली security boundary नहीं मानना चाहिए
  • कंटेनर और अलग physical या virtual machines को साथ में उपयोग करने से प्रभावी isolation मिल सकता है
  • Podman एक ही host के भीतर भी हर workload को अलग unprivileged user और उसके अपने user namespace में चलाकर isolate करने का तरीका देता है

अतिरिक्त सामग्री

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Lobste.rs की राय

  • प्रकाशित exploit से ज़्यादा उस मूल behavior पर ध्यान देना चाहिए जिसे यह vulnerability संभव बनाती है
    यह vulnerability read-only होने या न होने से अलग, page cache में लिखने देती है, इसलिए एक malicious container overlayfs की base image files से जुड़े pages को बदल सकता है, और container deployment के तरीके के हिसाब से इसका असर दूसरे containers तक भी जा सकता है
    यहाँ rootless configuration में, host system पर उसी user के रूप में चल रहे दूसरे containers target बनते हैं
    exploit का एक दूसरा तरीका यह हो सकता है कि किसी ऐसे base image पर आधारित container को चलाया जाए या खोजा जाए जिसके इस्तेमाल में होने की जानकारी हो, फिर उसके अंदर page cache में बदलाव किया जाए, और उसके बाद वही runtime और overlayfs data साझा करने वाले दूसरे containers उस code को चलाएँ
    rootless और user namespaces महत्वपूर्ण हैं, लेकिन यहाँ ज़्यादा मददगार नहीं हैं; और जैसा copy.fail साइट कहती है, containers में seccomp के ज़रिए socket(AF_ALG, ...) system call को block करने पर विचार करना चाहिए

    • मैंने इस मूल behavior तक गहराई से नहीं सोचा था, और ज़्यादा ध्यान rootless containers द्वारा दिए गए namespaces और capabilities को समेटकर compromised container की exposure range का आकलन करने पर दिया था
      “container deployment के तरीके के हिसाब से” से आपका मतलब ठीक-ठीक क्या है, इस पर थोड़ा और स्पष्टीकरण अच्छा रहेगा
      rootless Podman का एक फायदा यह है कि workload के अनुसार host पर उसी user से containers चलाना ज़रूरी नहीं होता
      अगर आप उस स्थिति की बात कर रहे हैं जहाँ मुख्य workstation user के रूप में कई rootless containers चलाए जाते हैं, तो मैं सहमत हूँ; लेकिन servers पर हर container को अलग user के तहत isolate किया जा सकता है, और वही container image अलग-अलग unprivileged users के रूप में भी चलाई जा सकती है
      यह Docker के default से काफ़ी अलग है, जहाँ ज़्यादातर चीज़ें root के रूप में चलती हैं, लेकिन मैंने लेख के अंत में यह भी लिखा था कि यह कोई अंतिम security boundary नहीं है, और rootless containers को कई unprivileged users में बाँटना सही है या नहीं, यह use case पर निर्भर करता है
      कुछ खास workloads को मैं VM में अलग करके चलाता हूँ
      मैं जानना चाहता हूँ कि rootless और user namespaces यहाँ मददगार नहीं हैं, इससे आपका मतलब exploit को रोकने से है या नहीं
      seccomp के लिए मैंने अभी तक containers पर explicit policy नहीं लिखी है, इसलिए इसे कवर नहीं किया, लेकिन यह आगे देखने लायक अच्छा संकेत है

  • मुझे Podman और rootless containers पसंद हैं, लेकिन CopyFail देखने के बाद मैं sibling comment जैसी ही निष्कर्ष पर पहुँचा
    podman+rootless के अतिरिक्त access control फायदों के बावजूद, आखिरकार वही पुरानी सलाह फिर सही साबित हुई कि container कोई security boundary नहीं है, और एक kernel exploit सब कुछ तोड़ सकता है
    मैं सिर्फ़ शौकिया तौर पर systems manage करता हूँ, लेकिन इस क्षेत्र की नई दिशा के रूप में मैंने libkrun backend for crun with podman देखा
    दावा यह है कि यह अधिकांश containerized workloads को वैसे ही संभालता है, लेकिन अंदर से उन्हें एक अलग guest kernel वाले MicroVM में चलाता है; हालाँकि इसकी maturity, production validation, और security audit level के बारे में मुझे पता नहीं, और कुछ चीज़ें काफ़ी cutting-edge लगती हैं
    LLM coding tools में MicroVM को तेज़ी से अपनाया जा रहा है, इसलिए हो सकता है यह स्थिति ज़्यादा समय न रहे
    podman machine भी काफ़ी promising लगा, लेकिन अफ़सोस कि वह सिर्फ़ developer workstation use case को ध्यान में रखकर बना है, और हर host system पर container execution के लिए सिर्फ़ एक VM रखने वाला मॉडल है
    फिर भी, मुझे लगता है “container कोई security boundary नहीं है” कहना कुछ ज़्यादा ही सरल कर देना है। container निश्चित रूप से एक security boundary है, बस उतनी मज़बूत नहीं जितनी हम मानना चाहते हैं

    • ज़्यादातर cloud container deployments में VM होने की वजह भी यही है। VM एक defendable boundary है
      local deployment में यह रेखा थोड़ी धुंधली हो जाती है
      hardware के नज़रिए से VM, process की तुलना में मूल रूप से ज़्यादा सुरक्षित नहीं है, लेकिन तीन कारणों से उसकी boundary को ज़्यादा अच्छी तरह defend किया जा सकता है
      VM escape system calls की तुलना में कम आम है, इसलिए performance को नुकसान पहुँचाए बिना ज़्यादा side-channel mitigations लागू करने की गुंजाइश रहती है
      VM का host interface काफ़ी सरल होता है। block device में block-level read/write interface होता है, और network device frames भेजते और प्राप्त करते हैं
      Linux या *BSD में socket पर मिलने वाला setsockopt call, ज़्यादातर emulation या paravirtualized drivers की तुलना में कहीं बड़ा attack surface है, और वह भी पूरे kernel attack surface का केवल एक बहुत छोटा हिस्सा है
      VM interface में state भी बहुत कम होती है। request-response model वाले ring में in-flight transactions होते हैं, लेकिन उसके अलावा लगभग कुछ नहीं
      credentials, UID, GID, file descriptor tables जैसी चीज़ें kernel में stateful complexity जोड़ती हैं, और bug होने पर process उनका फ़ायदा उठा सकता है
      workstation variant की मुश्किल यह है कि वह यह complexity फिर से वापस ले आता है
      उदाहरण के लिए, container base layer को immutable filesystem वाले block device के रूप में expose किया जा सकता है, लेकिन volumes और shared folders शायद 9pfs या VirtIO-FS, यानी VirtIO के ऊपर 9p या FUSE के रूप में mount होंगे
      इससे attack surface फिर बढ़ जाता है
      अगर किस्मत अच्छी हो, तो exploit chain की ज़रूरत पड़ेगी
      मैं FreeBSD पक्ष से ज़्यादा परिचित हूँ; वहाँ आम तौर पर paravirtualized या emulated devices देने वाले components को Capsicum से sandbox किया जाता है, इसलिए पहले host process पर कब्ज़ा करना पड़ता है, और फिर VM जिन चीज़ों तक पहुँच नहीं रखता था, उन तक पहुँचने के लिए kernel को भी तोड़ना पड़ता है
      लेकिन अगर यह अतिरिक्त sandboxing न हो, तो container escape फिर उसी दुनिया में लौट आता है जहाँ user जो कुछ कर सकता है, वह सब संभव हो जाता है, और desktop पर root compromise होने से यह बहुत बेहतर नहीं रह जाता
    • Kata Containers और Firecracker पहले से ही काफ़ी पुराने technologies हैं, और researchers ने इनकी समीक्षा की है, इसलिए मैं इन्हें उचित रूप से mature मानता हूँ
      व्यक्तिगत रूप से मैं gVisor को ज़्यादा पसंद करता हूँ। यह VMM runtime नहीं है, लेकिन कई सालों से मौजूद है, Tencent जैसी कंपनियाँ भी इसे इस्तेमाल करती हैं, और मेरे setup में जहाँ सारे containers पहले से Proxmox VM के अंदर चलते हैं, यह अच्छा फिट बैठता है
      एक और चीज़ जिसे मैं test कर रहा हूँ, वह है syd-oci, जिसे शायद MicroVM या gVisor जैसी default recommendations की तुलना में थोड़ा कम ध्यान मिला है
    • यह अभिव्यक्ति मेरे अनुभव से भी मेल खाती है, और इस लेख को लिखने की प्रक्रिया भी उस तथ्य को स्वीकार करने का अभ्यास जैसी थी
      libkrun संदर्भ के लिए धन्यवाद, यह एक promising संभावना लगती है
    • LLM coding tools की तरफ़ से तेज़ adoption, MicroVM को और mature बना सकती है, और production validation व hardening तक ले जा सकती है
      security audit तक पहुँचने की संभावना भी काफ़ी लगती है