التحكم في الوصول الإلزامي (MAC) باستخدام SELinux أو AppArmor

يُعد التحكم في الوصول الإلزامي أو Mandatory Access Control (MAC) من أهم طبقات الحماية المتقدمة في لينكس، لأنه يضيف مستوى صارماً من الضبط فوق صلاحيات الملفات التقليدية. فإذا كنت قد اطلعت سابقاً على إدارة الصلاحيات والملكية (Chmod, Chown, Sudo) فستعرف أن نموذج الصلاحيات المعتاد يعتمد على المالك والمجموعة والآخرين، لكنه لا يكفي وحده في البيئات الحساسة أو الخوادم المعرضة للإنترنت.

هنا يأتي دور أدوات مثل SELinux وAppArmor، حيث تفرض سياسات أمنية تحدد بدقة ما الذي يمكن للتطبيقات والخدمات الوصول إليه، حتى لو كانت تعمل بصلاحيات مرتفعة. هذه المقاربة تقلل كثيراً من أثر الاختراقات، وتمنع البرنامج المخترق من التحرك بحرية داخل النظام.

ما هو MAC ولماذا يختلف عن DAC؟

في لينكس التقليدي، يعتمد النظام غالباً على Discretionary Access Control (DAC)، أي أن مالك الملف أو المدير يستطيع منح أو سحب الأذونات. هذا النموذج مرن ومفيد، لكنه يفترض أن البرامج والمستخدمين المصرح لهم لن يتصرفوا بشكل ضار أو غير متوقع.

أما في نموذج MAC، فالقواعد الأمنية تُفرض مركزياً بواسطة النظام نفسه، وليس فقط من خلال مالك الملف. بمعنى آخر، قد يكون لدى الخدمة صلاحية قراءة ملف وفق أذونات chmod، لكن سياسة MAC قد تمنعها من ذلك إن لم يكن هذا السلوك مصرحاً ضمن السياسة الأمنية.

• DAC يركز على ملكية الملفات والأذونات التقليدية.
• MAC يركز على السياسات الملزمة التي لا يمكن للتطبيق تجاوزها بسهولة.
• MAC يقلل من خطر التصعيد الجانبي بعد اختراق خدمة واحدة.

SELinux وAppArmor: الفكرة العامة

كل من SELinux وAppArmor يهدفان إلى احتواء التطبيقات ومنعها من الوصول غير المصرح به إلى الملفات، الشبكة، العمليات، أو الموارد الحساسة. لكن الفرق الأساسي بينهما يظهر في طريقة بناء السياسات وإدارتها.

SELinux

Security-Enhanced Linux هو نظام أمني متقدم يعتمد على مفهوم Security Contexts والتصنيف الدقيق للكائنات والعمليات. يستخدم كثيراً في توزيعات مثل RHEL وCentOS وFedora وAlmaLinux وRocky Linux.

في SELinux، لا يكفي أن يكون الملف موجوداً في المسار الصحيح، بل يجب أيضاً أن يحمل السياق الأمني المناسب. لهذا السبب، فإن فهم هيكلية ملفات لينكس (Filesystem Hierarchy Standard – FHS) مهم جداً عند تشخيص المشاكل المرتبطة بمواضع الملفات والخدمات.

AppArmor

يُعد AppArmor أبسط نسبياً من SELinux من حيث المفهوم والإدارة. يعتمد على ملفات تعريف Profiles مرتبطة بمسارات البرامج، وهو شائع في توزيعات مثل Ubuntu وDebian وبعض مشتقاتها.

يُفضل كثير من المسؤولين AppArmor لأنه أسهل في التعلم والتخصيص، خصوصاً في البيئات التي تحتاج إلى تفعيل حماية جيدة بسرعة دون تعقيد كبير في السياسات.

متى تحتاج إلى SELinux أو AppArmor؟

ليست كل الأنظمة تحتاج إلى سياسات صارمة من اليوم الأول، لكن الاعتماد على MAC يصبح مهماً جداً في الحالات التالية:

• تشغيل خوادم ويب أو قواعد بيانات متصلة بالإنترنت.
• استضافة عدة خدمات على نفس النظام.
• العمل في بيئات تنظيمية أو مؤسسية تتطلب امتثالاً أمنياً.
• تشغيل تطبيقات طرف ثالث لا تثق بها بالكامل.
• تقليل أثر الثغرات البرمجية عند اختراق خدمة ما.

كما أن MAC يكمل طبقات حماية أخرى مثل جدار الحماية (Firewall) وتأمين النظام (UFW, Firewalld, Iptables)، ولا يُفترض أن يحل محلها. الحماية الفعالة في لينكس تأتي دائماً من الجمع بين أكثر من آلية دفاعية.

التحقق من حالة SELinux وAppArmor

قبل تعديل أي سياسة، ابدأ أولاً بفحص ما إذا كانت الأداة مفعلة على النظام. هذه الخطوة أساسية في التشخيص، خاصة إذا كنت تتتبع سبب فشل خدمة ما في الوصول إلى ملف أو منفذ.

فحص SELinux

getenforce
sestatus

ستظهر عادة إحدى الحالات التالية:

• Enforcing: السياسات مطبقة فعلياً.
• Permissive: تُسجل الانتهاكات دون منعها.
• Disabled: SELinux غير نشط.

فحص AppArmor

aa-status

