LID

``` ██╗ ██╗██████╗ ██║ ██║██╔══██╗ ██║ ██║██║ ██║ ██║ ██║██║ ██║ ███████╗██║██████╔╝ ╚══════╝╚═╝╚═════╝ ```

लिनक्स इंटीग्रिटी ड्रिफ्ट

— "लिनक्स मर रहा है" —

LSM सुरक्षा गारंटियों को बायपास करने वाले कर्नेल कोड पथों की व्यवस्थित खोज
_{गेट कभी तोड़ा नहीं गया। इसे बस घूमकर पार किया गया।}

---

LID क्या है?

लिनक्स सिक्योरिटी मॉड्यूल फ्रेमवर्क की एक मुख्य गारंटी है जो 20+ वर्षों से बनी हुई है:

सुरक्षा मॉड्यूल केवल प्रतिबंध जोड़ सकते हैं। वे कभी भी प्रतिबंध हटा नहीं सकते।

यह गारंटी सही है। LID इसे तोड़ता नहीं है।

LID ऐसे कर्नेल कोड पथ ढूंढता है जो LSM हुक को पूरी तरह से बायपास करते हैं — वे सबसिस्टम जो LSM फ्रेमवर्क से परामर्श किए बिना सुरक्षा-संवेदनशील संचालन करते हैं। सुरक्षा जांच सही है। समस्या यह है कि कर्नेल कभी पूछता ही नहीं।

यह समझना कि LID क्या है (और क्या नहीं है)

प्रत्येक खोज के दो अलग-अलग आयाम हैं जिन्हें भ्रमित नहीं किया जाना चाहिए:

A) नीति दृश्यता अंतर

वास्तुशिल्पीय अंध-स्थान। सवाल यह नहीं है कि "क्या कोई हमलावर इसका शोषण कर सकता है?" बल्कि:

• AppArmor/SELinux वास्तव में क्या देखता है?
• ऑडिट लॉग क्या रिकॉर्ड करता है?
• आपका SIEM/EDR क्या अवलोकन करता है?
• नीति इंजन को क्या लगता है कि हुआ?

यदि कोई सुरक्षा-संवेदनशील संचालन होता है और प्रवर्तन स्तर उसका मूल्यांकन भी नहीं करता, तो आपके पास एक दृश्यता अंतर है — भले ही आज कोई हमलावर व्यावहारिक रूप से इसका दुरुपयोग कर सके या नहीं। यह अनुपालन, फोरेंसिक्स, और गहराई-में-रक्षा धारणाओं के लिए मायने रखता है।

B) व्यावहारिक एस्केलेशन पथ

वास्तविक दुनिया की शोषण-क्षमता का सवाल:

• क्या यह एक विशेषाधिकार सीमा को पार करता है?
• क्या हमलावर को इसे ट्रिगर करने के लिए मौजूदा रूट/CAP_BPF की आवश्यकता है?
• क्या एक शोषण श्रृंखला आवश्यक है, या यह स्वतंत्र है?
• वास्तविक प्रभाव क्या है — डेटा एक्सेस, विशेषाधिकार वृद्धि, नीति चोरी?

ये दो चीजें अलग हैं। एक खोज एक महत्वपूर्ण दृश्यता अंतर हो सकती है (आपकी निगरानी अंधी है) बिना एक व्यावहारिक विशेषाधिकार वृद्धि (हमलावर को पहले से रूट चाहिए) के। इसके विपरीत, एक खोज न्यूनतम पूर्वापेक्षाओं के साथ एक सीधा एस्केलेशन पथ हो सकता है।

खोज	दृश्यता अंतर	व्यावहारिक एस्केलेशन
LID-001	महत्वपूर्ण — AppArmor कुछ नहीं देखता, ऑडिट लॉग खाली, शून्य फोरेंसिक निशान	सीमित — रूट या CAP_BPF+CAP_PERFMON आवश्यक (पहले से ही विशेषाधिकार प्राप्त)। यह विशेषाधिकार वृद्धि नहीं है। प्रभाव: नीति चोरी + ऑडिट अंधापन।
LID-002	उच्च — security_file_receive() कभी फायर नहीं होता, fd स्थानांतरण सभी LSM के लिए अदृश्य	उच्च — अविशेषाधिकार प्राप्त उपयोगकर्तास्थान से io_uring के माध्यम से काम करता है। बिना किसी विशेषाधिकार के LSM प्रवर्तन सीमा पार करता है।
LID-003	उच्च — security_sb_mount() बायपास हुआ, AppArmor माउंट नीति मृत कोड है	मध्यम — माउंट नेमस्पेस एक्सेस की आवश्यकता है (उपयोगकर्ता ns में CAP_SYS_ADMIN)। कई कंटेनर कॉन्फ़िग में उपलब्ध।
LID-004	महत्वपूर्ण — AppArmor कुछ नहीं देखता, शून्य BPF हुक (0/9), किसी भी BPF टोकन संचालन के लिए कोई ऑडिट ट्रेस नहीं	मध्यम — होस्ट द्वारा bpffs प्रतिनिधिमंडल + उपयोगकर्ता नेमस्पेस में CAP_BPF आवश्यक। BPF प्रतिनिधिमंडल (LXD/Incus) वाले कंटेनर रनटाइम में उपलब्ध।
LID-005	मध्यम — कंटेनर इंटरफ़ेस पर tc ईग्रेस क्लासिफायर कभी AF_XDP ट्रैफ़िक का मूल्यांकन नहीं करते	सीमित — कंटेनर eth0 पर tc ईग्रेस को बायपास करता है (सत्यापित)। Cilium बायपास नहीं हुआ — नोड-साइड veth इनग्रेस पर प्रवर्तन + स्रोत IP सत्यापन (परीक्षण किया गया)। प्रभाव केवल tc-मात्र ईग्रेस फ़िल्टरिंग वाले सादे-Docker सेटअप तक सीमित।

