🤦🏿 ✌🏽 👩🏾‍🤝‍👨🏿 SELinux का परिचय: तृतीय-पक्ष वेब अनुप्रयोगों के लिए लक्षित नीति संशोधन 📪 🦄 👋🏽

हाय साथियों!
हम में से कई वेब परियोजनाओं के लिए उत्पादन सर्वर स्थापित करने में शामिल हैं। मैं अपाचे या Nginx को कॉन्फ़िगर करने के तरीके के बारे में बात नहीं करूंगा: आप मेरे बारे में इससे अधिक जानते हैं। लेकिन फ्रंटएंड सर्वर बनाने का एक महत्वपूर्ण पहलू अनलिमिटेड रहता है: ये सुरक्षा सबसिस्टम के लिए सेटिंग्स हैं। "SELinux को अक्षम करें", अधिकांश शौकिया गाइडों की मानक अनुशंसा है। मुझे ऐसा लगता है कि यह जल्दबाजी में लिया गया निर्णय है, क्योंकि सॉफ्ट पॉलिसी मोड में सुरक्षा सबसिस्टम स्थापित करने की प्रक्रिया सबसे अधिक बार बहुत तुच्छ है।

आज मैं आपको ऑपरेटिंग सिस्टम के Red Hat (CentOS) परिवार में प्रयुक्त SELinux सुरक्षा सबसिस्टम को ट्यून करने के कुछ तरीकों के बारे में बताऊंगा। एक उदाहरण के रूप में, हम अपाचे + mod_wsgi + Django + ZEO वेब सर्वर के लिए Centre Version 5.8 पर एक बंडल कॉन्फ़िगर करेंगे।

लिनक्स सुरक्षा प्रणालियों को कॉन्फ़िगर करते समय, हम विवेकाधीन अभिगम नियंत्रण (डीएसी) प्रणाली के ढांचे से विवश हैं। हमारे पास हमारे निपटान में तीन स्तरों (मालिक, समूह के मालिक और अन्य) और पोसिक्स एसीएल में आरडब्ल्यूएक्स के मानक अधिकार हैं। इस प्रकार, उपयोगकर्ता अधिकारों के साथ एक आवेदन सैद्धांतिक रूप से संबंधित उपयोगकर्ता के लिए उपलब्ध सभी संसाधनों तक पहुंच है। यदि एप्लिकेशन से छेड़छाड़ की जाती है, तो इससे दुःखद परिणाम हो सकते हैं।

SELinux (सुरक्षा-संवर्धित लिनक्स) एक सुरक्षा सबसिस्टम है जो अनिवार्य पहुंच नियंत्रण (मैक) को लागू करता है, जो एक क्लासिक विवेकाधीन प्रणाली के साथ समानांतर में काम करता है। एक्सेस राइट्स सिस्टम द्वारा नीतियों का उपयोग करके निर्धारित किए जाते हैं। ऑपरेटिंग सिस्टम के Red Hat (CentOS) परिवार में, आप कर्नेल के भाग के रूप में SELinux को बॉक्स से बाहर निकालते हैं। कार्यों के लिए सबसे सरल समाधान के लिए हमें एक लक्षित नीति ("लक्ष्य") की आवश्यकता होती है, जो विशिष्ट अनुप्रयोगों के थोक के लिए नियमों का वर्णन करता है। हमें अतिरिक्त प्रयास के बिना बुनियादी सेवाओं की बुनियादी सुरक्षा मिलती है। नीति नियम ऐसे हैं कि इसमें वर्णित सभी एप्लिकेशन डीएसी के ढांचे में SELinux से प्रतिबंध के बिना काम नहीं करेंगे।

"लेकिन क्यों, वास्तव में, क्या हमें इस SELinux की आवश्यकता है?" आप पूछते हैं। इसका उत्तर काफी सरल है: कुछ मामलों में, सुरक्षा सबसिस्टम कम से कम अनधिकृत पहुंच को रिकॉर्ड करने की अनुमति देगा, और आदर्श रूप से, इसे रोकने के लिए। किसी भी मामले में, उल्लंघनकर्ता को एक विशिष्ट प्रक्रिया के लिए रूपरेखा के भीतर कार्य करना होगा।

