Linux में Landlock लागू करना

 (blog.prizrak.me)
1 पॉइंट द्वारा GN⁺ 2025-12-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Landlock एक Linux security API है जो किसी एप्लिकेशन को उन संसाधनों को स्पष्ट रूप से घोषित करने देता है जिन तक उसे पहुँच देनी है, ताकि kernel स्तर पर self-sandboxing हो सके।
  • यह मौजूदा SELinux या AppArmor की तुलना में सरल है, और बिना अतिरिक्त प्रशासनिक अधिकार के रनटाइम में नीति (policy) बना कर लागू की जा सकती है।
  • नीति में फाइल, डायरेक्टरी और पोर्ट जैसी पहुँची जा सकने वाली चीजों को स्पष्ट allowlist के रूप में परिभाषित किया जाता है, और hierarchical restriction के जरिए क्रमिक security hardening संभव है।
  • Rust, Go, Haskell आदि के लिए bindings उपलब्ध हैं, जिससे GUI ऐप, सर्वर और डेस्कटॉप प्रोसेस जैसे अलग-अलग environments में fine-grained access control लागू किया जा सकता है।
  • Linux सुरक्षा ecosystem में इसे एक simple और practical unprivileged sandboxing tool के रूप में देखा जा रहा है, और भविष्य में Linux डेस्कटॉप सुरक्षा सुदृढ़ करने का मुख्य घटक बनने की दिशा में यह गंभीरता से उभर रहा है।

Landlock का अवलोकन

  • Landlock Linux applications को यह स्पष्ट रूप से declare करने वाली एक API है कि उसे किन resources तक पहुँच देनी है।
    • यह OpenBSD के unveil() और pledge() कॉन्सेप्ट जैसा है और “सिर्फ आवश्यक संसाधन को ही अनुमति दो, बाकी block करो” वाले principle पर आधारित है।
  • यह अन्य Linux security mechanism की तुलना में समझना और integrate करना आसान, developer-friendly defensive layer देता है।
  • उद्देश्य यह है कि ऐप्स उपलब्ध पहुँच मॉडल के साथ Landlock उपयोग को बढ़ावा दिया जाए।

काम करने का तरीका

  • Linux Security Module(LSM) के रूप में, यह Linux 5.13 से उपलब्ध है।
  • SELinux या AppArmor से अलग, इसमें process-level transient restriction लागू होता है।
    • नीति रनटाइम में बनती है और केवल वर्तमान thread तथा child processes पर लागू होती है; process समाप्त होने पर समाप्त हो जाती है।
  • नीति के घटक
    1. Handled accesses: प्रतिबंधित करने वाले ऑपरेशन समूह (उदा. file system पढ़ना/लिखना)
    2. Access grants: अनुमति देने वाले objects की स्पष्ट सूची
  • उदाहरण नीति
    • /home/user read-only
    • /tmp read/write
    • पोर्ट 2222 bind करने की अनुमति
  • landlock_restrict_self() कॉल होने पर संबंधित thread और child processes स्थायी रूप से प्रतिबंधित क्षेत्र में प्रवेश करते हैं।
    • प्रतिबंध हटाया नहीं जा सकता; अधिकतम 16 परतें (layer) stack की जा सकती हैं।
    • नीचे की परतें पहुँच को और सीमित कर सकती हैं, लेकिन ऊपर की परत से हटाया गया अधिकार वापस नहीं जोड़ा जा सकता।
  • unprivileged तरीके से, सामान्य applications भी अपना स्वयं का sandbox बना सकते हैं।
  • ABI versioning के कारण पुराने kernels पर भी उपलब्ध सीमाओं के अंदर काम करता है।
  • यह Stackable LSM है, इसलिए SELinux या AppArmor के साथ साथ उपयोग किया जा सकता है।

उपयोग करने के कारण

  • predictable file access pattern वाले एप्लिकेशन के लिए उपयुक्त
    • उदाहरण: वेब सर्वर को केवल /var/www/html और /tmp तक सीमित करना।
  • सिस्टम-wide admin सेटअप या admin intervention की जरूरत नहीं, नीति सीधे code में define की जा सकती है।
  • privilege escalation के बिना उपयोग संभव है, और अधिकांश programmes में आसानी से integrate किया जा सकता है।
  • Rust, Go, Haskell के लिए bindings मौजूद हैं, और unveil शैली के कई wrapper projects भी उपलब्ध हैं।
  • official C library अभी नहीं है, लेकिन कई unofficial implementations उपलब्ध हैं।
  • Rust sample code में /usr, /etc, /dev को read-only तथा /home, /tmp को read/write access देने का उदाहरण मिलता है।

