LID

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

انحراف تكامل لينكس

— "لينكس يحتضر" —

اكتشاف منهجي لمسارات كود النواة التي تتجاوز ضمانات أمان LSM
_{لم تُخترق البوابة أبدًا. بل تم الالتفاف حولها.}

---

ما هو LID؟

إطار وحدة أمان لينكس لديه ضمان أساسي واحد استمر لأكثر من 20 عامًا:

وحدات الأمان يمكنها فقط إضافة قيود. لا يمكنها أبدًا إزالتها.

هذا الضمان صحيح. LID لا يخترقه.

LID يعثر على مسارات كود النواة التي تتجاوز خطافات LSM بالكامل — أنظمة فرعية تقوم بعمليات حساسة أمنيًا دون استشارة إطار LSM. الفحص الأمني صحيح. المشكلة هي أن النواة لا تسأل أبدًا.

فهم ما هو LID (وما ليس كذلك)

كل اكتشاف له بعدان متميزان لا ينبغي الخلط بينهما:

أ) فجوة رؤية السياسة

النقطة العمياء المعمارية. السؤال ليس "هل يمكن لمهاجم استغلال هذا؟"، بل:

• ما الذي يراه AppArmor/SELinux فعليًا؟
• ما الذي يسجله سجل التدقيق تسجيله؟
• ما الذي يلاحظه نظام SIEM/EDR الخاص بك؟
• ما الذي يعتقده محرك السياسات أنه حدث؟

إذا حدثت عملية حساسة أمنيًا ولم تقم طبقة الإنفاذ بتقييمها أبدًا، فإنك تعاني من فجوة رؤية — بغض النظر عما إذا كان بإمكان المهاجم إساءة استخدامها عمليًا اليوم. هذا مهم لـ الامتثال، الطب الشرعي، و افتراضات الدفاع المتعمق.

ب) مسار التصعيد العملي

سؤال قابلية الاستغلال في العالم الحقيقي:

• هل يعبر هذا حدود الامتياز؟
• هل يحتاج المهاجم إلى صلاحيات الجذر/ CAP_BPF الموجودة مسبقًا لتشغيله؟
• هل هناك حاجة إلى سلسلة استغلال، أم أنه مستقل؟
• ما هو التأثير الفعلي — الوصول إلى البيانات، تصعيد الامتياز، التهرب من السياسة؟

هذان الشيئان مختلفان. يمكن أن يكون الاكتشاف فجوة رؤية حرجة (مراقبتك عمياء) دون أن يكون تصعيد امتياز عملي (المهاجم يحتاج بالفعل إلى الجذر). على العكس، يمكن أن يكون الاكتشاف مسار تصعيد مباشر بمتطلبات مسبقة ضئيلة.

الاكتشاف	فجوة الرؤية	التصعيد العملي
LID-001	حرجة — AppArmor لا يرى شيئًا، سجل التدقيق فارغ، لا أثر طب شرعي صفري	محدودة — يتطلب الجذر أو CAP_BPF+CAP_PERFMON (مميز بالفعل). ليس تصعيد امتياز. التأثير: التهرب من السياسة + العمى التدقيقي.
LID-002	عالية — security_file_receive() لا يُطلق أبدًا، نقل واصف الملف غير مرئي لجميع LSMs	عالية — يعمل من مساحة مستخدم غير مميزة عبر io_uring. يعبر حدود إنفاذ LSM دون أي امتياز.
LID-003	عالية — تجاوز security_sb_mount()، سياسة تثبيت AppArmor هي كود ميت	متوسطة — يتطلب الوصول إلى مساحة اسم التثبيت (CAP_SYS_ADMIN في مساحة اسم المستخدم). متاح في العديد من تكوينات الحاويات.
LID-004	حرجة — AppArmor لا يرى شيئًا، لا خطافات BPF (0/9)، لا أثر تدقيق لأي عملية رمز BPF	متوسطة — يتطلب تفويض bpffs من المضيف + CAP_BPF في مساحة اسم المستخدم. متاح في بيئات تشغيل الحاويات مع تفويض BPF (LXD/Incus).
LID-005	متوسطة — مصنفات tc الصادرة على واجهة الحاوية لا تقيم أبدًا حركة مرور AF_XDP	محدودة — يتجاوز tc الصادر على eth0 للحاوية (تم التحقق). لم يتم تجاوز Cilium — يفرض على واجهة veth الجانبية للمضيف + التحقق من IP المصدر (تم اختباره). التأثير محدود لإعدادات Docker العادية مع تصفية tc الصادرة فقط.

