Docker --privileged

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert)!

क्या आप साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आप PEASS के नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करना चाहते हैं? सब्सक्रिप्शन प्लान्स देखें!
The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह
आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या मुझे ट्विटर 🐦@carlospolopm** पर फॉलो** करें।
अपने हैकिंग ट्रिक्स साझा करें, hacktricks रेपो और hacktricks-cloud रेपो में PR जमा करके।

क्या प्रभावित होता है

जब आप एक कंटेनर को --privileged के रूप में चलाते हैं, तो आप इन सुरक्षा उपायों को अक्षम कर देते हैं:

/dev माउंट करें

एक --privileged कंटेनर में, सभी डिवाइस /dev/ में पहुंच सकते हैं। इसलिए आप माउंट करके होस्ट के डिस्क से बाहर निकल सकते हैं।

# docker run --rm -it alpine sh
ls /dev
console  fd       mqueue   ptmx     random   stderr   stdout   urandom
core     full     null     pts      shm      stdin    tty      zero

# docker run --rm --privileged -it alpine sh
ls /dev
cachefiles       mapper           port             shm              tty24            tty44            tty7
console          mem              psaux            stderr           tty25            tty45            tty8
core             mqueue           ptmx             stdin            tty26            tty46            tty9
cpu              nbd0             pts              stdout           tty27            tty47            ttyS0
[...]

केवल पढ़ने योग्य कर्नेल फ़ाइल सिस्टम

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

# docker run --rm -it alpine sh
mount | grep '(ro'
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
cpuset on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
cpu on /sys/fs/cgroup/cpu type cgroup (ro,nosuid,nodev,noexec,relatime,cpu)
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpuacct)

# docker run --rm --privileged -it alpine sh
mount  | grep '(ro'

कर्नेल फ़ाइल सिस्टम को मास्क करना

/proc फ़ाइल सिस्टम को चयनित रूप से लिखने योग्य है लेकिन सुरक्षा के लिए, कुछ हिस्से लिखने और पढ़ने की पहुंच को रोकने के लिए उन्हें tmpfs से ढक दिया गया है, यह सुनिश्चित करता है कि कंटेनर प्रक्रियाएँ संवेदनशील क्षेत्रों तक पहुंच नहीं पा सकतीं।

tmpfs एक फ़ाइल सिस्टम है जो सभी फ़ाइलों को वर्चुअल मेमोरी में स्टोर करता है। tmpfs आपके हार्ड ड्राइव पर कोई फ़ाइल नहीं बनाता है। इसलिए अगर आप एक tmpfs फ़ाइल सिस्टम को अनमाउंट करते हैं, तो उसमें रहने वाली सभी फ़ाइलें हमेशा के लिए खो जाती हैं।

# docker run --rm -it alpine sh
mount  | grep /proc.*tmpfs
tmpfs on /proc/acpi type tmpfs (ro,relatime)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755)

# docker run --rm --privileged -it alpine sh
mount  | grep /proc.*tmpfs

लिनक्स क्षमताएँ

कंटेनर इंजन डिफ़ॉल्ट रूप से कंटेनर को अंदर क्या हो रहा है को नियंत्रित करने के लिए कुछ सीमित संख्या की क्षमताएँ के साथ चलाता है। विशेषाधिकृत वाले में सभी क्षमताएँ एक्सेस करने के योग्य होती हैं। क्षमताओं के बारे में जानने के लिए पढ़ें:

pageLinux Capabilities

# docker run --rm -it alpine sh
apk add -U libcap; capsh --print
[...]
Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=eip
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
[...]

# docker run --rm --privileged -it alpine sh
apk add -U libcap; capsh --print
[...]
Current: =eip cap_perfmon,cap_bpf,cap_checkpoint_restore-eip
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
[...]

आप डॉकर मोड में --privileged चलाए बिना एक कंटेनर के लिए उपलब्ध क्षमताओं को परिवर्तित कर सकते हैं --cap-add और --cap-drop फ्लैग्स का उपयोग करके।