Linux sandboxing की स्थिति और जरूरत

  • Linux उपयोग बढ़ने के साथ desktop-targeted malware भी बढ़ रहा है।
  • Linux की तुलनात्मक सुरक्षा मुख्यतः उसके market share और technical barrier की वजह से दिखती है; यह उसके मूलभूत architecture की वजह से नहीं।
  • सामान्य वितरण (distro) की समस्याएँ
    • untrusted binaries चलाना संभव है।
    • इंटरनेट से सीधे scripts रन किए जा सकते हैं।
    • बिना पासवर्ड के sudo उपयोग।
    • सामान्य application के पास $HOME के भीतर संवेदनशील फाइलों की पहुँच हो सकती है।
    • X11 environment में keypress monitoring संभव।
    • किसी भी पोर्ट पर arbitrary bind संभव।

existing security tools की सीमाएँ

  • Containerization (Docker, Podman): सेवाओं के अलगाव (isolation) के लिए ठीक, लेकिन desktop apps के लिए उपयुक्त नहीं; --privileged विकल्प के कारण isolation bypass के उदाहरण मौजूद हैं।
  • Flatpak / Snap: GUI apps के लिए ठीक, लेकिन permissions काफी व्यापक हैं और CLI tools के लिए उपयुक्त नहीं।
  • Firejail: app-wise profile की जरूरत, हर रन पर explicit invocation करना पड़ता है।

डेवलपर दृष्टिकोण से existing mechanisms

  • seccomp: शक्तिशाली, पर सेटअप कठिन है; blacklist approach अपेक्षाकृत कमजोर हो सकती है।
  • SELinux: मजबूत, लेकिन जटिल और admin policy आवश्यक; कई distributions में default off रहता है।
  • AppArmor: SELinux से सरल, फिर भी admin profile की जरूरत; कुछ distros में disabled रहता है।

Landlock के फायदे का सार

  • unprivileged, app-centric, easy integration, deny-by-default
  • Linux 5.13 के बाद व्यापक समर्थन, backward/forward compatibility बरकरार
  • पूर्ण नहीं, फिर भी एक simple और independent unprivileged sandboxing tool के रूप में एक खाली जगह को भरता है।

Landlock की संभावित उपयोगिता

  • high-privilege daemon process के long-running scenario में, Landlock से access range सीमित किया जा सकता है।
  • PDF reader, image viewer, web browser, word processor केवल open की हुई फाइलों तक सीमित किए जा सकते हैं।
  • FTP/HTTP server केवल आवश्यक फाइलों तक पहुँच रखें।
    • उदाहरण: nginx अगर root पर रन कर रहा हो, तो भी attacker अगर shell हासिल कर ले, तो नीति के बाहर की फाइलों तक पहुँच नहीं बना पाएगा।
  • अगर Supervisor proposal लागू हो जाए, तो Linux desktop पर Android-जैसा permission system लाना संभव हो सकता है।
    • GUI और permission storage system के साथ combine करने पर, अधिक सुरक्षित user experience संभव है।

Landlock के चल रहे feature विकास

  • Supervise Mode: user space में पहुँच allow/deny को interactive तरीके से तय करना, Android-style permission prompt जैसा।
  • Socket Restrictions: process द्वारा उपयोग की जा सकने वाली socket types/ports पर fine-grained नियंत्रण।
  • LANDLOCK_RESTRICT_SELF_TSYNC: प्रतिबंध को process के सभी threads में propagate करना।
  • LANDLOCK_ADD_RULE_QUIET: चुने हुए objects के लिए audit log संदेश suppress करना।
  • LANDLOCK_ADD_RULE_NO_INHERIT: upper directory की permission को नीचे inherit होने से रोकना, filesystem control को और granular बनाना।

सारांश

  • Landlock एक सरल, unprivileged, default-deny sandboxing mechanism है।
  • समझने और integrate करने में आसान, तथा Linux डेस्कटॉप और application security सुधारने की बड़ी संभावनाएँ रखता है।
  • डेवलपर सीधे अपने application में Landlock लागू करके security level सुधार सकते हैं।

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