अपनी स्वयं की सेटिंग्स जोड़ने के लिए, हम संदर्भों, डोमेन और एक्सेस वैक्टर के साथ काम करेंगे। सुरक्षा-प्रासंगिक घटनाओं को कर्नेल स्तर पर SELinux द्वारा इंटरसेप्ट किया जाता है। सुरक्षा इंजन तंत्र डीएसी नियमों के बाद प्रभावी होते हैं। SELinux RBAC (रोल-बेस्ड एक्सेस कंट्रोल), TE (टाइप एनफोर्समेंट) और वैकल्पिक रूप से MLS (मल्टी-लेवल सिक्योरिटी) क्षमताएं प्रदान करता है। प्रत्येक सिस्टम ऑब्जेक्ट का एक विशिष्ट संदर्भ (प्रकार) होता है। नीति के नियमों के आधार पर, सुरक्षा सबसिस्टम या तो इस ऑपरेशन के निष्पादन की अनुमति देता है या इसे ब्लॉक करता है, और प्रक्रिया में एक त्रुटि संदेश प्राप्त होता है। SELinux द्वारा किए गए सभी निर्णय एक्सेस वेक्टर कैश (AVC) में कैश किए जाते हैं।

SELinux संदर्भ में उपयोगकर्ता, भूमिका, प्रकार और स्तर के बारे में जानकारी होती है। हम एक प्रकार पर काम करेंगे जो टाइप प्रवर्तन का एक गुण है। यह प्रक्रियाओं के लिए डोमेन और फाइलों के लिए प्रकार द्वारा परिभाषित किया गया है। SELinux नियम, अनुमत प्रकार के इंटरैक्शन का वर्णन करते हैं। यदि संबंधित नियम है तो ही प्रवेश की अनुमति है।

अलग से, मैं डोमेन बदलाव की तकनीक को नोट करना चाहूंगा। SELinux में, किसी एप्लिकेशन को एक डोमेन से दूसरे में बदलना संभव है यदि स्रोत डोमेन से एक प्रक्रिया एक एप्लिकेशन चलाती है जो एक फ़ाइल से नए डोमेन के एंट्रीपॉइंट प्रकार से शुरू होती है।

मानक लक्षित नीति 200 से अधिक अनुप्रयोगों के लिए संदर्भ, डोमेन और एक्सेस नियमों का निर्माण और वर्णन करती है। आपके पास नीति का विस्तार करने और प्रस्तावित संदर्भों के ढांचे के भीतर कार्य करने का अवसर है। बुनियादी नीतियों को विकसित करते समय, लगभग सभी मुख्य उपयोग के मामलों को ध्यान में रखा गया। मानक समाधान बनाने के लिए, आपको व्यावहारिक रूप से कुछ भी बदलने की ज़रूरत नहीं है।

इसलिए, टेम्पलेट समाधानों को लागू करते समय, SELinux सुरक्षा तंत्र का उपयोग करने से इनकार करना कम से कम उचित नहीं है। अतिरिक्त सॉफ़्टवेयर स्थापित करते समय इसके उपयोग में कुछ कठिनाइयाँ उत्पन्न होती हैं। कार्य के संदर्भ में, वे मॉड्यूल mod_wsgi और ZEO हैं। SELinux को चालू रखने के लिए, हमें इसकी सेटिंग्स में बदलाव करने की आवश्यकता है।

मेरे उदाहरण में, मैं अपाचे वेब सर्वर (httpd-2.2.3-63.el5.centos.1) के साथ CentOS 5.8 (कर्नेल 2.6.18-308.1.1.el5) का उपयोग कर रहा हूं। पायथन (2.7.2), Django (1.4), mod_wsgi (3.3), और Zope (3.4.0) इसके अतिरिक्त स्थापित हैं। (इस सॉफ़्टवेयर के लिए प्रॉसिक्युलर इंस्टॉलेशन प्रक्रिया एक अलग विवरण के लायक नहीं है।)