पुनरुत्पादन मैट्रिक्स

प्रत्येक खोज के विशिष्ट कर्नेल/कॉन्फ़िग/विशेषाधिकार आवश्यकताएँ हैं। यदि आपका वातावरण मेल नहीं खाता, तो खोज पुनरुत्पादित नहीं होगी।

LID-001: eBPF पथनाम पुनर्लेखन

शर्त	आवश्यक	नोट्स
कर्नेल संस्करण	5.x+	5.15, 6.1, 6.6, 6.8 पर परीक्षित
CONFIG_BPF_SYSCALL	=y	सभी प्रमुख डिस्ट्रो पर डिफ़ॉल्ट
CONFIG_BPF_KPROBE_OVERRIDE	=y	Ubuntu/Debian इसे सक्षम करते हैं, RHEL नहीं
CONFIG_SECURITY_APPARMOR	=y	लक्ष्य LSM AppArmor होना चाहिए
AppArmor प्रोफ़ाइल	प्रवर्तन, लक्ष्य पथ पर नियम अस्वीकार करें	किसी भी पथ-आधारित अस्वीकार नियम के साथ काम करता है
विशेषाधिकार	root या CAP_BPF + CAP_PERFMON	अविशेषाधिकार प्राप्त रूप से नहीं चल सकता
kernel.lockdown	none या integrity	confidentiality मोड kprobe अटैचमेंट को ब्लॉक करता है
kernel.unprivileged_bpf_disabled	अप्रासंगिक	CAP_BPF की आवश्यकता वैसे भी
fs.protected_hardlinks	क्रॉस-यूज़र लिंक के लिए 0	1 (डिफ़ॉल्ट) अभी भी समान-उपयोगकर्ता हार्ड लिंक की अनुमति देता है
SELinux बजाय AppArmor	काम नहीं करता	SELinux इनोड-आधारित है, पथनाम-आधारित नहीं

LID-002: io_uring MSG_RING

शर्त	आवश्यक	नोट्स
कर्नेल संस्करण	6.0+	IORING_MSG_SEND_FD 6.0 में जोड़ा गया
CONFIG_IO_URING	=y	सभी प्रमुख डिस्ट्रो पर डिफ़ॉल्ट
विशेषाधिकार	कोई नहीं	अविशेषाधिकार प्राप्त उपयोगकर्तास्थान से काम करता है
io_uring_disabled sysctl	0 (डिफ़ॉल्ट)	2 अविशेषाधिकार प्राप्त को ब्लॉक करता है, 1 सभी को ब्लॉक करता है
लक्ष्य LSM	कोई भी (SELinux, AppArmor, Smack)	security_file_receive() एक सामान्य LSM हुक है
kernel.lockdown	अप्रासंगिक	कोई BPF शामिल नहीं

LID-004: BPF टोकन AppArmor अंधापन

शर्त	आवश्यक	नोट्स
कर्नेल संस्करण	6.9+	BPF टोकन 6.9 में पेश किया गया
CONFIG_BPF_SYSCALL	=y	सभी प्रमुख डिस्ट्रो पर डिफ़ॉल्ट
CONFIG_SECURITY_APPARMOR	=y	Ubuntu/Debian डिफ़ॉल्ट
bpffs प्रतिनिधिमंडल के साथ	हाँ	होस्ट को delegate_* विकल्पों के साथ माउंट करना होगा
विशेषाधिकार	उपयोगकर्ता नेमस्पेस में CAP_BPF	userns रूट के लिए तुच्छ रूप से उपलब्ध
SELinux बजाय AppArmor	प्रभावित नहीं	SELinux सभी 9 BPF हुक लागू करता है

LID-003: नया माउंट API

शर्त	आवश्यक	नोट्स
कर्नेल संस्करण	5.2+	fsopen/fsmount 5.2 में पेश किया गया
CONFIG_SECURITY_APPARMOR	=y	केवल AppArmor प्रभावित है
विशेषाधिकार	उपयोगकर्ता नेमस्पेस में CAP_SYS_ADMIN	unshare -m के साथ उपलब्ध
SELinux बजाय AppArmor	काम नहीं करता	SELinux security_sb_kern_mount() लागू करता है
कंटेनर रनटाइम	seccomp फ़िल्टर पर निर्भर करता है	Docker डिफ़ॉल्ट seccomp fsopen को ब्लॉक करता है — Podman/LXC शायद न करें

LID-005: AF_XDP tc ईग्रेस बायपास

शर्त	आवश्यक	नोट्स
कर्नेल संस्करण	4.18+	AF_XDP 4.18 में पेश किया गया
CONFIG_XDP_SOCKETS	=y	सभी प्रमुख डिस्ट्रो पर डिफ़ॉल्ट
विशेषाधिकार	केवल CAP_NET_RAW	Docker, Kubernetes पॉड में डिफ़ॉल्ट
कंटेनर रनटाइम	Docker, K8s, LXC	डिफ़ॉल्ट क्षमता सेट
tc-आधारित नेटवर्क नीति	हाँ	Cilium eBPF, Calico, tc u32/flower

त्वरित संदर्भ: प्रत्येक खोज को क्या ब्लॉक करता है