بسم الله الرحمن الرحيم
الحمد لله رب العالمين، وصلى الله وسلم وبارك على عبده ورسوله نبينا محمد وعلى آله وصحبه أجمعين
السلام عليكم ورحمة الله وبركاته
تعرف على نوع الحماية و ما هو SELinux شرح شامل و مفصّل
SELinux (Security-Enhanced Linux)
هو إطار أمان قوي لـلّينُكس يوفّر تحكّم وصول إجباري (Mandatory Access Control — MAC) متقدّمًا فوق نظام الصلاحيات التقليدي (DAC). طوّرته وكالة الأمن القومي الأمريكية (NSA) بالمشاركة مع مجتمع لينكس، وهدفه الأساسي هو تقليل مساحة الهجوم (attack surface) ومنع البرامج حتى لو استغلت وثغّرت من التجوّل أو التسبب بضرر خارج نطاق ما تسمح به السياسة الأمنية.
1. لماذا SELinux مهم؟
يمنع البرامج المخترَقة من تنفيذ أمور غير مصرح بها حتى لو كانت تعمل بصلاحية root.
يحدّ من إمكانية الاستغلالات بالجذر (privilege escalation).
يوفّر تحكّمًا دقيقًا للغاية في ما يمكن لكل برنامج/عملية/مستخدم الوصول إليه من موارد النظام (ملفات، منافذ، قدرات).
يستخدم في توزيعات سيرفرية مهمة (Fedora, RHEL, CentOS، إلخ) لضمان مستوى عالٍ من الأمان.
2. الفرق بين DAC و MAC (لماذا SELinux مختلف)
DAC (Discretionary Access Control):
تحكم تقليدي قائم على مالك الملف وصلاحياته (owner/group/others). يمكن للمستخدمين تغيير الصلاحيات بحرية.
MAC (Mandatory Access Control):
سياسات أمنية مركزية تفرض قواعد لا يمكن للمستخدمين تجاوزها حتى لو كانوا أصحاب الملفات. SELinux هو نظام MAC.
3. مكونات معماريّة SELinux (بشكل مبسّط)
1. نواة لينكس (Kernel) مع دعم SELinux: تطبّق قواعد السياسة داخل النواة عند كل محاولة للوصول.
2. السياسة (Policy): مجموعة القواعد التي تحدد من يمكنه فعل ماذا. السياسات تأتي في صيغ متعددة (targeted, strict, mls...).
3. ملفات التوصيف والسياق (Contexts / Labels): كل كائن (ملف، عملية، منفذ، جهاز، إلخ) يحصل على تسميات (labels/contexts).
4. أدوات المستخدم (Userspace tools): أدوات لإدارة الحالة، تعديل السياسات، والتحقيق في الإنذارات (مثال: `sestatus`, `setenforce`, `semanage`, `restorecon`, `audit2allow`).
5. سجل الأحداث (Audit log): حيث تُسجَّل محاولات الوصول المرفوضة عادة في `/var/log/audit/audit.log` أو في `journalctl`.
4. صيغة السياق (SELinux context)
السِياق الشائع يظهر على شكل أربع حقول مفصولة بنقطتين:
```
user:role:type:level
```
user:
حساب SELinux (ليس حساب UNIX بالضرورة).
role:
دور (role) مثل `system_r`، ويحدد أي types يمكن للمستخدم العمل معها.
type
(أهم حقل في سياسة الـ Targeted): يعرّف تصنيفًا (مثلاً `httpd_t`, `ssh_t`, `etc_t`) ويُستخدم في معظم القواعد.
level:
يستخدم في سياسات متقدمة متعددة المستويات (MLS/MCS) ويظهر كـ `s0` أو `s0:c0.c1023`، إلخ.
أمثلة:
```
-rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html
system_u:system_r:httpd_t:s0 /usr/sbin/httpd
5. أوضاع تشغيل SELinux
Enforcing:
تُطبق السياسات عمليًا وتُرفَع الأخطاء في السجلات عند أي محاولة مرفوضة.
Permissive:
لا يتم منع الوصول، لكن تُسجَّل المخالفات (مفيد لتطوير السياسات).
Disabled:
معطّل تمامًا (غير مستحسن في بيئات الإنتاج).
التحقق من الحالة:
```
sestatus
أو
getenforce
لتغيير مؤقت:
sudo setenforce 0 وضع permissive
sudo setenforce 1 وضع enforcing
```ملاحظة: تغيير `setenforce` مؤقت (يُفقد بعد إعادة التشغيل)؛ لتغييره دائميًا عدِّل `/etc/selinux/config`.
6. أنواع السياسات الشائعة
Targeted Policy:
الأكثر انتشارًا؛ يحمي خدمات محدَّدة (مثل httpd, sshd) عبر تحديد أنماط (`types`) لهذه الخدمات.
العمليات غير المستهدفة تعمل بحرية DAC.
MLS / MCS:
سياسات متقدمة لدعم العزل متعدد المستويات/المجموعات (مستخدم في بيئات حساسة للغاية أو containerns مع متطلبات فصل صارمة).
Strict Policy:
سياسة أكثر شمولًا قد تفرض قواعد على كل شيء إعدادها أصعب وأصعب في الإدارة.
7. كيفية قراءة وإنشاء قواعد وسجلات الرفض
سجلات الرفض تظهر عادة في `/var/log/audit/audit.log` أو عبر `ausearch`، ويمكن تحويلها إلى قواعد مبدئية مع `audit2allow`.
أمثلة عملية:
```
عرض السجلات المتعلقة بعملية محددة
ausearch -c 'httpd' --raw
استخراج رسائل الرفض الأخيرة
ausearch -m AVC,USER_AVC -ts recent
تحويل سجل رفض إلى قاعدة مؤقتة (عرض)
ausearch -m AVC -ts today | audit2allow -m mypol
```
لإنشاء وحدة سياسة (module) من سجلات الرفض:
```
إنشاء ملف .te (type enforcement)
ausearch -m AVC -ts today | audit2allow -M my_apache_fix
تثبيت الوحدة
sudo semodule -i my_apache_fix.pp
```
تحذير: لا تقبل كل قواعد `audit2allow` تلقائيًا في بيئات الإنتاج بدون مراجعة — قد تمنح صلاحيات زائدة.
8. أدوات إدارة SELinux شائعة ومعانيها
`sestatus` — يعرض حالة SELinux.
`getenforce` / `setenforce` — قراءة/تغيير الوضع.
`semanage` — إدارة السياسات (إدارة السياقات الثابتة، المنافذ، booleans، إلخ).
مثال: `semanage port -l` لعرض المنافذ المعروفة، semanage fcontext -a -t httpd_sys_content_t "/web(/.)?"` لإضافة تعيين سياق.
`restorecon` — يعيد تعيين سياق ملف إلى ما هو معرف في السياسة.
مثال: `sudo restorecon -Rv /var/www/html`
`chcon` — يغيّر السياق مؤقتًا لملف (لا يستمر عبر restorecon أو إعادة التشغيل ما لم تُستخدم semanage).
مثال: `sudo chcon -t httpd_sys_content_t /my/file`
`sealert` / `setroubleshoot` — أدوات رسومية/نصية لتفسير رسائل AVC (قد لا تكون مثبتة افتراضيًا).
`semodule` — إدارة وحدات السياسات المحزّمة (`.pp`).
`audit2allow` — تحويل سجلات الرفض إلى قواعد مقترحة.
9. مثال عملي: ملف ويب لا يعرض بسبب SELinux
المشكلة: بعد نسخ ملفات الموقع إلى `/var/www/html/myapp`, صفحة الويب تعطي 403.
التحقيق:
```
تحقق من سياقات الملفات
ls -Z /var/www/html/myapp
أعد تعيين السياق حسب سياسة الويب
sudo restorecon -Rv /var/www/html/myapp
```
إذا كان هناك رفض في السجلات:
```
ausearch -m AVC -ts today | audit2allow -m webfix
```
راجع ما يقترح `audit2allow` قبل تطبيقه. لإنشاء وتثبيت وحدة:
```
ausearch -m AVC -ts today | audit2allow -M webfix
sudo semodule -i webfix.pp
```
10. SELinux Booleans (مفاتيح تشغيل/إيقاف وظائف محددة)
تسمح Booleans بتشغيل/إيقاف سلوكيات محددة دون إعادة بناء السياسة كاملة. أمثلة:
`httpd_can_network_connect` — يسمح لـ httpd بالاتصال بالشبكة.
`httpd_enable_homedirs` — يسمح لخادم الويب بخدمة ملفات من مجلدات المستخدمين.
عرض القيم:
```
getsebool -a | grep httpd
لتغيير قيمة:
sudo setsebool -P httpd_can_network_connect on
-P لجعلها دائمة عبر إعادة التشغيل
```
11. نصائح وأفضل ممارسات
1. ابدأ بوضع Permissive عند تطوير السياسة ثم انتقل لـ Enforcing عندما تتأكد. سجّل كل الرفض وراجع.
2. راجع كل قواعد audit2allow يدويًا؛ لا تُدرج أي قاعدة دون فهم ما تمنح.
3. استخدم semanage fcontext + restorecon لتعيين سياقات صحيحة للملفات بدلاً من chcon المؤقت.
4. سجّل وراقب سجلات AVC بانتظام — هي مصدر مهم لفهم محاولات الوصول المرفوضة.
5. اعتمد Booleans بدل تغيير السياسات حينما يكون الخيار مناسبًا.
6. وثّق التغييرات (modules التي ثبّتها، booleans التي عدّلتها).
7. اختبر في بيئة staging قبل تطبيق السياسات في الإنتاج.
12. مقارنة سريعة بين SELinux و AppArmor
المنهج: SELinux يعتمد على التسميات labels وسياسات متعرّفة بشكل مركزي، بينما AppArmor يعتمد غالبًا على المسارات path-based.
القوة والدقة: SELinux قادر على فرض سياسات أكثر تفصيلاً وتعقيدًا (مثلاً MLS)، لكنه أصعب في التعلم والإدارة.
سهولة الاستخدام: AppArmor أسهل في الإعداد والبروفايلات غالبًا أبسط.
الانتشار: توزيعات مثل RHEL/Fedora/CentOS تفضّل SELinux
اما Ubuntu وDebian تقترن أكثر بـ AppArmor
(لكن Debian يمكن تفعيل SELinux).
13. موارد عملية (أوامر مرجعية)
```
الحالة
sestatus
getenforce
السجلات
ausearch -m AVC -ts today
ausearch -c httpd
تحويل سجلات إلى سياسة (راجع دائماً)
ausearch -m AVC -ts today | audit2allow -M mymod
sudo semodule -i mymod.pp
إدارة السياقات الدائمة
semanage fcontext -a -t httpd_sys_content_t "/srv/myapp(/.)?"
restorecon -Rv /srv/myapp
Booleans
getsebool -a | grep httpd
sudo setsebool -P httpd_can_network_connect on
```
SELinux
هو نظام أمان قوي وفعال يرفع مستوى الحماية على أنظمة لينكس عبر فرض سياسات دقيقة لا يمكن للمستخدمين تجاوزها بسهولة. وهو ملائم جدًا للخوادم والبيئات التي تتطلّب عزلاً صارمًا بين الخدمات والمستخدمين. لكن قوّته تأتي مع تعقيد إداري — لذلك من الأفضل تعلم أدواته وفهم سجلاته، والاعتماد على وضع `Permissive` للتحقيق ثم التدرج إلى `Enforcing` بعد التأكد.
هل يمكن تثبيت SELinux و AppArmor معا
نعم يمكن وجود SELinux و AppArmor معًا على نفس نظام لينكس، لكن لا يمكن استخدامهما فعليًا في نفس الوقت على نفس العمليات.
بمعنى آخر:
✔ يمكن تثبيت SELinux و AppArmor معًا بدون مشاكل.
✘ لكن لا يمكن تفعيلهما معًا كأنظمة MAC تعمل بالتوازي.
✔ النظام يسمح بوجودهما، لكن النواة Linux kernel لا تدعم تطبيق سياستين MAC (Mandatory Access Control) معًا في الوقت نفسه.
📌 شرح مبسّط
يوجد في النواة طبقة واحدة فقط مخصّصة لأنظمة التحكم الإجباري MAC.
هذه الطبقة تستطيع تحميل نظام واحد فقط مثل:
اما SELinux أو AppArmor
أو Smack
أو TOMOYO
إذا حاولت تفعيل نظامين معًا، سيأخذ واحد فقط الأولوية (غالبًا SELinux لأنه يحمّل مبكرًا).
📌 ما الذي يحدث عندما تثبّتهما معًا؟
1. في Debian و Ubuntu
يمكن تثبيت SELinux والحزمة الخاصة به.
ولكن AppArmor هو المفعّل افتراضيًا.
إذا فعّلت SELinux، سيقوم النظام تلقائيًا بـ تعطيل AppArmor عند الإقلاع، أو تفشل سياسات AppArmor في التحميل.
2. في Fedora / RHEL / CentOS مفعّل SELinux افتراضيًا
إذا حاولت تثبيت AppArmor، لن يعمل لأنه يتعارض مع SELinux (الذي يحمّل أولًا في النواة).
📌 لماذا لا يمكن تشغيلهما معًا؟
لأن كل نظام MAC يحاول:
اعتراض نفس syscalls
تعليم (labeling) نفس الملفات
التحكم بنفس العمليات
تنفيذ سياسات أمنية مختلفة
وهذا يسبب تعارضًا مباشرًا، لذلك النواة تمنع التشغيل المزدوج.
📌 ماذا يمكن فعله؟
يمكنك:
✔ تثبيت النظامين
✘ لكن يجب اختيار واحد فقط لتفعيله
أما الاثنين معًا — فهذا غير ممكن وظيفيًا.
📌 كيف أعرف أيهما يعمل الآن؟
للتحقق من SELinux:
```
sestatus
getenforce
```
للتحقق من AppArmor:
```
sudo aa-status
```
إذا كان SELinux في وضع `Enforcing`، فعادةً AppArmor سيكون معطلاً.
📌 أي النظامين أنصحك باستخدامه؟
يعتمد على نوع توزيعتك وخدمتك:
✔ Ubuntu/Debian AppArmor أسهل ويدعم snap SELinux يحتاج إعداد طويل
✔ Fedora/RHEL/Rocky/AlmaLinux SELinux هو النظام الرسمي والأقوى AppArmor غير منصوح به هنا
المشاركات
ليست هناك تعليقات:
إرسال تعليق
(( مَا يَلْفِظُ مِنْ قَوْلٍ إِلَّا لَدَيْهِ رَقِيبٌ عَتِيدٌ))