إذا كنت تدير الخدمات يومياً، فستحتاج أيضاً إلى فهم إدارة الخدمات باستخدام (systemd) و (systemctl) لأن كثيراً من تغييرات السياسات تترافق مع إعادة تشغيل الخدمة أو إعادة تحميلها.

أوضاع التشغيل وأفضل استخدام لها

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

الأفضل هو استخدام وضع المراقبة أولاً لتجميع السجلات وفهم المنع الذي يحدث. ثم تُعدّل السياسة بطريقة صحيحة قبل العودة إلى التطبيق الكامل.

تعطيل SELinux أو AppArmor بشكل دائم يجب أن يكون آخر حل ممكن، وليس أول خطوة عند استكشاف الأخطاء.

مثال عملي مع SELinux

لنفترض أنك نقلت ملفات موقع ويب إلى مسار مخصص، ثم لاحظت أن خادم الويب لا يستطيع قراءتها. غالباً المشكلة ليست في أذونات chmod وحدها، بل في Security Context غير مناسب.

يمكنك فحص السياقات الحالية باستخدام أوامر عرض الملفات، وهي مهارة ترتبط أيضاً بموضوع أدوات عرض ومعالجة النصوص (cat, nano, vim, less, tail) عند مراجعة الملفات والسجلات.

ls -Z /var/www/html
ps -eZ | grep httpd

إذا كانت الملفات لا تحمل النوع المناسب لخادم الويب، يمكن تصحيح التسمية المؤقتة أو الدائمة وفق السياسة. مثال شائع:

sudo restorecon -Rv /var/www/html

وفي حال استخدام مسار جديد خارج المسار المعتاد، قد تحتاج إلى تعريف سياق دائم له:

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/mywebsite(/.*)?"
sudo restorecon -Rv /srv/mywebsite

بهذا الشكل، يصبح الوصول مسموحاً وفق منطق SELinux بدلاً من الالتفاف على السياسة.

مثال عملي مع AppArmor

في AppArmor، ترتبط الحماية بملف تعريف خاص بالبرنامج. إذا كان التطبيق يحتاج إلى قراءة مجلد جديد أو كتابة ملفات في مسار مخصص، فيجب تعديل الـ profile الخاص به.

يمكن معرفة حالة الملفات الشخصية المحملة والأوضاع الحالية عبر:

sudo aa-status

وللدخول في نمط التعلم أو المساعدة على بناء القواعد:

sudo aa-complain /usr/sbin/nginx
sudo aa-logprof

الأمر aa-logprof يساعدك على تحليل السجلات واقتراح قواعد مناسبة بناءً على محاولات الوصول المرفوضة. بعد ذلك يمكنك إعادة التطبيق الصارم:

sudo aa-enforce /usr/sbin/nginx

تشخيص مشاكل المنع وقراءة السجلات

نجاح العمل مع MAC يعتمد كثيراً على مهارات تحليل السجلات. فبدلاً من التخمين، يجب مراجعة الرسائل الأمنية لتحديد الملف أو العملية أو السلوك الذي تم منعه.

هذا يرتبط مباشرة بموضوع مراقبة السجلات (Logs) وتحليل الأخطاء (journalctl, /var/log)، لأن كثيراً من مشاكل SELinux وAppArmor لا تظهر بوضوح للمستخدم النهائي، بينما تكون التفاصيل الدقيقة مسجلة في النظام.

sudo journalctl -xe
sudo ausearch -m avc -ts recent

في بيئات SELinux، رسائل AVC تعتبر مؤشراً مهماً على سبب الرفض. أما في AppArmor فتظهر الانتهاكات عادة في سجلات النواة أو عبر journalctl.

أفضل الممارسات عند تطبيق MAC

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

أكثر الأخطاء شيوعاً هو منح الخدمة أذونات ملفات واسعة جداً بينما المشكلة الحقيقية تكون في سياسة SELinux أو AppArmor، وليس في نظام الأذونات التقليدي.

أيّهما تختار: SELinux أم AppArmor؟

لا توجد إجابة واحدة تناسب الجميع. إذا كنت تعمل على توزيعات Red Hat وتحتاج إلى سياسات دقيقة جداً وقابلة للتوسع في البيئات المؤسسية، فغالباً سيكون SELinux هو الخيار الأنسب. أما إذا كنت تريد حلاً أسهل في التعلم والإدارة على Ubuntu أو Debian، فغالباً سيكون AppArmor أكثر عملية.

• SELinux: أقوى من حيث العمق والمرونة، لكنه أكثر تعقيداً.
• AppArmor: أبسط في الإدارة، وسريع التبني، وفعال في كثير من السيناريوهات.

خاتمة

التحكم في الوصول الإلزامي ليس مجرد إعداد إضافي في لينكس، بل هو طبقة أمنية استراتيجية تحد من الأضرار حتى عند نجاح الهجوم الأولي. فبدلاً من الاعتماد الكامل على الصلاحيات التقليدية، يفرض SELinux وAppArmor حدوداً دقيقة على سلوك التطبيقات والخدمات.

عند فهم الفكرة الأساسية، ومراجعة السجلات، وتعديل السياسات بشكل منهجي، ستتمكن من بناء خوادم أكثر صلابة وموثوقية. والأهم أن تتعامل مع MAC كجزء من منظومة حماية متكاملة تشمل إدارة الصلاحيات، الجدار الناري، مراقبة السجلات، وإدارة الخدمات بشكل احترافي.