Kernel Hardening: Linux उपयोगकर्ता खातों को ब्रूट-फोर्स हमलों से बचाना

मूल लेख ↗ Hacker News चर्चा ↗

परियोजना का दायरा और Qubes/Kicksecure से संबंध

  • टिप्पणीकारों का कहना है कि शीर्षक भ्रामक रूप से संकीर्ण है; यह परियोजना ब्रूट-फोर्स सुरक्षा से आगे बढ़कर व्यापक hardening प्रदान करती है।
  • Qubes OS में, कई उपयोगकर्ता अप्रत्यक्ष रूप से Whonix के माध्यम से Kicksecure का उपयोग करते हैं, लेकिन कुछ का तर्क है कि Qubes की मुख्य सुरक्षा हार्डवेयर वर्चुअलाइज़ेशन है, जबकि Kicksecure द्वितीयक है।

Kexec, Root, और Defense-in-Depth

  • कुछ लोगों का तर्क है कि kexec को disable करना बेकार है क्योंकि इसका उपयोग केवल root कर सकता है, और root को सीमित करना creeping DRM जैसा है।
  • अन्य लोग kexec को disable करने में value देखते हैं, defense-in-depth की एक परत के रूप में, विशेषकर SELinux, सीमित /dev/mem//dev/kmem, disabled /proc/kcore, और module restrictions के साथ।
  • प्रतिवाद: root को kexec फिर से enable करने या kernel patch करने से वास्तव में रोकने के लिए व्यापक MAC policies और compile-time choices की आवश्यकता होती है; अन्यथा root अभी भी kernel memory को modify कर सकता है।

Secure Boot, Signed Modules, और User Freedom

  • एक पक्ष मजबूत integrity के लिए केवल signed kernel modules की अनुमति देने का समर्थन करता है (वैकल्पिक रूप से, secure boot के माध्यम से)।
  • आलोचकों को चिंता है कि यह गैर-वैकल्पिक lockdown (Android, TPM, gaming anti-cheat के उदाहरण) की ओर बढ़ता है और उपयोगकर्ताओं के अपने hardware पर नियंत्रण को कमजोर करता है।
  • कुछ लोग नोट करते हैं कि hardened setups boot के बाद module loading disable कर देते हैं; अन्य आपत्ति करते हैं कि उपयोगकर्ताओं को अपना खुद का ring 0 code load करने से रोकना अस्वीकार्य है।

Root, sudo, और suid की भूमिका

  • एक मजबूत अल्पसंख्यक का तर्क है कि root का अस्तित्व और व्यापक शक्ति “bad security” है और इसे न्यूनतम या network-admin, software-install, आदि जैसी संकरी भूमिकाओं में विभाजित किया जाना चाहिए।
  • प्रस्तावित मॉडल: root को हटाएँ या निर्बल करें, suid binaries से बचें, और इसके बजाय privileged services या capabilities-based binaries का उपयोग करें।
  • विरोध: administrators को अपने systems पर पूर्ण नियंत्रण रखने में सक्षम होना चाहिए; Linux को iOS-जैसे locked-down systems में बदलना व्यापक रूप से अस्वीकार किया जाता है।
  • कुछ लोग सुझाव देते हैं कि सावधानीपूर्वक configured sudo और SELinux पहले से ही root को हटाए बिना fine-grained control प्रदान करता है।

SELinux: शक्ति बनाम उपयोगिता

  • SELinux को root को भी प्रतिबंधित करने का एक परिपक्व तरीका माना जाता है (जैसे module load, kexec को block करना)।
  • राय बंटी हुई है: कुछ कहते हैं कि यह व्यवहार में अच्छी तरह काम करता है; अन्य इसे जटिल, खराब दस्तावेज़ित, और ऐसी चीज़ मानते हैं जिसे लोग मुख्यतः “out of the way” करना चाहते हैं।

Browser Sandboxing और Application Isolation

  • कई approaches पर चर्चा हुई: अलग user accounts, AppArmor, Firejail, flatpak/bubblewrap, containers (docker/podman), Qubes-style VMs, या remote browsers।
  • आम सहमति: system को browser से बचाने के लिए कई tools मौजूद हैं; लेकिन browser के data को अन्य user processes से पूरी तरह बचाना, system-wide sandboxing के बिना, अधिक कठिन है।