🌒 ✂️ 👨🏿‍💼 SELinux - प्रणाली के साथ काम करने का विवरण और विशेषताएं। भाग २ 🥐 🧥 🧑🏽‍🤝‍🧑🏻

सहकर्मियों, सेलाइनक्स के बारे में लेख के पहले भाग में , हमने SELinux प्रणाली के साथ काम करने की मुख्य विशेषताओं की जांच की। जैसा कि वादा किया गया था, अब हम दूसरा भाग प्रकाशित कर रहे हैं, जो नीतियों को स्थापित करने पर केंद्रित है। अच्छा, चलिए शुरू करते हैं।

SELinux नीतियाँ अनुकूलित करना

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

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

आपके सिस्टम के लिए उपलब्ध सभी कार्यों को देखने के लिए, बस निम्नलिखित कमांड चलाएँ:

# getsebool -a

पैरामीटर बदलने के लिए, आपको सेटसेबुल कमांड का उपयोग करने की आवश्यकता है। उदाहरण के लिए, HTTPD सेवा मॉड्यूल और स्क्रिप्ट को नेटवर्क से कनेक्ट करने की अनुमति देने के लिए, बस कंसोल में निम्नलिखित दर्ज करें:

 # setsebool -P httpd_can_network_connect on

लेखा परीक्षा 2 के साथ कस्टम नीतियां बनाना

कभी-कभी ऐसे हालात पैदा हो जाते हैं जब पर्याप्त पूर्वनिर्धारित कार्य नहीं होते हैं, जब आपको किसी नए मॉड्यूल के साथ मौजूदा नीति को पूरक करने की आवश्यकता होती है, तो मैन्युअल रूप से किसी चीज तक पहुंच प्रदान करने के लिए कुछ शर्तों को लिख देना चाहिए। उदाहरण के लिए, हम अपने SMTP मेल सर्वर के लिए Postgrey ऐड-ऑन इंस्टॉल करते हैं। हमारे सर्वर को यूनिक्स सॉकेट्स के माध्यम से पोस्टग्रे के साथ बातचीत करनी चाहिए, लेकिन मेल सर्वर के लिए मानक SELinux नीति इसकी अनुमति नहीं देती है, यह सॉकेट्स के माध्यम से संचार करने के प्रयासों को अवरुद्ध करता है।

ऐसी स्थितियों में, फ़ाइलों के संदर्भ को बदलने से मदद नहीं मिलेगी, कोई अतिरिक्त कार्य नहीं हैं, जिनके द्वारा हम स्थिति को ठीक कर सकते हैं। बेशक, आप हमेशा एक "समस्याग्रस्त" सेवा के लिए SELinux को निष्क्रिय कर सकते हैं, लेकिन यह समाधान, निश्चित रूप से आदर्श से बहुत दूर है, क्योंकि गैर-शून्य संभावना है कि मेल सर्वर एक दिन हैक हो जाएगा।

तो, SELinux को Permissive मोड में डालें, और फिर मेल सर्वर को शुरू करें। कुछ समय बाद, AVC संदेश SELinux लॉग में दिखाई देगा, जिसमें हमारे सर्वर की सभी अमान्य कार्रवाइयाँ रिकॉर्ड की जाएंगी:

 type=AVC msg=audit(1218128130.653:334): avc: denied { connectto } for pid=9111 comm="smtpd" path="/var/spool/postfix/postgrey/socket" scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1218128130.653:334): avc: denied { write } for pid=9111 comm="smtpd" name="socket" dev=sda6 ino=39977017 scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_spool_t:s0 tclass=sock_file

अब हम स्थानीय नीति के लिए नियमों का एक सेट उत्पन्न करने के लिए ऑडिट 2 क्लॉक यूटिलिटी का उपयोग कर सकते हैं जो सभी आवश्यक पोस्टग्रे क्रियाओं की अनुमति देता है:

 # grep smtpd_t /var/log/audit/audit.log | audit2allow -m postgreylocal > postgreylocal.te # cat postgreylocal.te module postgreylocal 1.0; require { type postfix_smtpd_t; type postfix_spool_t; type initrc_t; class sock_file write; class unix_stream_socket connectto; } #============= postfix_smtpd_t ============== allow postfix_smtpd_t initrc_t:unix_stream_socket connectto; allow postfix_smtpd_t postfix_spool_t:sock_file write;

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

 # grep smtpd_t /var/log/audit/audit.log | audit2allow -M postgreylocal

अब हमें इस मॉड्यूल को लोड करने की आवश्यकता है, उन्हें पहले से ही शामिल नीतियों के साथ पूरक करते हुए सेमोड्यूल कमांड का उपयोग किया गया है:

 # semodule -i postgreylocal.pp

उसके बाद, मॉड्यूल को /etc/selinux/targeted/modules/active/modules/postgreylocal.pp पर ले जाया जाता है।
यह जांचने के लिए कि क्या कोई मॉड्यूल सही तरीके से लोड किया गया है, सभी लोड किए गए मॉड्यूल की एक सूची को "सेमोडुले-एल" कमांड का उपयोग करके प्रदर्शित किया जा सकता है।

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

SELinux नीतियों के लिए मॉड्यूल का मैनुअल कॉन्फ़िगरेशन।