مصفوفة قابلية التكرار

كل اكتشاف له متطلبات محددة من النواة/التكوين/الامتياز. إذا كانت بيئتك لا تتطابق، فلن يتكرر الاكتشاف.

LID-001: إعادة كتابة اسم مسار eBPF

الشرط	مطلوب	ملاحظات
إصدار النواة	5.x+	تم اختباره على 5.15، 6.1، 6.6، 6.8
CONFIG_BPF_SYSCALL	=y	افتراضي في جميع التوزيعات الرئيسية
CONFIG_BPF_KPROBE_OVERRIDE	=y	أوبونتو/ديبيان يفعلانه، 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 يعتمد على inode وليس على اسم المسار

LID-002: io_uring MSG_RING

الشرط	مطلوب	ملاحظات
إصدار النواة	6.0+	IORING_MSG_SEND_FD أُضيف في 6.0
CONFIG_IO_URING	=y	افتراضي في جميع التوزيعات الرئيسية
الامتيازات	لا شيء	يعمل من مساحة مستخدم غير مميزة
sysctl io_uring_disabled	0 (الافتراضي)	2 يمنع غير المميزين، 1 يمنع الجميع
LSM المستهدف	أي (SELinux، AppArmor، Smack)	security_file_receive() هو خطاف LSM عام
kernel.lockdown	غير ذي صلة	لا يشمل BPF

LID-004: عمى AppArmor لرمز BPF

الشرط	مطلوب	ملاحظات
إصدار النواة	6.9+	رمز BPF أُدخل في 6.9
CONFIG_BPF_SYSCALL	=y	افتراضي في جميع التوزيعات الرئيسية
CONFIG_SECURITY_APPARMOR	=y	افتراضي أوبونتو/ديبيان
bpffs مع التفويض	نعم	يجب على المضيف تثبيته مع خيارات delegate_*
الامتيازات	CAP_BPF في مساحة اسم المستخدم	متاح بسهولة لجذر userns
SELinux بدلاً من AppArmor	غير متأثر	SELinux ينفذ جميع خطافات BPF التسعة

LID-003: واجهة برمجة التطبيقات للتثبيت الجديدة

الشرط	مطلوب	ملاحظات
إصدار النواة	5.2+	fsopen/fsmount أُدخلا في 5.2
CONFIG_SECURITY_APPARMOR	=y	فقط AppArmor متأثر
الامتيازات	CAP_SYS_ADMIN في مساحة اسم المستخدم	متاح مع unshare -m
SELinux بدلاً من AppArmor	لا يعمل	SELinux ينفذ security_sb_kern_mount()
بيئة تشغيل الحاوية	يعتمد على مرشح seccomp	fsopen يمنعه seccomp الافتراضي لـ Docker — قد لا يمنعه 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

مرجع سريع: ما يمنع كل اكتشاف

البيئة	LID-001	LID-002	LID-003	LID-004	LID-005
أوبونتو 22.04+ (AppArmor، افتراضي)	يعمل	يعمل	يعمل	يعمل (6.9+)	يعمل
ديبيان 12+ (AppArmor)	يعمل	يعمل	يعمل	يعمل (6.9+)	يعمل
RHEL/Fedora (SELinux)	لا	يعمل	لا	لا	يعمل
lockdown=confidentiality	لا	يعمل	يعمل	جزئيًا	يعمل
مستخدم غير مميز	لا	يعمل	يعتمد على userns	يعتمد على تفويض bpffs	لا
حاوية (بدون CAP_BPF)	لا	يعتمد على io_uring	يعتمد على seccomp	لا	يعمل
حاوية (تم إسقاط CAP_NET_RAW)	لا	يعتمد	يعتمد	لا	لا

الاكتشافات