Red Hat की RHEL source code वितरण पद्धति में बदलाव
- जून 2023 में Red Hat ने Red Hat Enterprise Linux(RHEL) के पीछे के source code को वितरित करने के तरीके को बदलने का एक विवादास्पद निर्णय लिया
- इस निर्णय ने Rocky Linux, AlmaLinux, Oracle Linux जैसे RHEL के downstream rebuilds की भविष्य की व्यवहार्यता पर कई सवाल खड़े किए
- इसके बाद प्रत्येक distribution ने community को आश्वस्त करने के लिए घोषणाएँ कीं
- कई open source communities ने Red Hat के निर्णय को एक लालची corporate influence के रूप में देखा
- लोग Debian की ओर migrate कर रहे हैं या पहले ही कर चुके हैं, ऐसा कहकर उसे एक सुरक्षित ठिकाने के रूप में खोज रहे हैं
सुरक्षा का महत्व और कठिनाई
- सुरक्षा कठिन है, उबाऊ है, अप्रिय है, और इसे सही तरीके से करने के लिए बहुत प्रयास की आवश्यकता होती है
- Debian अपने users की सुरक्षा के लिए पर्याप्त प्रयास नहीं करता
Red Hat द्वारा SELinux अपनाना और default policies देना
- Red Hat ने बहुत पहले SELinux के उपयोग को अपनाया था, और केवल kernel में feature सक्षम करने से आगे बढ़ा
- उन्होंने distribution के लिए default SELinux policies बनाने का कठिन काम किया
- ये policies RHEL में default रूप से enabled होती हैं, और RHEL में default रूप से चलने वाले विभिन्न daemons और servers में सबसे अधिक उपयोग होने वाले daemons की सुरक्षा में मदद करती हैं
- Apache, nginx, MariaDB, PostgreSQL, OpenSSH आदि सभी RHEL distribution के साथ दी जाने वाली SELinux policies द्वारा सुरक्षित किए जाते हैं
Containers पर SELinux policies लागू करना
- यह सुरक्षा containers तक भी विस्तृत होती है
- containers software deploy करने के लिए developers की बढ़ती हुई पसंदीदा पद्धति बनते जा रहे हैं
- container में कुछ चलाना अपने आप में सुरक्षित है, यह एक गलतफहमी है
- containers स्वयं security problems हल नहीं करते, वे software deployment problems हल करते हैं
- Red Hat आधारित distributions में Docker के विकल्प podman का उपयोग किया जा सकता है, जो बिना daemon के containers चलाने और पूरी तरह rootless mode में चलाने का लाभ देता है
- Red Hat इससे एक कदम आगे जाकर containers को host OS और अन्य containers से अलग करने के लिए मजबूत default SELinux policies लागू करता है
- containers पर SELinux policies लागू करने से अज्ञात भविष्य की vulnerabilities के जोखिम को कम करने के लिए मजबूत safeguards मिलते हैं
Red Hat के default SELinux policies प्रदान करने के प्रयास
- Red Hat जानता था कि यदि वह इन default policies पर काम नहीं करेगा, तो users इस technology को नहीं अपनाएँगे और लाखों servers असुरक्षित स्थिति में रह जाएँगे
- SELinux कठिन है, इसकी policy language और tools जटिल और अस्पष्ट हैं, और tax return भरने जितने ही कम आकर्षक हैं
- लेकिन Red Hat के किए गए काम की वजह से RHEL में SELinux का उपयोग अधिकांशतः पारदर्शी है और users को वास्तविक security benefits देता है
Debian का AppArmor दृष्टिकोण
- Debian open source community का एक मुख्य स्तंभ है, जो stability और व्यापक software library के लिए जाना जाता है
- लेकिन इसका default security framework अभी भी सुधार की काफी गुंजाइश रखता है
- Debian 10 से default रूप से AppArmor सक्षम करने का निर्णय security सुधार की दिशा में एक सकारात्मक कदम है, लेकिन यह पूरे system में आधा-अधूरा लागू है, इसलिए अपर्याप्त है
- AppArmor पर Debian की निर्भरता और उसकी default configuration दिखाती है कि उसके security approach में एक संरचनात्मक समस्या है
- AppArmor सही तरीके से configure होने पर मजबूत सुरक्षा दे सकता है, लेकिन Debian की default settings उसकी क्षमता का लाभ नहीं उठातीं
Debian में AppArmor की समस्याएँ
- सीमित default profiles: Debian न्यूनतम AppArmor profiles के साथ आता है, जिससे कई महत्वपूर्ण services असुरक्षित रह जाती हैं
- reactive बनाम proactive रुख: Debian का security model अक्सर users पर निर्भर करता है कि वे अधिक सख्त policies लागू करें, बजाय इसके कि default रूप से सुरक्षित configuration दे
- असंगत अनुप्रयोग: Red Hat systems में SELinux के विपरीत, Debian का AppArmor आंशिक रूप से लागू होता है, जिससे संभावित security gaps पैदा होते हैं
- resources की कमी: एक community-driven project होने के कारण Debian के पास Red Hat जैसी व्यापक security policies विकसित और maintain करने के लिए पर्याप्त resources नहीं हैं
Debian में Docker के माध्यम से container workloads चलाना
- Debian में Docker के जरिए container workloads चलाना बहुत आम है
- Docker
docker-default नाम का containers के लिए एक default AppArmor profile अपने आप बनाता और load करता है
- दुर्भाग्य से यह security के लिहाज से बहुत मजबूत profile नहीं है और अत्यधिक permissive है
- यह profile कुछ हद तक सुरक्षा देता है, लेकिन attack surface का एक बड़ा हिस्सा खुला छोड़ देता है
AppArmor और SELinux के बीच मूलभूत अंतर
- AppArmor और SELinux के बीच मूलभूत अंतर mandatory access control(MAC) के प्रति उनके दृष्टिकोण में है
- AppArmor path-based model पर काम करता है, जबकि SELinux कहीं अधिक जटिल type enforcement system का उपयोग करता है
- यह अंतर container environments में विशेष रूप से अधिक स्पष्ट होता है
- SELinux system की सभी objects(फाइलें, processes, ports आदि) पर types लागू करता है
- SELinux समर्थित RHEL system में container शुरू करने पर उसे तुरंत
container_t type दिया जाता है, जो एक सख्त access control mechanism है
container_t type containers को प्रभावी ढंग से सीमित करता है ताकि वे उन objects के साथ interact न कर सकें जिन्हें container उपयोग के लिए स्पष्ट रूप से label नहीं किया गया है- SELinux type enforcement पर ही नहीं रुकता, बल्कि multi-category security(MCS) labels का उपयोग करके container isolation को एक कदम और आगे ले जाता है
- ये labels एक अतिरिक्त separation layer के रूप में काम करते हैं, जो एक ही type(
container_t) वाले containers के बीच भी isolation बनाए रखते हैं
- प्रत्येक container को एक विशिष्ट MCS label मिलता है, जो व्यापक
container_t environment के भीतर एक निजी sandbox बनाता है
AppArmor का दृष्टिकोण
- AppArmor types या categories की परवाह नहीं करता, बल्कि predefined profiles के आधार पर specific programs की capabilities सीमित करने पर केंद्रित होता है
- ये profiles यह निर्धारित करते हैं कि program किन files तक पहुँच सकता है और कौन से actions कर सकता है
- यह approach लागू करने और समझने में अधिक सरल है, लेकिन SELinux के type enforcement जितनी सूक्ष्म या पूरे system में उतनी सुसंगत नहीं है
- mainstream Linux distributions आमतौर पर default रूप से सभी सामान्य network-oriented daemons के लिए व्यापक AppArmor profiles वितरित नहीं करते
वास्तविक प्रभाव
- SELinux environment में कोई compromised container host system या अन्य containers तक पहुँचने या उन्हें प्रभावित करने में type enforcement और MCS labels की दोहरी बाधा के कारण गंभीर रुकावटों का सामना करता है
- SELinux अधिक मजबूत isolation देता है, लेकिन इसकी कीमत बढ़ी हुई जटिलता और संभावित performance overhead के रूप में चुकानी पड़ती है
- AppArmor एक अधिक सरल और सुलभ security model देता है, जो सही configuration के साथ अब भी बहुत प्रभावी हो सकता है
- Red Hat ने SELinux और container उपयोग को सहज और आसान बनाने के लिए प्रयास किए हैं
- अंततः Debian और Red Hat के बीच चुनाव केवल corporate influence और community-driven development के बीच चुनाव नहीं है
- यह उस system और उस system के बीच का चुनाव भी है जो सबसे अच्छे की उम्मीद करता है और जो सबसे बुरी स्थिति के लिए तैयारी करता है
- आज की अत्यधिक connected दुनिया में दुर्भाग्य से निराशावाद आवश्यक है
GN⁺ की राय
- Red Hat की RHEL source code वितरण नीति में बदलाव विवादास्पद है, लेकिन security के दृष्टिकोण से यह एक तर्कसंगत निर्णय हो सकता है
- enterprise Linux distributions में SELinux जैसी मजबूत security capabilities देना अनिवार्य है
- हालांकि, Red Hat की नीति में बदलाव open source ecosystem पर नकारात्मक प्रभाव डाल सकता है, और Debian जैसे community-based distributions की भूमिका और अधिक महत्वपूर्ण हो सकती है
- Debian को user-friendly और flexible distribution के रूप में जाना जाता है, लेकिन उसकी default security capabilities को मजबूत करने की आवश्यकता है
- AppArmor, SELinux जितना शक्तिशाली नहीं है, लेकिन सही तरीके से configure किया जाए तो यह एक प्रभावी security solution बन सकता है
- लंबी अवधि में SELinux और AppArmor के फायदों को मिलाने वाले किसी नए security framework के विकास की आवश्यकता हो सकती है
- container security cloud-native युग में एक बेहद महत्वपूर्ण मुद्दा है, इसलिए सभी distributions को इस हिस्से पर अधिक प्रयास करना चाहिए
2 टिप्पणियां
यह सही है कि Apparmor, selinux की तुलना में कम सख्त है..
लेकिन यह कहना मुश्किल है कि इसकी वजह से सुरक्षा कमजोर है।
Selinux इतना ज़्यादा सख्त है कि सर्वर सेटअप करने पर ज़्यादातर लोग उसे बंद ही कर देते हैं।
और डेस्कटॉप में सुरक्षा, selinux की मुख्य चिंता नहीं है।
UI या user experience के लिए ज़रूरी restrictions और उचित authentication request process आदि की ज़रूरत होती है, और यह selinux की तरह resources के isolation से अलग बात है।
इसलिए डेस्कटॉप security, चाहे वह Red Hat परिवार हो या Debian परिवार, सब freedesktop में standardize किए गए polkit (policykit) आधारित तरीके पर चलते हैं.
Hacker News राय