Adit2allow, एक शक के बिना, एक विशिष्ट समस्या को हल करने वाली नीतियों के लिए मॉडल बनाने के साथ मुकाबला करता है। लेकिन कभी-कभी यह उपयोगिता काफी सही काम नहीं करती है, इसलिए आपको मॉड्यूल को मैन्युअल रूप से कॉन्फ़िगर करना होगा। उदाहरण के लिए, SELinux AVC लॉग प्रविष्टियों पर विचार करें:

 Summary: SELinux is preventing postdrop (postfix_postdrop_t) "getattr" to /var/log/httpd/error_log (httpd_log_t). Detailed Description: SELinux denied access requested by postdrop. It is not expected that this access is required by postdrop and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/log/httpd/error_log, restorecon -v '/var/log/httpd/error_log' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:postfix_postdrop_t Target Context root:object_r:httpd_log_t Target Objects /var/log/httpd/error_log [ file ] Source postdrop Source Path /usr/sbin/postdrop Port <Unknown> Host sanitized Source RPM Packages postfix-2.3.3-2 Target RPM Packages Policy RPM selinux-policy-2.4.6-137.1.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name sanitized Platform Linux sanitized 2.6.18-53.1.21.el5 #1 SMP Tue May 20 09:35:07 EDT 2008 x86_64 x86_64 Alert Count 599 First Seen Wed Jul 2 08:27:15 2008 Last Seen Sun Aug 10 22:47:52 2008 Local ID c303a4ea-8e7a-4acc-9118-9cc61c6a2ec8 Line Numbers Raw Audit Messages host=sanitized type=AVC msg=audit(1218397672.372:352): avc: denied { getattr } for pid=4262 comm="postdrop" path="/var/log/httpd/error_log" dev=md2 ino=117005 scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=root:object_r:httpd_log_t:s0 tclass=file host=sanitized type=SYSCALL msg=audit(1218397672.372:352): arch=c000003e syscall=5 success=no exit=-13 a0=2 a1=7fffd6febca0 a2=7fffd6febca0 a3=0 items=0 ppid=4261 pid=4262 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=90 sgid=90 fsgid=90 tty=(none) comm="postdrop" exe="/usr/sbin/postdrop" subj=system_u:system_r:postfix_postdrop_t:s0 key=(null)

जब हम ऑडिट 2 को चलाते हैं और परिणामी postfixlocal.te नीति को देखते हैं, तो हम निम्नलिखित देखेंगे:

 # grep postdrop /var/log/audit/audit.log | audit2allow -M postfixlocal # cat postfixlocal.te module postfixlocal 1.0; require { type httpd_log_t; type postfix_postdrop_t; class dir getattr; class file { read getattr }; } #============= postfix_postdrop_t ============== allow postfix_postdrop_t httpd_log_t:file getattr;

प्रश्न तुरंत उठता है, कि पोस्टड्रॉप / var / log / httpd / error_log का उपयोग करने की कोशिश क्यों की जा रही है? यह वह क्रिया नहीं है जिसकी हम इस कार्यक्रम से उम्मीद कर सकते हैं, इसलिए अब यह तय करना है कि हम इस कार्रवाई की अनुमति दें या नहीं।

इस समस्या को हल करने के लिए हमारे पास कई तरीके हैं।

- हम इस त्रुटि को अनदेखा कर सकते हैं और SELinux को फ़ाइल तक पहुँच को अवरुद्ध करने की अनुमति दे सकते हैं।

- हम ऑडिट 2 क्लाउड का उपयोग करके एक उचित नीति मॉड्यूल बनाकर इस कार्रवाई को सक्षम कर सकते हैं।
- हम फ़ाइल का उपयोग करने के प्रयास के लिए वांछित SELinux प्रतिक्रिया निर्धारित करने के लिए इस मॉड्यूल की फ़ाइल को मैन्युअल रूप से संपादित कर सकते हैं। उदाहरण के लिए, हम इस इवेंट के ऑडिट पर रोक लगा सकते हैं, जबकि एक्सेस को ब्लॉक कर सकते हैं। ऐसा करने के लिए, हमें "NOTaudit" के अनुरूप लाइन में "अनुमति" मान को बदलना होगा:

 #============= postfix_postdrop_t ============== dontaudit postfix_postdrop_t httpd_log_t:file getattr;

अब हमें संपादित नीति मॉड्यूल को मैन्युअल रूप से संकलित और लोड करना होगा:

 # checkmodule -M -m -o postfixlocal.mod postfixlocal.te # semodule_package -o postfixlocal.pp -m postfixlocal.mod # semodule -i postfixlocal.pp

इस प्रकार, फ़ाइल / var / log / httpd / error_log तक पहुंच अवरुद्ध है, लेकिन हमें SELinux से इसके बारे में लगातार चेतावनी नहीं मिलती है।

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

SELinux - प्रणाली के साथ काम करने का विवरण और विशेषताएं। भाग २

SELinux नीतियाँ अनुकूलित करना

लेखा परीक्षा 2 के साथ कस्टम नीतियां बनाना

SELinux नीतियों के लिए मॉड्यूल का मैनुअल कॉन्फ़िगरेशन।

More articles: