SELinux

نظام لينكس المحسن أمنياً ( SELinux ) هو وحدة أمان لنواة لينكس توفر آلية لدعم سياسات أمان التحكم في الوصول ، بما في ذلك عناصر التحكم الإلزامية في الوصول (MAC).

SELinux عبارة عن مجموعة من تعديلات نواة النظام وأدوات مساحة المستخدم التي أُضيفت إلى توزيعات لينكس المختلفة . تسعى بنيتها إلى فصل تطبيق قرارات الأمان عن سياسة الأمان، وتبسيط كمية البرامج المستخدمة في تطبيق سياسة الأمان. ^{[ 3 ] [ 4 ]} يمكن تتبع المفاهيم الأساسية التي يقوم عليها SELinux إلى العديد من المشاريع السابقة لوكالة الأمن القومي الأمريكية (NSA).

يصف فريق الأمن المحسن لنظام لينكس التابع لوكالة الأمن القومي الأمريكية نظام لينكس المحسن للأمن التابع لوكالة الأمن القومي بأنه ^{[ 5 ]}

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

تُطبّق نواة لينكس المُدمجة مع SELinux سياسات تحكم إلزامية في الوصول، تُقيّد برامج المستخدم وخدمات النظام، بالإضافة إلى الوصول إلى الملفات وموارد الشبكة. ويُقلّل تقييد الامتيازات إلى الحد الأدنى اللازم للعمل من قدرة هذه البرامج والخدمات على إحداث ضرر في حال وجود خلل أو اختراق (على سبيل المثال، عبر تجاوزات سعة المخزن المؤقت أو سوء التكوين). تعمل آلية التقييد هذه بشكل مستقل عن آليات التحكم التقليدية في الوصول في لينكس ( الاختيارية ). فهي لا تتضمن مفهوم " المستخدم الجذر" (root) ، ولا تُعاني من أوجه القصور المعروفة في آليات أمان لينكس التقليدية، مثل الاعتماد على ملفات setuid / setgid الثنائية.

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

من منظورٍ مثالي، يوفر SELinux مزيجًا من المفاهيم والقدرات المستمدة من ضوابط الوصول الإلزامية، وضوابط سلامة البيانات الإلزامية ، والتحكم في الوصول القائم على الأدوار (RBAC)، وهندسة فرض النوع . وتتيح أدوات الطرف الثالث إمكانية بناء مجموعة متنوعة من سياسات الأمان.