1 टिप्पणियां

 
GN⁺ 2025-12-01
Hacker News राय
  • मैंने Landlock का इस्तेमाल करके अनचाही telemetry ब्लॉक की
    C में एक छोटा-सा प्रोग्राम लिखा, जो सिर्फ एक खास port पर listen करे और बाकी सभी network connections को ब्लॉक कर दे
    मैंने sandboxer.c उदाहरण देखा, और file access restrictions को छुए बिना सिर्फ network को control किया
    dmesg में blocked connections दिखते हैं, शायद audit फीचर की वजह से
    यह टूल unprivileged user mode में काम करता है, और container के अंदर भी firewall settings के बिना अच्छी तरह चलता है
    लेकिन मुझे नहीं लगता कि यह malicious program को पूरी तरह रोकने के लिए उपयुक्त है
    • क्या आप source code साझा कर सकते हैं?
  • Landlock परफेक्ट नहीं है
    issue #28 और संबंधित mail thread को देखें तो एक समस्या है कि sandbox rules मौजूद नहीं होने वाली directories को refer नहीं कर सकते
    उदाहरण के लिए, अगर ~/.ssh अभी मौजूद नहीं है और आप rule जोड़ते हैं, तो बाद में directory बनने पर भी access block नहीं होगा
    यानी security के लिहाज़ से इसमें कमजोरी आ सकती है
  • मैं itch.io games को bwrap के साथ sandbox करने की कोशिश कर रहा हूँ
    इन्हें minimum privilege पर चलाना काफ़ी मुश्किल है
    “Microlandia” नहीं चलती, लेकिन दूसरे Unity games ठीक चलते हैं
    उम्मीद है कि Landlock-आधारित tools ज़्यादा बनें, ताकि ऐसा काम आसान हो
    • bubblewrap project
    • मेरी run script का उदाहरण
    • Microlandia game page
    • मैंने भी npm project को isolate करने के लिए bwrap इस्तेमाल किया है 
      bwrap --unshare-pid --dev-bind / / --tmpfs /home --bind "$(pwd)" "$(pwd)" bash
      यह काफ़ी अच्छा काम करता है, लेकिन लगता है कि अगर network namespace पहले से specify कर पाते तो बेहतर होता
  • container runtime में Landlock की support status क्या है, यह जानना चाहता हूँ
    लगता है CRI अपने interface खुद define करना चाहते हैं, लेकिन वे kernel support से हमेशा पीछे ही रहेंगे
    ज़्यादातर infra engineers शायद app-वार sandbox policies maintain नहीं करेंगे
    मुझे लगता है कि application का खुद Landlock इस्तेमाल करना ज़्यादा practical है
    • runc issue, runtime-spec issue का ज़िक्र करते हुए,
      समझाया गया कि अगर runtime syscalls को बस pass through कर दे, तो app के खुद को lock down करने पर भरोसा करना पड़ता है
    • मुझे लगता है Landlock मूल रूप से container runtime के लिए नहीं, बल्कि किसी और purpose के लिए बना फीचर है
  • एक medical device developer के रूप में यह approach मुझे बहुत पसंद आई
    हम अंदरूनी तौर पर मिलते-जुलते API से critical process management करते हैं
    इस तरह का research regulated industries के लिए भी बहुत मददगार होगा
  • “कोई official C library नहीं है” यह बात अजीब लगती है
    अगर यह kernel feature है, तो स्वाभाविक रूप से C API पहले होना चाहिए — फिर यह क्यों नहीं है, सोचता हूँ
    • kernel का basic interface syscall(uapi) है
      libc तो उसके ऊपर की layer भर है, और आज भी कई syscalls libc wrapper के बिना मौजूद हैं
    • यहाँ बात glibc या musl जैसी standard C library की हो रही है
      आप अपने headers बनाकर _syscallN macro से सीधे call भी कर सकते हैं
    • C API न होना कोई बड़ी समस्या नहीं है
      landbox जैसे simple wrapper इस्तेमाल किए जा सकते हैं,
      और Rust या Go भी C FFI expose कर सकते हैं
      kernel के sandboxer.c उदाहरण को देखें तो काफ़ी है
    • ज़्यादातर बातें man7 दस्तावेज़ में व्यवस्थित हैं
    • kernel developers सीधे userland software नहीं बनाते, इसलिए C API नहीं है
  • ध्यान रहे कि Landlock सिर्फ TCP sockets को restrict करता है, UDP या raw sockets को नहीं रोकता
    • यह काफ़ी बड़ा security hole लगता है। सोच रहा हूँ, इसकी वजह क्या है?
    • raw sockets के लिए privileges चाहिए होते हैं, और iptables से UID-आधारित blocking भी की जा सकती है
      यह Landlock से अलग है, लेकिन complement की तरह इस्तेमाल हो सकता है
    • फिर भी यह काफ़ी बड़ा gap लगता है
    • यह अजीब limitation है, लेकिन यह जानकर अच्छा लगा
  • यह दिलचस्प है कि Landlock ने /sys configuration की बजाय नए syscalls जोड़े
    शायद इसकी वजह least privilege principle है
    यह भी जानना है कि क्या seccomp से Landlock syscalls block किए जा सकते हैं
    अगर पुरानी seccomp policy में Landlock numbers शामिल न हों, तो क्या SIGSYS आ सकता है?
    • दूसरे LSM भी धीरे-धीरे syscall-आधारित model की ओर जा रहे हैं
      filesystem-आधारित API में footgun बहुत होते हैं, और dirfd-आधारित access control के लिए syscall ज़्यादा उपयुक्त है
      अच्छी तरह लिखे गए seccomp filters -ENOSYS लौटाते हैं, ताकि यह बस “supported नहीं है” जैसा लगे
    • seccomp से Landlock syscalls restrict किए जा सकते हैं, लेकिन इसकी practical value कम है
      क्योंकि Landlock मौजूदा privileges को सिर्फ और सीमित करता है, कोई नया privilege नहीं देता
  • मैंने अभी-अभी Linux security में रुचि लेना शुरू किया है
    मैं Mac छोड़कर पूरी तरह Linux पर जाने की तैयारी कर रहा हूँ, और जानना चाहता हूँ कि malware defense में Landlock कितनी मदद कर सकता है
    उदाहरण के लिए, मैं ऐसा environment बनाना चाहता हूँ जो ~/.ssh access अपने-आप deny कर दे
    और यह भी जानना चाहता हूँ कि क्या इससे app launcher बनाया जा सकता है
    • Landlock का threat model malware खुद नहीं, बल्कि सामान्य app में मौजूद code execution vulnerabilities हैं
      इसका मकसद यह है कि app खुद अपनी गैर-ज़रूरी privileges सीमित करे, ताकि attacker पूरे system पर कब्ज़ा न कर सके
    • ~/.ssh access block करने जैसी चीज़ों के लिए AppArmor या SELinux जैसे MAC model की ज़रूरत होती है
      Landlock तब उपयोगी है जब app खुद या अपने child processes को restrict करना चाहता है
      जैसे npm post-install scripts को सिर्फ build directory तक सीमित करना
      यह OpenBSD के pledge की तरह API है, जिसे app developers सीधे इस्तेमाल करते हैं
      लेकिन Linux ecosystem बिखरा हुआ है, इसलिए इसका adoption धीमा होगा
      तब तक इसे wrapper या launcher के रूप में इस्तेमाल करना ही practical है
    • package manager को build scripts के लिए policy specify करनी होगी, या users को खुद wrapper इस्तेमाल करना होगा
      अंततः यह तभी असरदार है जब program को अपनी privileges की समझ हो
    • यह लगभग macOS और iOS की sandboxing अवधारणा जैसा ही है
      app startup में जिन resources की ज़रूरत है, उन्हें whitelist किया जाता है और बाकी सब block कर दिया जाता है
      यह malicious software defense के लिए नहीं, बल्कि self-process protection के लिए है
  • “कोई official C library नहीं है” यह बात सुनकर हँसी आती है
    standard library में syscall पहले से हैं, तो अलग library की क्या ज़रूरत है?
    man7 दस्तावेज़ भी मौजूद है
    शायद मतलब सिर्फ यह है कि कोई abstraction layer चाहिए
    • libc syscall numbers के management और side effects को handle करती है,
      इसलिए यह थोड़ा surprising है कि glibc अभी तक Landlock interface नहीं देता
      शायद इसकी वजह non-Linux compatibility की समस्या है