سلسلة RHCSA: الأساسيات الضرورية لمراقبة الوصول مع SELinux في RHEL 7 – الجزء 13

خلال هذه السلسلة، قمنا باستكشاف تفصيلي لما لا يقل عن طريقتين لمراقبة الوصول: أذونات ugo/rwx القياسية (إدارة المستخدمين والمجموعات – الجزء 3) وقوائم تحكم الوصول (تكوين ACL على أنظمة الملفات – الجزء 7).

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

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

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

في RHEL 7، يتم دمج SELinux في نفس النواة ويتم تمكينه بوضع Enforcing افتراضيًا. في هذه المقالة سنشرح بإيجاز المفاهيم الأساسية المرتبطة بـ SELinux وعمله.

أوضاع SELinux

يمكن لـ SELinux العمل بثلاث طرق مختلفة:

1. Enforcing: يرفض SELinux الوصول بناءً على قواعد سياسة SELinux، وهي مجموعة من الإرشادات التي تتحكم في محرك الأمان.
2. Permissive: لا يرفض SELinux الوصول، ولكن يتم تسجيل الرفض للإجراءات التي كان يجب رفضها إذا كانت تعمل في وضع الإجبار.
3. Disabled (واضحة المعنى).

يعرض الأمر getenforce الوضع الحالي لـ SELinux، بينما يُستخدم الأمر setenforce (تليه 1 أو 0) لتغيير الوضع إلى Enforcing أو Permissive، على التوالي، خلال الجلسة الحالية فقط.

لتحقيق الثبات عبر تسجيل الخروج وإعادة التشغيل، ستحتاج إلى تحرير ملف /etc/selinux/config وتعيين متغير SELINUX إما إلى enforcing، permissive، أو disabled:

# getenforce
# setenforce 0
# getenforce
# setenforce 1
# getenforce
# cat /etc/selinux/config

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

البيانات السي لينكسية

A SELinux context consists of an access control environment where decisions are made based on SELinux user, role, and type (and optionally a level):

1. A SELinux user complements a regular Linux user account by mapping it to a SELinux user account, which in turn is used in the SELinux context for processes in that session, in order to explicitly define their allowed roles and levels.
2. يعني مجال الدور كوسيلة بين المجالات ومستخدمي السي لينكسية في أنه يحدد أي تواجد مجالات العمليات وأنواع الملفات التي يمكن الوصول إليها. هذا يحمي جهازك ضد الاضطرابات المتعلقة بترسيخ الموارد الشرعية.
3. A type defines an SELinux file type or an SELinux process domain. Under normal circumstances, processes are prevented from accessing files that other processes use, and and from accessing other processes, thus access is only allowed if a specific SELinux policy rule exists that allows it.

دعونا نرى كيف يعمل كل هذا من خلال المثالين التاليين.

مثال 1: تغيير منتصف البوت للدايمون

في تأمين SSH – جزء 8 أشرفنا بأن تغيير منتصف البوت الإفتراضي حيث يستمع sshd هوأحد التدابير الأولية لحماية جهازك ضد الهجمات الخارجية. دعونا نحرر ملف /etc/ssh/sshd_config و نضع المنتصف في 9999:

Port 9999

حفظ التغييرات، ثم إعادة بدء sshd:

# systemctl restart sshd
# systemctl status sshd

كما ترون، فقد فشلت sshd في البدء. لكن ماذا حدث؟

A quick inspection of /var/log/audit/audit.log indicates that sshd has been denied permissions to start on port 9999 (SELinux log messages include the word “AVC” so that they might be easily identified from other messages) because that is a reserved port for the JBoss Management service:

# cat /var/log/audit/audit.log | grep AVC | tail -1

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

استعمال،

# semanage port -l | grep ssh

للحصول على قائمة بالمنافذ التي يسمح لها SELinux بإستماع sshd.

لذا دعونا نغير المنتصف في /etc/ssh/sshd_config إلى Port 9998، وأضف المنتصف إلى سياق ssh_port_t، ثم إعادة بدء الخدمة:

# semanage port -a -t ssh_port_t -p tcp 9998
# systemctl restart sshd
# systemctl is-active sshd

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

مثال 2: تسمية httpd لإرسال إشعار sendmail

هذا مثال على توظيف سيلينكس لإدارة عملية تتواصل مع عملية أخرى. إذا كنت تقوم بتطوير mod_security و mod_evasive مع Apache في سerveur RHEL 7 ، يجب عليك تمكين httpd عن متابعة sendmail لإرسال إشعار بالبريد في حالة (D)DoS هجمة. في الأمر التالي ، تختفي علامة -P إذا لم تريد أن يكون التغيير دائمًا بعد الإعادة التشغيلية.

# semanage boolean -1 | grep httpd_can_sendmail
# setsebool -P httpd_can_sendmail 1
# semanage boolean -1 | grep httpd_can_sendmail

كما تلاحظ من مثال الأعلى ، إن إعدادات الـ مجموعة الأحكام الصحيح / خطأ لسيلينكس (أو ببساطة المجموعات) هي قواعد صحيح / خطأ مكونة في سياسات سيلينكس. يمكنك قائمة بجميع المجموعات مع semanage boolean -l ، وبدلاً من ذلك يمكنك قنابلها إلى grep لتصفر الخروج.

مثال 3: تقديم موقع ثابت من مجلد آخر ما عدا المجلد الافتراضي

فهما أنك تقوم بتقديم موقع ثابت باستخدام مجلد آخر ما عدا المجلد الافتراضي (/var/www/html)، قول /websites (قد يكون الحال إذا كنت تخزين ملفات شبكية تعمل لديك وتحتاج إلى توصيلها في /websites).

a). Create an index.html file inside /websites with the following contents:

<html>
<h2>SELinux test</h2>
</html>

إذا كان هذا هو حالك

# ls -lZ /websites/index.html

سترون أن الملف index.html معرّف بنوع default_t SELinux الذي لا يستطيع أپاكيلو مراجعته:

b). Change the DocumentRoot directive in /etc/httpd/conf/httpd.conf to /websites and don’t forget to update the corresponding Directory block. Then, restart Apache.

c). Browse to http://<web server IP address>, and you should get a 503 Forbidden HTTP response.

d). Next, change the label of /websites, recursively, to the httpd_sys_content_t type in order to grant Apache read-only access to that directory and its contents:

# semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"

e). Finally, apply the SELinux policy created in d):

# restorecon -R -v /websites

الآن قوم بإعادة تشغيل أپاكيلو وقوم بمراجعة http://<IP الجهاز السيء> مجددًا وسترون الملف ال HTML المسمي بطريقة correct:

الخلاصة

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

إذا استطعت ، دعوني أوصي بمصادرين أساسيتين للبدء: صفحة NSA SELinux ودليل RHEL 7 SELinux للمستخدمين والمدراء.

لا تتردد في إخبارنا بأي أسئلة أو تعليقات.