AppArmor
PreviousAbusing Docker Socket for Privilege EscalationNextAuthZ& AuthN - Docker Access Authorization Plugin
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AppArmor एक कर्नेल संवर्धन है जिसे कार्यक्रमों के लिए उपलब्ध संसाधनों को प्रति-कार्यक्रम प्रोफाइल के माध्यम से प्रतिबंधित करने के लिए डिज़ाइन किया गया है, प्रभावी रूप से अनिवार्य पहुँच नियंत्रण (MAC) को लागू करता है, जो पहुँच नियंत्रण विशेषताओं को सीधे कार्यक्रमों से जोड़ता है बजाय उपयोगकर्ताओं के। यह प्रणाली कर्नेल में प्रोफाइल लोड करके काम करती है, आमतौर पर बूट के दौरान, और ये प्रोफाइल निर्धारित करते हैं कि एक कार्यक्रम किन संसाधनों तक पहुँच सकता है, जैसे नेटवर्क कनेक्शन, कच्चे सॉकेट तक पहुँच, और फ़ाइल अनुमतियाँ।
AppArmor प्रोफाइल के लिए दो संचालन मोड हैं:
Enforcement Mode: यह मोड प्रोफाइल के भीतर परिभाषित नीतियों को सक्रिय रूप से लागू करता है, उन क्रियाओं को अवरुद्ध करता है जो इन नीतियों का उल्लंघन करती हैं और syslog या auditd जैसे सिस्टम के माध्यम से उल्लंघन के किसी भी प्रयास को लॉग करता है।
Complain Mode: प्रवर्तन मोड के विपरीत, शिकायत मोड उन क्रियाओं को अवरुद्ध नहीं करता है जो प्रोफाइल की नीतियों के खिलाफ जाती हैं। इसके बजाय, यह इन प्रयासों को नीति उल्लंघनों के रूप में लॉग करता है बिना प्रतिबंध लागू किए।
Kernel Module: नीतियों के प्रवर्तन के लिए जिम्मेदार।
Policies: कार्यक्रम के व्यवहार और संसाधन पहुँच के लिए नियम और प्रतिबंध निर्दिष्ट करते हैं।
Parser: प्रवर्तन या रिपोर्टिंग के लिए नीतियों को कर्नेल में लोड करता है।
Utilities: ये उपयोगकर्ता-मोड कार्यक्रम हैं जो AppArmor के साथ बातचीत करने और प्रबंधित करने के लिए एक इंटरफ़ेस प्रदान करते हैं।
Apparmor प्रोफाइल आमतौर पर /etc/apparmor.d/ में सहेजे जाते हैं।
sudo aa-status के साथ आप उन बाइनरीज़ की सूची प्राप्त कर सकेंगे जो किसी प्रोफाइल द्वारा प्रतिबंधित हैं। यदि आप सूचीबद्ध प्रत्येक बाइनरी के पथ में "/" को बिंदु में बदल सकते हैं, तो आप उल्लेखित फ़ोल्डर के भीतर apparmor प्रोफाइल का नाम प्राप्त करेंगे।
उदाहरण के लिए, /usr/bin/man के लिए एक apparmor प्रोफाइल /etc/apparmor.d/usr.bin.man में स्थित होगा।
प्रभावित निष्पादन योग्य को इंगित करने के लिए, पूर्ण पथ और वाइल्डकार्ड फ़ाइलों को निर्दिष्ट करने के लिए अनुमति है।
यह इंगित करने के लिए कि बाइनरी के पास फाइलों पर क्या पहुंच होगी, निम्नलिखित एक्सेस नियंत्रण का उपयोग किया जा सकता है:
r (पढ़ें)
w (लिखें)
m (निष्पादन योग्य के रूप में मेमोरी मैप)
k (फाइल लॉकिंग)
l (हार्ड लिंक बनाना)
ix (एक नए प्रोग्राम के साथ दूसरे प्रोग्राम को निष्पादित करने के लिए नीति विरासत में लेना)
Px (दूसरे प्रोफ़ाइल के तहत निष्पादित करें, पर्यावरण को साफ़ करने के बाद)
Cx (एक बच्चे के प्रोफ़ाइल के तहत निष्पादित करें, पर्यावरण को साफ़ करने के बाद)
Ux (बिना किसी प्रतिबंध के निष्पादित करें, पर्यावरण को साफ़ करने के बाद)
चर प्रोफ़ाइल में परिभाषित किए जा सकते हैं और प्रोफ़ाइल के बाहर से हेरफेर किया जा सकता है। उदाहरण: @{PROC} और @{HOME} (प्रोफ़ाइल फ़ाइल में #include <tunables/global> जोड़ें)
अनुमति नियमों को ओवरराइड करने के लिए अस्वीकृति नियमों का समर्थन किया जाता है।
प्रोफ़ाइल बनाने की प्रक्रिया को आसानी से शुरू करने के लिए apparmor आपकी मदद कर सकता है। यह संभव है कि apparmor बाइनरी द्वारा किए गए कार्यों का निरीक्षण करे और फिर आपको यह तय करने दे कि आप कौन से कार्यों की अनुमति देना या अस्वीकृत करना चाहते हैं। आपको बस यह चलाना है:
फिर, एक अलग कंसोल में सभी क्रियाएँ करें जो बाइनरी सामान्यतः करेगी:
फिर, पहले कंसोल में "s" दबाएं और फिर रिकॉर्ड की गई क्रियाओं में बताएं कि आप क्या अनदेखा, अनुमति या कुछ और करना चाहते हैं। जब आप समाप्त कर लें, तो "f" दबाएं और नया प्रोफ़ाइल /etc/apparmor.d/path.to.binary में बनाया जाएगा।
तीर कुंजियों का उपयोग करके आप चुन सकते हैं कि आप क्या अनुमति/अस्वीकृत/कुछ और करना चाहते हैं
आप एक बाइनरी के apparmor प्रोफ़ाइल का टेम्पलेट भी बना सकते हैं:
ध्यान दें कि एक बनाए गए प्रोफ़ाइल में डिफ़ॉल्ट रूप से कुछ भी अनुमति नहीं है, इसलिए सब कुछ अस्वीकृत है। आपको उदाहरण के लिए बाइनरी को /etc/passwd पढ़ने की अनुमति देने के लिए /etc/passwd r, जैसी पंक्तियाँ जोड़ने की आवश्यकता होगी।
आप फिर लागू कर सकते हैं नया प्रोफ़ाइल के साथ
निम्नलिखित उपकरण लॉग पढ़ेगा और उपयोगकर्ता से पूछेगा कि क्या वह कुछ पहचाने गए प्रतिबंधित क्रियाओं की अनुमति देना चाहता है:
तीर कुंजियों का उपयोग करके आप चुन सकते हैं कि आप क्या अनुमति देना/अस्वीकृत करना/कुछ और करना चाहते हैं
Example of AUDIT and DENIED logs from /var/log/audit/audit.log of the executable service_bin:
आप इस जानकारी को निम्नलिखित का उपयोग करके भी प्राप्त कर सकते हैं:
ध्यान दें कि docker-profile का प्रोफ़ाइल डॉकर द्वारा डिफ़ॉल्ट रूप से लोड किया जाता है:
डिफ़ॉल्ट रूप से Apparmor docker-default profile https://github.com/moby/moby/tree/master/profiles/apparmor से उत्पन्न होता है
docker-default profile सारांश:
सभी नेटवर्किंग तक पहुँच
कोई क्षमता परिभाषित नहीं है (हालांकि, कुछ क्षमताएँ बुनियादी आधार नियमों को शामिल करने से आएंगी यानी #include <abstractions/base>)
किसी भी /proc फ़ाइल में लिखना अनुमति नहीं है
/proc और /sys के अन्य उपनिर्देशिकाएँ/फ़ाइलें पढ़ने/लिखने/लॉक/लिंक/कार्यन्वयन पहुँच के लिए अस्वीकृत हैं
माउंट अनुमति नहीं है
Ptrace केवल उस प्रक्रिया पर चलाया जा सकता है जो समान apparmor profile द्वारा सीमित है
एक बार जब आप docker container चलाते हैं, तो आपको निम्नलिखित आउटपुट देखना चाहिए:
ध्यान दें कि apparmor डिफ़ॉल्ट रूप से कंटेनर को दिए गए क्षमताओं के विशेषाधिकारों को भी ब्लॉक करेगा। उदाहरण के लिए, यह /proc के अंदर लिखने की अनुमति को ब्लॉक कर सकेगा, भले ही SYS_ADMIN क्षमता दी गई हो क्योंकि डिफ़ॉल्ट रूप से docker apparmor प्रोफ़ाइल इस एक्सेस को अस्वीकार करती है:
आपको इसकी सीमाओं को बायपास करने के लिए apparmor को अक्षम करना होगा:
ध्यान दें कि डिफ़ॉल्ट रूप से AppArmor कंटेनर को फोल्डर्स को माउंट करने से मना करेगा अंदर से, भले ही SYS_ADMIN क्षमता हो।
ध्यान दें कि आप docker कंटेनर में क्षमताएँ जोड़/हटा सकते हैं (यह अभी भी AppArmor और Seccomp जैसी सुरक्षा विधियों द्वारा प्रतिबंधित होगा):
--cap-add=SYS_ADMIN SYS_ADMIN क्षमता दें
--cap-add=ALL सभी क्षमताएँ दें
--cap-drop=ALL --cap-add=SYS_PTRACE सभी क्षमताएँ हटा दें और केवल SYS_PTRACE दें
आमतौर पर, जब आप पाते हैं कि आपके पास एक विशिष्ट क्षमता docker कंटेनर के अंदर उपलब्ध है लेकिन शोषण का कुछ हिस्सा काम नहीं कर रहा है, तो इसका कारण यह होगा कि docker apparmor इसे रोक रहा होगा।
(उदाहरण यहां से)
AppArmor कार्यक्षमता को स्पष्ट करने के लिए, मैंने एक नया Docker प्रोफ़ाइल "mydocker" बनाया जिसमें निम्नलिखित पंक्ति जोड़ी गई:
प्रोफ़ाइल को सक्रिय करने के लिए, हमें निम्नलिखित करना होगा:
प्रोफाइल की सूची बनाने के लिए, हम निम्नलिखित कमांड कर सकते हैं। नीचे दी गई कमांड मेरे नए AppArmor प्रोफाइल को सूचीबद्ध कर रही है।
जैसा कि नीचे दिखाया गया है, जब हम “/etc/” को बदलने की कोशिश करते हैं, तो हमें त्रुटि मिलती है क्योंकि AppArmor प्रोफ़ाइल “/etc” पर लिखने की पहुंच को रोक रही है।
आप यह पता लगा सकते हैं कि कौन सा apparmor प्रोफ़ाइल एक कंटेनर चला रहा है:
फिर, आप निम्नलिखित पंक्ति चला सकते हैं सटीक प्रोफ़ाइल खोजने के लिए जो उपयोग की जा रही है:
In the weird case you can modify the apparmor docker profile and reload it. You could remove the restrictions and "bypass" them.
AppArmor is path based, this means that even if it might be protecting files inside a directory like /proc if you can configure how the container is going to be run, you could mount the proc directory of the host inside /host/proc and it अब AppArmor द्वारा सुरक्षित नहीं होगा.
In this bug you can see an example of how even if you are preventing perl to be run with certain resources, if you just create a a shell script specifying in the first line #!/usr/bin/perl and you execute the file directly, you will be able to execute whatever you want. E.g.:
सीखें और AWS हैकिंग का अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) सीखें और GCP हैकिंग का अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