Seccomp

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

pageSeccomp

# docker run --rm -it alpine sh
grep Seccomp /proc/1/status
Seccomp:	2
Seccomp_filters:	1

# docker run --rm --privileged -it alpine sh
grep Seccomp /proc/1/status
Seccomp:	0
Seccomp_filters:	0

# You can manually disable seccomp in docker with
--security-opt seccomp=unconfined

ध्यान दें कि जब Kubernetes क्लस्टर में Docker (या अन्य CRIs) का उपयोग किया जाता है, तो seccomp फ़िल्टर डिफ़ॉल्ट रूप से अक्षम हो जाता है।

AppArmor

AppArmor एक कर्नेल एन्हांसमेंट है जो कंटेनर को सीमित संसाधनों के साथ प्रति-प्रोग्राम प्रोफ़ाइल में सीमित करने के लिए है। जब आप --privileged फ़्लैग के साथ चलाते हैं, यह सुरक्षा अक्षम हो जाती है।

pageAppArmor

# You can manually disable seccomp in docker with
--security-opt apparmor=unconfined

SELinux

कंटेनर को --privileged फ्लैग के साथ चलाने से SELinux लेबल निष्क्रिय हो जाते हैं, जिससे यह कंटेनर इंजन का लेबल विरासत में प्राप्त करता है, सामान्यत: unconfined, पूर्ण पहुंच प्रदान करते हुए। रूटलेस मोड में, यह container_runtime_t का उपयोग करता है, जबकि रूट मोड में, spc_t लागू होता है।

pageSELinux

# You can manually disable selinux in docker with
--security-opt label:disable

क्या प्रभावित नहीं होता

नेमस्पेस

नेमस्पेस --privileged फ्लैग द्वारा प्रभावित नहीं होते हैं। यहाँ तक कि जब उनमें सुरक्षा प्रतिबंध सक्षम नहीं होता, तो वे सिस्टम पर सभी प्रक्रियाएँ या मुख्य नेटवर्क को नहीं देखते हैं, उदाहरण के लिए। उपयोगकर्ता --pid=host, --net=host, --ipc=host, --uts=host कंटेनर इंजन फ्लैग का उपयोग करके व्यक्तिगत नेमस्पेस को अक्षम कर सकते हैं।

# docker run --rm --privileged -it alpine sh
ps -ef
PID   USER     TIME  COMMAND
1 root      0:00 sh
18 root      0:00 ps -ef

{% टैब शीर्षक="अंदर --pid=host कंटेनर" %}

# docker run --rm --privileged --pid=host -it alpine sh
ps -ef
PID   USER     TIME  COMMAND
1 root      0:03 /sbin/init
2 root      0:00 [kthreadd]
3 root      0:00 [rcu_gp]ount | grep /proc.*tmpfs
[...]

उपयोगकर्ता नेमस्पेस

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

संदर्भ

https://www.redhat.com/sysadmin/privileged-flag-container-engines

जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert)!

क्या आप साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी का हैकट्रिक्स में विज्ञापन देखना चाहते हैं? या क्या आपको PEASS के नवीनतम संस्करण या हैकट्रिक्स को पीडीएफ़ में डाउनलोड करने का एक्सेस चाहिए? सब्सक्रिप्शन प्लान्स की जाँच करें!
द पीएस फैमिली की खोज करें, हमारा विशेष एनएफटीएस संग्रह।
आधिकारिक PEASS और हैकट्रिक्स स्वैग प्राप्त करें।
शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह या मुझे ट्विटर पर फ़ॉलो करें 🐦@carlospolopm।
हैकिंग ट्रिक्स साझा करें, हैकट्रिक्स रेपो और हैकट्रिक्स-क्लाउड रेपो में पीआर जमा करके।

PreviousCGroups NextDocker Breakout / Privilege Escalation

Last updated 3 months ago