कठोर जेंटू: विवरण

शुरू करने के लिए, मैं समझाता हूँ कि मैं इस लेख को क्यों प्रकाशित कर रहा हूँ। तथ्य यह है कि ज्यादातर Gentoo लिनक्स उपयोगकर्ता अभी भी Hardent Gentoo का उपयोग नहीं करते हैं। और यह आमतौर पर इस तथ्य के कारण होता है कि वे या तो यह नहीं जानते कि यह क्या है, या तो उन्हें लगता है कि यह बहुत जटिल है, या उन्हें लगता है कि स्थिरता, कार्यक्षमता या सिस्टम प्रदर्शन से इसका नुकसान होगा। ये वे भय हैं जिन्हें मैं दूर करना चाहता हूं।



कठोर गेंटू संकलक और कर्नेल में कुछ बदलाव हैं जो सिस्टम की समग्र सुरक्षा को हैकिंग से बढ़ाते हैं। उदाहरण के लिए, कठोर कर्नेल संभावित रूप से खतरनाक ऑपरेशनों को रोक सकता है, और कठोर-जीसीसी उन कार्यक्रमों की सुरक्षा करता है जो हैकिंग के खिलाफ संकलित करता है विशिष्ट तरीकों का उपयोग करके ला बफर अतिप्रवाह। मोटे तौर पर, अगर आपके पास प्रोग्राम X का "छेददार" संस्करण है और एक हैकर इसे क्रैक करने की कोशिश कर रहा है, तो यह एक नियमित प्रणाली में सफल होगा, लेकिन यह कड़े में काम नहीं करेगा, और यह लॉग को भी लिख देगा।



एक नियमित Gentoo पर कठोर स्थापित करने के लिए, आपको पूरी प्रणाली को पूरी तरह से पुन: स्थापित करने की आवश्यकता होगी - अन्यथा कठोर-जीसीसी द्वारा प्रदान किए गए सुरक्षा का उपयोग नहीं किया जाएगा। कठोर एक और प्रणाली है जिसे सावधानीपूर्वक कॉन्फ़िगर करने की आवश्यकता है - आपने इसे सुरक्षा के साथ ओवरडोज़ किया है - यह बिल्कुल भी काम नहीं करता है, आप इसे ज़्यादा नहीं करते हैं - फिर क्यों कठोर बनाया गया है? कड़े के साथ कुछ प्रोग्राम साथ नहीं मिलते हैं (आमतौर पर बाइनरी पैकेज: फायरवुड एनवीडिया / एटीआई, जावा प्लस किसी कारण सॉफ़्टवेयर जैसे कि mplayer / xmms के लिए) - यह घातक नहीं है, आपको बस इन कार्यक्रमों के लिए कुछ सुरक्षा को अक्षम करना होगा (इसके लिए उपयोगिताओं हैं ...) क्या हो रहा है। कर्नेल का उपयोग हार्ड-सोर्स पैकेज से किया जाता है, और यह आमतौर पर कुछ संस्करणों के लिए जेंटू-स्रोतों से पीछे रहता है।



इसलिए, हार्डेंट जेंटू कई अलग-अलग, अक्सर एक-दूसरे से स्वतंत्र, परियोजनाओं का एक संयोजन है:

1. कठोर टूलचिन - gcc / glibc / binutils पर विशेष पैच:
   
   
   • SSP - बाइनरी में बफर अतिप्रवाह सुरक्षा जोड़ता है, अर्थात। SSP के साथ संकलित कार्यक्रम स्वयं यह जाँचता है कि यह अतिप्रवाह का पता नहीं लगाता है और अगर यह अतिप्रवाह का पता लगाता है (प्रोग्राम में एक बग के परिणामस्वरूप या इसे एक क्रैक के साथ क्रैक करने का प्रयास करता है)।
   • पाई - खुद से सुरक्षा में वृद्धि नहीं करता है, लेकिन अधिक लचीली कोड की पीढ़ी की ओर जाता है, इसलिए इसे PaX के कर्नेल स्तर पर संरक्षित किया जा सकता है।
   
   
   PIE और SSP एक दूसरे से स्वतंत्र होते हैं, और उन्हें एक साथ और अलग से उपयोग किया जा सकता है (कड़े टूलचिन को संकलित करने के बाद, सभी विकल्पों के बीच स्विच करने के लिए gcc-config के माध्यम से संभव होगा - PIE + SSP, केवल PIE, केवल SSP, कुछ भी नहीं (अर्थात सामान्य) gcc) - उदाहरण के लिए, यदि किसी प्रकार का कार्यक्रम संकलित नहीं होगा।