يمكن أن يُعزى العمل الأول الموجه نحو توحيد نهج يوفر ضوابط الوصول الإلزامية والاختيارية (MAC وDAC) ضمن بيئة حوسبة UNIX (بشكل أدق، POSIX) إلى مجموعة عمل TRUSIX التابعة لوكالة الأمن القومي ، والتي اجتمعت من عام 1987 إلى عام 1991 ونشرت كتاب Rainbow Book واحد (#020A)، وأنتجت نموذجًا رسميًا ونموذجًا أوليًا لأدلة التقييم المرتبطة به (#020B) والذي لم يُنشر في النهاية.

صُمم SELinux لإظهار أهمية ضوابط الوصول الإلزامية لمجتمع لينكس، وكيفية إضافة هذه الضوابط إلى لينكس. في البداية، كان لا بد من تطبيق التصحيحات التي تُشكل SELinux بشكل صريح على مصدر نواة لينكس؛ ثم دُمج SELinux في نواة لينكس الرئيسية في سلسلة 2.6 من نواة لينكس.

أصدرت وكالة الأمن القومي الأمريكية (NSA)، المطور الرئيسي الأصلي لنظام SELinux، النسخة الأولى منه لمجتمع تطوير البرمجيات مفتوحة المصدر بموجب رخصة جنو العمومية (GPL) في 22 ديسمبر 2000. ^{[ 6 ]} دُمج البرنامج في نواة لينكس الرئيسية 2.6.0-test3، التي صدرت في 8 أغسطس 2003. ومن بين المساهمين البارزين الآخرين: ريد هات ، ونتورك أسوشيتس ، وسكيور كومبيوتينغ كوربوريشن ، وتريسيس تكنولوجي، وترستد كمبيوتر سوليوشنز. أُتيحت نسخ تجريبية من تطبيق FLASK /TE عبر مشروع TrustedBSD لأنظمة التشغيل FreeBSD وداروين .

يُطبّق نظام لينكس المُعزّز أمنيًا نواة الأمان المتقدمة من فلوكس (FLASK) ^{[ 7 ]} . تحتوي هذه النواة على مكونات معمارية تمّ تصميمها في نظام تشغيل فلوك ^{[ 8 ]} . تُوفّر هذه المكونات دعمًا عامًا لفرض أنواع عديدة من سياسات التحكم الإلزامي في الوصول ^{[ 9 ]} ، بما في ذلك تلك القائمة على مفاهيم فرض النوع ، والتحكم في الوصول القائم على الأدوار ، والأمان متعدد المستويات . وقد بُنيت FLASK بدورها على DTOS، وهو نظام تشغيل موزع موثوق به مُشتق من ماخ، طُوّر كجزء من بحث سابق في أنظمة التحكم الإلزامي في الوصول ^{[ 10 ]} .

لا يشترط أن يكون مستخدمو وأدوار SELinux مرتبطين بمستخدمي وأدوار النظام الفعلية. يُعيّن SELinux لكل مستخدم أو عملية حالية سياقًا ثلاثيًا يتكون من اسم المستخدم والدور والنطاق (أو النوع). يتميز هذا النظام بمرونة أكبر من المعتاد: فكقاعدة عامة، يشترك معظم المستخدمين الفعليين في نفس اسم مستخدم SELinux، وتُدار جميع عمليات التحكم في الوصول من خلال الوسم الثالث، وهو النطاق. يجب تحديد الظروف التي يُسمح بموجبها لعملية ما بالدخول إلى نطاق معين في السياسات. runconيسمح الأمر بتشغيل عملية في سياق محدد صراحةً (المستخدم، والدور، والنطاق)، ولكن قد يرفض SELinux هذا الانتقال إذا لم تتم الموافقة عليه من قِبل السياسة.

تحتوي الملفات ومنافذ الشبكة وغيرها من مكونات الأجهزة على سياق SELinux، يتألف من اسم ودور (نادرًا ما يُستخدم) ونوع. في حالة أنظمة الملفات، يُطلق على الربط بين الملفات وسياقات الأمان اسم "التصنيف". يُحدد التصنيف في ملفات السياسات، ولكن يمكن تعديله يدويًا دون تغيير السياسات. أنواع الأجهزة مفصلة للغاية، على سبيل المثال، bin_t(جميع الملفات في المجلد /bin) أو postgresql_port_t(منفذ PostgreSQL، 5432). يمكن تحديد سياق SELinux لنظام ملفات بعيد بشكل صريح عند عملية التحميل.

يضيف SELinux -Zمفتاح التبديل إلى أوامر shell ls، psوبعض الأوامر الأخرى، مما يسمح برؤية سياق الأمان للملفات أو العملية.

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

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

تشمل ميزات SELinux ما يلي:

• الفصل التام بين السياسة والتنفيذ
• واجهات سياسات محددة جيدًا
• دعم التطبيقات التي تستعلم عن السياسة وتفرض التحكم في الوصول (على سبيل المثال، تشغيل مهام crond في السياق الصحيح)
• استقلالية السياسات المحددة ولغة السياسات
• استقلالية تنسيقات ومحتويات ملصقات الأمان المحددة
• تسميات وعناصر تحكم فردية لكائنات وخدمات النواة
• دعم تغييرات السياسات
• تدابير منفصلة لحماية سلامة النظام (نوع المجال) وسرية البيانات ( الأمان متعدد المستويات )
• سياسة مرنة
• التحكم في تهيئة العمليات وتوريثها، وتنفيذ البرنامج
• التحكم في أنظمة الملفات، والمجلدات، والملفات، ومُعرّفات الملفات المفتوحة
• التحكم في المقابس والرسائل وواجهات الشبكة
• ضوابط استخدام "القدرات"
• معلومات مخزنة مؤقتًا حول قرارات الوصول عبر ذاكرة التخزين المؤقت لمتجه الوصول (AVC) ^{[ 12 ]}
• سياسة الرفض الافتراضية (أي شيء غير محدد صراحة في السياسة غير مسموح به) ^{[ 13 ] [ 14 ] [ 15 ]}

تم تطبيق SELinux في نظام Android منذ الإصدار 4.3. ^{[ 16 ]}

من بين توزيعات لينكس المجانية المدعومة من المجتمع، كانت فيدورا من أوائل من تبنوا SELinux، حيث دعمته افتراضيًا منذ فيدورا كور 2. وتشمل التوزيعات الأخرى التي تدعمه ديبيان بدءًا من الإصدار 9 ستريتش ^{[ 17 ]} وأوبونتو بدءًا من الإصدار 8.04 هاردي هيرون [18]. واعتبارًا ^{من الإصدار 11.1} ، يتضمن أوبن سوزي تفعيلًا أساسيًا لـ SELinux ^{[ 19 ]} . ويُقدم سوزي لينكس إنتربرايز (SLE) 11 ميزة SELinux كمعاينة تقنية ^{[ 20 ] .}

يحظى SELinux بشعبية في الأنظمة القائمة على حاويات Linux ، مثل CoreOS Container Linux و rkt. ^{[ 21 ]} وهو مفيد كعنصر تحكم أمني إضافي للمساعدة في تعزيز العزل بين الحاويات المنشورة ومضيفها.

يتوفر SELinux منذ عام 2005 كجزء من نظام Red Hat Enterprise Linux (RHEL) الإصدار 4 وجميع الإصدارات اللاحقة. وينعكس هذا التواجد أيضًا في الإصدارات المقابلة من الأنظمة المشتقة مثل CentOS و Scientific Linux و AlmaLinux و Rocky Linux . تعتمد سياسة الأمان المُستهدفة في RHEL4 على مبدأ سهولة الاستخدام القصوى، ولذلك فهي ليست مُقيِّدة بالقدر الكافي. من المُخطط أن تتضمن الإصدارات اللاحقة من RHEL المزيد من الأهداف في سياسة الأمان المُستهدفة، مما يعني تطبيق سياسات أكثر تقييدًا. قدّم الإصدار 5 من RHEL سياسة الأمان متعددة المستويات (MLS) للخوادم فقط. وقدّم Fedora Linux 10 سياسة أمان دنيا، مُصممة لمنصات مُحددة مثل الأجهزة ذات الذاكرة المنخفضة والآلات الافتراضية . ^{[ 22 ]}

بدأ نظام openSUSE Tumbleweed بالانتقال من AppArmor إلى SELinux للتثبيتات الجديدة منذ 11 فبراير 2025، كما تم شحن نظام SLE/openSUSE Leap 16 مزودًا بـ SELinux افتراضيًا. ^{[ 23 ]} اعتمد نظام openSUSE/SLE سياسات RHEL/Fedora لتطبيق SELinux، مع بعض الاختلافات. ^{[ 24 ]} تم الاحتفاظ بـ AppArmor للتثبيتات الحالية لنظامي Tumbleweed وSLE/openSUSE Leap 15.x (يمكن للمستخدمين نقل تثبيتاتهم الحالية إلى SELinux يدويًا). يتوفر AppArmor أيضًا كخيار أثناء التثبيت لمستخدمي Tumbleweed، ولكنه غير متوفر في SLE/Leap 16. ^{[ 25 ] [ 26 ]}

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

^تتضمن أدوات سطر الأوامر ^{ما يلي : [ 27 ]}chcon ، ^{[ 28 ]}restorecon ، ^{[ 29 ]}restorecond ، ^{[ 30 ]}runcon ، ^{[ 31 ]}secon ، ^{[ 32 ]}fixfiles ، ^{[ 33 ]}setfiles ، ^{[ 34 ]}load_policy ، ^{[ 35 ]}booleans ، ^{[ 36 ]}getsebool ، ^{[ 37 ]}setsebool ، ^{[ 38 ]} ، togglesebool^{[ 39 ]} ، [ ⁴⁰ ] ، ^{[ 41 ]} و [ ⁴² ] setenforcesemodulepostfix-nochrootcheck-selinux-installationsemodule_packagecheckmoduleselinux-config-enforcingselinuxenabledselinux-policy-upgrade

يمثل SELinux أحد الحلول الممكنة لمشكلة تقييد صلاحيات البرامج المثبتة. وهناك بديل شائع آخر يُسمى AppArmor ، وهو متوفر على أنظمة SUSE Linux Enterprise Server (SLES) (قبل الإصدار 16)، و openSUSE ، والأنظمة المبنية على Debian . طُوّر AppArmor كمكوّن لمنصة Immunix Linux التي توقف تطويرها . ونظرًا للاختلاف الجذري بين AppArmor وSELinux، فإنهما يُمثلان بديلين متميزين للتحكم في البرامج. فبينما يُعيد SELinux ابتكار بعض المفاهيم لتوفير مجموعة أوسع من خيارات السياسات، صُمم AppArmor ليكون بسيطًا من خلال توسيع نفس الدلالات الإدارية المستخدمة في DAC لتشمل مستوى التحكم الإلزامي في الوصول.

هناك عدة اختلافات رئيسية:

• يتمثل أحد الفروق المهمة في أن AppArmor يُعرّف كائنات نظام الملفات باستخدام اسم المسار بدلاً من رقم العقدة (inode). هذا يعني، على سبيل المثال، أن ملفًا غير قابل للوصول قد يصبح قابلاً للوصول إليه في AppArmor عند إنشاء رابط ثابت إليه، بينما سيمنع SELinux الوصول إليه عبر هذا الرابط الثابت المُنشأ حديثًا.
  • ونتيجة لذلك، يمكن القول أن AppArmor ليس نظامًا لفرض النوع ، حيث لا يتم تعيين نوع للملفات؛ بدلاً من ذلك، تتم الإشارة إليها فقط في ملف التكوين.
• يختلف كل من SELinux و AppArmor اختلافًا كبيرًا في كيفية إدارتهما وكيفية دمجهما في النظام. ^{[ 43 ]}
• بما أن AppArmor يسعى إلى إعادة إنشاء ضوابط DAC التقليدية مع تطبيقها على مستوى MAC، فإن مجموعة عملياته أصغر بكثير من تلك المتاحة في معظم تطبيقات SELinux. على سبيل المثال، تتكون مجموعة عمليات AppArmor من: القراءة، والكتابة، والإلحاق، والتنفيذ، والقفل، والربط. ^{[ 44 ]} بينما تدعم معظم تطبيقات SELinux عددًا من العمليات يفوق ذلك بكثير. فعلى سبيل المثال، يدعم SELinux عادةً نفس هذه الأذونات، ولكنه يتضمن أيضًا ضوابط لـ mknod، والربط بمنافذ الشبكة، والاستخدام الضمني لإمكانيات POSIX، وتحميل وتفريغ وحدات النواة، ووسائل متنوعة للوصول إلى الذاكرة المشتركة، وما إلى ذلك.
• لا توجد في AppArmor أيّة ضوابط لتقييد صلاحيات POSIX بشكلٍ قاطع. ولأنّ التطبيق الحالي للصلاحيات لا يتضمن مفهوم "الفاعل" للعملية (فقط "الجهة الفاعلة" والعملية)، فإنّ مهمة طبقة MAC عادةً هي منع العمليات ذات الامتيازات على الملفات خارج نطاق تحكّم الجهة الفاعلة (أي "بيئة الحماية"). يستطيع AppArmor منع تعديل سياسته الخاصة، ومنع تحميل/إلغاء تحميل أنظمة الملفات، لكنّه لا يفعل شيئًا لمنع المستخدمين من تجاوز نطاق تحكّمهم المعتمد.
  • على سبيل المثال، قد يُعتبر من المفيد لموظفي الدعم الفني تغيير ملكية أو صلاحيات بعض الملفات حتى لو لم يكونوا مالكين لها (كما هو الحال في مشاركة ملفات القسم). لا يرغب المسؤول في منح المستخدمين صلاحيات الجذر على الجهاز، لذا يمنحهم صلاحيات معينة CAP_FOWNER. CAP_DAC_OVERRIDEفي بيئة SELinux، يمكن للمسؤول (أو مُورّد النظام الأساسي) تهيئة SELinux لحجب جميع الصلاحيات عن المستخدمين غير المقيدين، ثم إنشاء نطاقات مقيدة ليتمكن الموظف من الانتقال إليها بعد تسجيل الدخول، نطاق يسمح له بممارسة تلك الصلاحيات، ولكن فقط على الملفات من النوع المناسب.
• لا يوجد مفهوم للأمان متعدد المستويات في AppArmor، وبالتالي لا يوجد تطبيق صارم لـ BLP أو Biba متاح .
• يتم تكوين AppArmor باستخدام ملفات نصية عادية فقط. أما SELinux (افتراضياً في معظم التطبيقات) فيستخدم مزيجاً من الملفات النصية (التي يستخدمها المسؤولون والمطورون لكتابة سياسة قابلة للقراءة قبل تجميعها) والسمات الموسعة.
• يدعم SELinux مفهوم "خادم السياسات البعيد" (الذي يمكن تهيئته عبر /etc/selinux/semanage.conf) كمصدر بديل لتكوين السياسات. عادةً ما تكون الإدارة المركزية لـ AppArmor معقدة للغاية، حيث يتعين على المسؤولين الاختيار بين تشغيل أدوات نشر التكوين بصلاحيات المستخدم الجذر (للسماح بتحديثات السياسات) أو تهيئتها يدويًا على كل خادم.

ويمكن أيضاً تحقيق عزل العمليات من خلال آليات مثل المحاكاة الافتراضية .

اعتمدت وكالة الأمن القومي بعض مفاهيم SELinux في نظام Android المحسن أمنياً . ^{[ 45 ]}

تقوم شركة جنرال دايناميكس ببناء وتوزيع نظام التشغيل الموثوق PitBull، ^{[ 46 ]} وهو تحسين أمني متعدد المستويات (MLS) لنظام Red Hat Enterprise Linux .

يُعدّ نظام الأمان متعدد الفئات (MCS) إضافةً إلى SELinux لنظام Red Hat Enterprise Linux ، حيث يسمح للمستخدمين بتصنيف الملفات، وذلك لتقييد الوصول إليها بشكلٍ أكبر من خلال التحكم التقديري في الوصول وفرض أنواع البيانات. وتُوفّر الفئات أقسامًا إضافية ضمن مستويات الحساسية المستخدمة في نظام الأمان متعدد المستويات (MLS). ^{[ 47 ]}

• AppArmor – وحدة أمان نواة لينكس 
• أسترا لينكس – نظام تشغيل حاسوب روسي قائم على نظام لينكس 
• التحكم في الوصول القائم على مجموعة القواعد (RSBAC) – إطار عمل للتحكم في الوصول لنواة لينكس 
• نظام التحكم الإلزامي المبسط في الوصول إلى النواة - وحدة أمان نواة لينكس: صفحات تعرض أوصافًا مختصرة لأهداف إعادة التوجيه 
• ملحقات سولاريس الموثوقة – ملحقات أمان لنظام التشغيل سولاريس 
• تومويو – وحدة أمان نواة لينكس. صفحات تعرض أوصافًا مختصرة لأهداف إعادة التوجيه. 
• TrustedBSD – نظام تشغيل مجاني ومفتوح المصدر يشبه نظام يونكس. صفحات تعرض أوصافًا مختصرة لوجهات إعادة التوجيه. 
• أمان يونكس
• نظام التشغيل Qubes OS – نظام تشغيل قائم على لينكس يركز على الأمان 

• الموقع الرسمي