सबसे पहले, हमें httpd के लिए SELinux पॉलिसी का विस्तार करना होगा। डिफ़ॉल्ट सेटिंग्स इसके समझौते के मामले में प्रक्रिया के विश्वसनीय अलगाव के लिए अभिप्रेत हैं। हालाँकि, आपके प्रोजेक्ट पर httpd की पहुँच के लिए कुछ परिवर्तनों की आवश्यकता होगी। नीति के लेखकों ने आवेदन के पूर्ण तर्क को संदर्भ पर प्रतिबंध के साथ रखा। एक साधारण कमांड आपको अपने सिस्टम पर फाइलों के मार्कअप से परिचित कराने में मदद करेगी:

semanage fcontext -l | grep httpd

नीति प्रस्तुत प्रकारों में से प्रत्येक तक पहुंच को नियंत्रित करती है। संबंधित मेन पेज ( आदमी httpd_selinux ) पर संदर्भों की एक पूरी सूची मिल सकती है। हम httpd_sys_content_t प्रकार में रुचि रखते हैं, जो डेमॉन और स्क्रिप्ट को फ़ाइलों तक पहुंचने की अनुमति देता है। इस प्रकार, मानक डीएसी अधिकारों के अतिरिक्त, आपको अपनी परियोजना की निर्देशिका और फ़ाइलों के संदर्भ को निर्दिष्ट करना होगा। यह एक समय पर chcon कमांड का उपयोग करके किया जा सकता है।

chcon -R -t " httpd_sys_content_t " / your / project

हालांकि, मैं एक नियम के साथ प्रकार सेट करने की सलाह देता हूं। यह नई फ़ाइलों को जोड़ते समय बाद में स्वचालित प्रकार असाइनमेंट सुनिश्चित करेगा।

semanage fcontext -a -t httpd_sys_content_t "/your/project(/.*)?"
restorecon -R / your / project

मेरा डेमो प्रोजेक्ट एक ZoDB डेटाबेस के साथ Django का उपयोग करता है। डेटाबेस के साथ संचार के साधन के रूप में, ZEO का उपयोग किया जाता है। चूंकि यह एक स्टैंडअलोन सॉफ्टवेयर है, इसलिए SELinux के भीतर इसकी कार्यप्रणाली सुनिश्चित करना आवश्यक है। अलगाव सुनिश्चित करने के लिए, यह सलाह दी जाती है, जैसा कि मेरा मानना है, कि http: //d_d डोमेन में अपाचे उपयोगकर्ता अधिकारों के साथ ZEO लॉन्च करना है। ऐसा करने के लिए, हम डेमन मोड में एक स्टार्टअप दीक्षा स्क्रिप्ट को परिभाषित करते हैं। मैं इसके बड़े आकार की वजह से यहां संपूर्ण स्क्रिप्ट की सूची नहीं दूंगा। हमारे लिए मुख्य बात पर्याप्त होगी:

/ usr / स्थानीय / बिन / zeoctl -d -s / var / run / zeo / zsock -C / etc / zeo / zeoctl.conf start

यह मत भूलो कि आपकी आरंभीकरण स्क्रिप्ट को उचित संदर्भ में लाया जाना चाहिए ताकि SELinux को बाद के प्रकार के संक्रमण के दौरान समस्याओं से बचा जा सके।

chcon –t "initrc_exec_t" / etc / init.d / your_init_script

कॉन्फ़िगरेशन फ़ाइल में, आपको आवश्यक उपयोगकर्ता निर्दिष्ट करना होगा।

< रनर >
कार्यक्रम / usr / स्थानीय / बिन / runzeo -a / var / run / zeo / zeo.socket -f / var / your_db_path / db.fs
डेमॉन सच है
उपयोगकर्ता अपाचे
</ धावक >

एक सॉकेट का उपयोग ZEO और Django के बीच लिंक के रूप में किया जाता है। चूँकि httpd_t डोमेन में httpd काम करता है, इसलिए आपको प्रकार और DAC अधिकारों पर बातचीत करनी चाहिए ताकि एप्लिकेशन इससे जुड़ सके। ऐसा करने के लिए, हम निर्देशिका / var / run / zeo तैयार करेंगे और इसके लिए आवश्यक संदर्भ सेट करेंगे। हम केवल-सॉकेट के लिए संदर्भ के स्वचालित असाइनमेंट को सीमित करने के लिए -f -s स्विच का उपयोग करते हैं, और -f -d को निर्देशिका में संदर्भ सेट करने के लिए करते हैं।