2. कोर को पैच करता है। उनमें से बहुत सारे हैं, और अलग-अलग :), लेकिन जेंटू केवल उनमें से चार का समर्थन करता है - PaX , SeLinux , GrSecurity और RSBAC । कार्यक्षमता वे तीन प्रकार जोड़ते हैं:
   
   
   1. बफर अतिप्रवाह संरक्षण (एक ला एसएसपी लेकिन कर्नेल और अन्य तरीकों से, ताकि वे एक दूसरे के पूरक हों): पीएक्स। उदाहरण के लिए, PaX आपको डेटा के साथ डेटा पेजों में कोड के निष्पादन पर रोक लगाने की अनुमति देता है (NX-bit का सॉफ़्टवेयर कार्यान्वयन, जो केवल इंटेल के 64-बिट प्रतिशत में दिखाई दिया) - PaX सिर्फ इस प्रक्रिया को मारता है यदि वह इस सुरक्षा का उल्लंघन करने की कोशिश करता है; जब किसी प्रोग्राम को मेमोरी में लोड किया जाता है, तो यह यादृच्छिक पते पर अपने सभी कार्यों को लोड करता है, इसलिए किसी शोषण के लिए यह पता लगाना बहुत मुश्किल होता है कि कंट्रोल को ट्रांसफर करने के लिए कौन सा पता है (यह पाई के साथ संकलन के कारण संभव हो जाता है)।
   2. संभावित खतरनाक कर्नेल सुविधाओं को अक्षम करना: Grececurity, RSBAC। उदाहरण: चेरोट के अंदर माउंट को निष्पादित करने के लिए निषेध - ताकि एक हैकर जो चेरोट-माइंडेड डेमॉन में टूट जाए और जड़ हो जाए, चेरोट से बाहर नहीं निकल सके।
   3. सहित प्रक्रियाओं और उपयोगकर्ताओं के अधिकारों का प्रतिबंध (मैं यह भी कहूंगा - ज्यादातर) मूल उपयोगकर्ता के: SeLinux, GrSecurity / RBAC, RSBAC। यहां यह विचार है कि व्यवस्थापक (आपको :)) को यह इंगित करने के लिए एक सूची तैयार करने की आवश्यकता है कि कौन से प्रोग्राम / उपयोगकर्ता को उनके पास क्या करने का अधिकार है। उदाहरण: आप अपाचे रूट प्रक्रिया को सभी रूट अधिकारों से पोर्ट 80 पर बैठने की क्षमता और / etc / apos2 / में फाइल पढ़ने के लिए प्रतिबंधित कर सकते हैं। इस स्थिति में, भले ही इसे हैक किया गया हो और हैकर को "रूट" मिलता है, तो यह "रूट" केवल उपरोक्त ऑपरेशन कर सकता है ... हैकर बेहद निराश होगा। :)
   
   
   ये तीन "सुविधाएँ" भी एक दूसरे पर निर्भर नहीं करती हैं। लेकिन खुद पैच - सेलाइनक्स, ग्रैसिटी और आरएसबीएसी आमतौर पर एक-दूसरे के साथ संगत नहीं होते हैं और आपको उनमें से केवल एक का उपयोग करने की आवश्यकता होती है। हालाँकि, Gentoo SeLinux और GrSecurity को एक साथ मिलाने में कामयाब रहा। ग्रामसुरिटी का वह हिस्सा जो तीसरी विशेषता (अधिकारों का प्रतिबंध) से संबंधित है, RBAC कहलाता है, और इसे SeLinux के साथ एक साथ उपयोग नहीं किया जा सकता है - या तो।
   
   कुल मिलाकर, विकल्प हैं, उदाहरण के लिए, निम्नलिखित:
   
   
   • पैक्स + ग्रामसुरक्षा
   • PaX + GrSecurity (RBAC के बिना) + SeLinux
   • पैक्स + सेलाइनक्स
   • पैक्स + आरएसबीएसी
   • ... आदि ...
   
   
   मैंने तब से पहला (PaX + GrSecurity) चुना सबसे पहले, Seininux की स्थापना एक दुःस्वप्न होने का वादा करती है, Grececurity / RBAC के विपरीत; दूसरे, मेरी राय में, Gentoo में RSBAC के लिए समर्थन अभी भी नम है; और तीसरी बात, मुझे ग्रैसिटी पसंद है, मुझे यह पसंद आया। :))

जारी रखने के लिए ...



नोट: पाठ का एक भाग दो साल पहले लिखा गया था , और maillist gentoo-user-ru में प्रकाशित किया गया था । मैं पाठ को 4 भागों में तोड़ना चाहता हूं (क्योंकि लंबे विषयों का हब पर स्वागत नहीं है), साथ ही इसे वर्तमान मामलों की जानकारी के साथ पूरक करने के लिए (लेकिन तब से नाटकीय रूप से कुछ भी नहीं बदला है, बस छोटी समस्याएं छोटी हो गई हैं)।