semanage fcontext -a -f -d -t 'httpd_sys_script_rw_t' ' ' /var/run/zeo(/.*)? '
semanage fcontext -a -f -s -t 'httpd_sys_script_rw_t' ' ' /var/run/zeo(/.*)? '
restorecon –R / var / run

ZEO कॉन्फ़िगरेशन फ़ाइल में, आपको संचार सॉकेट के मजबूर स्थान को निर्दिष्ट करना होगा।

< zeo >
पता / var / run / zeo / zeo.socket
</ zeo >

चूंकि हम अपाचे उपयोगकर्ता की ओर से एप्लिकेशन को चलाने की योजना बनाते हैं, इसलिए प्रकारों की परिवर्तनशीलता को ध्यान में रखना आवश्यक है। Httpd_t टाइप करने के लिए हमें रनिंग प्रक्रिया की आवश्यकता है। डिफ़ॉल्ट रूप से, फ़ाइलों / usr / स्थानीय / बिन / zeoctl और / usr / स्थानीय / बिन / runzeo में एक bin_t संदर्भ होगा। चूंकि उन्हें अपरंपरागत डोमेन से बुलाया जाएगा, इसलिए संदर्भ परिवर्तन की श्रृंखला का पता लगाना आवश्यक है। सबसे पहले, /etc/init.d/ से स्क्रिप्ट को कॉल किया जाएगा, जिसे हमने initrc_exec_t टाइप किया है । इस स्थिति के लिए संक्रमण श्रृंखला खोजें।

sesearch -Ts -s unconfined_t -t initrc_exec_t | grep "initrc_exec_t"

पाया गया संक्रमण श्रृंखला अपरंपरागत_t initrc_exec_t: प्रक्रिया initrc_t की तरह लगती है । हम देखते हैं कि प्रक्रिया initrc_t संदर्भ प्राप्त करेगी । तदनुसार, अब हमें एक संक्रमण श्रृंखला खोजने की आवश्यकता है जो हमें आवश्यक प्रकार के httpd_t पर ले जाएगी ।

sesearch -T -s initrc_t | grep "प्रक्रिया httpd_t"

खोज का परिणाम initrc_t httpd_exec_t: httpd_t लिंक की प्रक्रिया होगी । इस परिवर्तन के घटित होने के लिए, हमें निष्पादन योग्य फ़ाइलों के लिए httpd_exec_t संदर्भ सेट करना होगा ।

वीर्यपात fcontext -a -t httpd_exec_t "/ usr / स्थानीय / बिन / ज़ेलेक्ट"
semanage fcontext -a -t httpd_exec_t "/ usr / लोकल / बिन / रनो"
restorecon -R / usr / स्थानीय / बिन

अब हमें SELinux पॉलिसी में httpd के लिए सॉकेट परमिशन को जोड़ने की आवश्यकता है। ऐसा करने के कई तरीके हैं। उपयोगकर्ता के दृष्टिकोण से सबसे आसान ऑडिट 2 क्लॉउड उपयोगिता है, जो सिस्टम लॉग से AVC संदेशों के आधार पर नीति मॉड्यूल बनाने की अनुमति देता है। उपयोगिता का सावधानीपूर्वक उपयोग करें, क्योंकि यह केवल कुछ कार्यों के लिए अनुमतियाँ बनाता है - लेकिन अधिक कुछ नहीं ( डेवलपर्स वेबसाइट पर एक विस्तृत मार्गदर्शिका प्रदान की गई है )।

दूसरा तरीका मॉड्यूल को मैन्युअल रूप से बनाना, इसे संकलित करना और इसे वर्तमान नीति में स्थापित करना है। चूंकि यह विधि प्रक्रिया का एक बेहतर दृश्य प्रदान करती है, हम इस तरह से ZEO के लिए मॉड्यूल का निर्माण करेंगे। Httpd_t प्रकार httpd_sys_script_rw_t के सॉकेट के साथ बनाने और काम करने के अधिकार प्रदान करता है। ऐसा करने के लिए, निम्नलिखित सामग्रियों से फ़ाइल /tmp/httpdAllowDjangoZEO.te बनाएं:

मॉड्यूल httpdAllowDjangoZEO 1.0;

आवश्यकता {
httpd_t टाइप करें;
httpd_sys_script_rw_t टाइप करें;
वर्ग sock_file लिंक;
वर्ग sock_file setattr;
वर्ग sock_file create;
वर्ग sock_file को अनलिंक करें;
वर्ग sock_file लिखना;
}
# ============== httpd_t ================
httpd_t httpd_sys_script_rw_t: sock_file लिंक की अनुमति दें;
httpd_t httpd_sys_script_rw_t: sock_file setattr को अनुमति दें;
httpd_t httpd_sys_script_rw_t: sock_file create करने दें;
httpd_t httpd_sys_script_rw_t: sock_file अनलिंक करें;
httpd_t httpd_sys_script_rw_t: sock_file लिखना अनुमति दें;

अगला, हमें मॉड्यूल बनाने और संकलित करने की आवश्यकता है। ऐसा करने के लिए, checkmodule और semodule_package कमांड का उपयोग करें। वर्तमान नीति में मॉड्यूल को स्थापित करने के लिए, हमें अर्ध- उपयोगिता की आवश्यकता है।

checkmodule -M -m -o / tmp / httpdAllowDjangoZEO.mod / tmp / httpdAllowDjangoZEO.te
semodule_package --outfile / tmp / httpdAllowDjangoZEO.pp --module / tmp / httpdAllowDjangoZEO.mod
semodule -i httpdAllowDjangoZEO.pp

अंतिम क्रिया ZoDB डेटाबेस और ZEO कॉन्फ़िगरेशन फ़ाइल के संग्रहण स्थान के संदर्भ को कॉन्फ़िगर करने के लिए होगी। इस प्रक्रिया में, हमें तकनीकी .lock फ़ाइलें बनाने की आवश्यकता होगी। इसलिए, डेटाबेस भंडारण स्थान को उपयुक्त संदर्भ के साथ चिह्नित किया जाना चाहिए, जो फ़ाइलों के निर्माण की अनुमति देगा। " Httpd_sys_script_rw_t " इसके लिए अच्छा है।

वीर्यपात fcontext –a –t "httpd_sys_script_rw_t" " / var / your_db_path ( / । * ) ?"

कॉन्फ़िगरेशन फ़ाइलों के लिए एक विशेष प्रकार "httpd_config_t" है।

शब्दांश fcontext –a -t "httpd_config_t" " / etc / zeo ( / । * ?" )

अब बस कॉन्फ़िगरेशन प्रक्रिया को पूरा करने के लिए सेवाओं को पुनरारंभ करें।

हमारे द्वारा लिखे गए नियम पूरे बंडल को समस्याओं के बिना काम करने की अनुमति देंगे। उसी समय, हम सर्वर और उसकी सेवाओं को अतिरिक्त SELinux सुरक्षा प्रदान करते हैं। यदि Django या ZEO घटकों में से एक समझौता किया जाता है, तो हमलावर सीमित हो जाएगा और सिस्टम में नहीं जा पाएगा, क्योंकि वह httpd_t डोमेन के भीतर कार्य करेगा।

इसलिए, हमें SELinux को अक्षम किए बिना एक काम करने वाला httpd उपयोगकर्ता कॉन्फ़िगरेशन मिला। इसी तरह, आप अपने किसी भी एप्लिकेशन के लिए नियामक नीतियां बना सकते हैं। इसमें अधिक समय नहीं लगता है और इसके लिए गंभीर सैद्धांतिक प्रशिक्षण की आवश्यकता नहीं होती है। तो शायद आपको SELinux को डिसेबल नहीं करना चाहिए?

SELinux तकनीक के बारे में अधिक समग्र समझ के लिए, मेरा सुझाव है कि आप Fedor 13 के लिए SELinux के रूसी-भाषा के विवरण से खुद को परिचित करें।

SELinux का परिचय: तृतीय-पक्ष वेब अनुप्रयोगों के लिए लक्षित नीति संशोधन

More articles: