مقال :مقدمه الى SELinux الجزء الثالث-المستخدمين

تم أرشفة هذا المحتوى

في الجزء الأخير من هذه السلسة سوف نتحدث عن SELinux users وسوف نتعرف على طرق التعامل مع الأخطاء التي يتم تسجيلها في سجلات SELinux error logs.

ملاحظة: كل التعليمات وحزم البيانات والملفات التي سوف نتعامل معها في هذا المقال تم تجريبها على نظام التشغيل CentOS 7 بشكل عام فإن المبادئ تبقى نفسها في التوزيعات الأخرى.

في هذا المقال سنقوم بتشغيل التعليمات بصلاحيات root إذا لم تكن تستطيع العمل على حساب بصلاحيات root يمكنك استخدام حساب له صلاحيات sudo privileges واستخدام “sudo” قبل أي تعليمة.

SELinux Users:

المستخدمين في SELinux مختلفين عن المستخدمين العاديين في نظام لينكس وهذا الاختلاف متضمن حساب root  أيضاً, في SELinux  المستخدم ليس كالمستخدم العادي الذي تقوم أنت بأنشاءه باستخدام تعليمة معينةاو ذلك المستخدم  الذي يجب أن يقوم بعملية تسجيل الدخول إلى السيرفر , في SELinux  المستخدمين يتم تعريفهم في السياسة التي يتم تحميلها إلى الذاكرة أثناء عملية الإقلاع ويوجد عدد قليل فقط من المستخدمين. يتم الإشارة إلى اسم المستخدم بإضافة _u بشكل مشابه للأنواع types التي يتم الإشارة إليها بإضافة _t  والقواعد roles التي يتم الإشارة إليها من خلال إضافة _r.

كل مستخدم في SELinux له حقوق مختلفة في النظام, اسم المستخدم الخاص ب SELinux يتم عرضه في الجزء الأول من security context عندما تعمل SELinux في النمط enforced فإن كل مستخدم عادي في نظام لينكس يتم ربطه مع مستخدم SELinux

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

لرؤية الحسابات المرتبطة ببعضها يمكننا استخدام التعليمة التالية:

semanage login -l

والنتيجة:

Login Name             SELinux User        MLS/MCS Range       Service
__default__               unconfined_u              s0-s0:c0.c1023            *

root                             unconfined_u              s0-s0:c0.c1023            *

system_u                     system_u                      s0-s0:c0.c1023            *

العمود الأول “Login Name” يحوي على أسماء حسابات مستخدمي نظام لينكس العاديين، يوجد ثلاث حسابات فقط، قد تتسأل ألم نقم بأنشاء أربع حسابات تجريبية في الجزء السابق من هذه السلسلة؟؟ نعم لقد قمنا بذلك وهذه الحسابات يتم تمثيلها ضمن default ، أي حساب لمستخدم عادي . العمود الثاني يحوي على أسماء حسابات SELinux , العمود الثالث يحوي على: MLS – Multilevel Security

MCS – Multi Category Security الخاصين بكل مستخدم، الآن تجاهل هذا العمود والعمود الذي بعده (Service)

حساب root يكون مستقل عن الحسابات العادية التي يتم تمثيلها ضمن “default” وكما تلاحظ فإن حساب root مرتبط مع الحساب unconfined_u.

لرؤية كل مستخدمي SELinux يمكننا استخدام التعليمة التالية:

semanage user -l

والنتيجة:

Labeling MLS/ MLS/

SELinux User Prefix MCS Level MCS Range SELinux Roles

guest_u user s0 s0 guest_r

root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r

staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r

sysadm_u user s0 s0-s0:c0.c1023 sysadm_r

system_u user s0 s0-s0:c0.c1023 system_r unconfined_r

unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r

user_u user s0 s0 user_r

xguest_u user s0 s0 xguest_r

 

هذا الجدول يحوي على أسماء حسابات SELinux المُعرفة ضمن السياسة , لقد رأينا الحسابات Unconfined_u and system_u من قبل ولكن لم نرى باقي الحسابات مثل guest_u, staff_u, sysadm_u , user_u

هذه الأسماء تشير إلى الحقوق أو الصلاحيات المرتبطة بها.

مثلاً: يمكننا أن نفترض أن المستخدم sysadm_u يمكن أن يكون له صلاحيات أكثر من المستخدم guest_u وللتأكد من ذلك يمكننا النظر إلى العمود الخامس “SELinux Roles” إذا كنت تذكر ومن الجزء السابق فإن SELinux roles هي عبارة عن بوابات بين المستخدم والعملية (نظام تصفية أو فلترة) يتم السماح للمستخدم بالوصول والقيام بالعملية إذا كان ذلك مسموح ضمن القواعد المطبقة (المستخدم المرتبط بهذه القواعد يستطيع الوصول إلى المجال الخاص بالعملية .

من الجدول السابق يمكننا رؤية أن المستخدم unconfined_u مرتبط مع القواعد system_r و unconfined_r

سياسة SELinux تسمح لهذه القواعد بتشغيل العمليات processes ضمن المجال unconfined_t domain وبشكل مشابه فإن المستخدم sysadm_u مسموح له العمل ضمن القواعد sysadm_r. كل من هذه القواعد تملك مجالات domains مختلفة تحدد لها الأمور المسموح بها.

لنعد خطوة إلى الوراء، لقد رأينا أن حسابات مستخدمي لينكس العاديين يتم تمثيلها ضمن default وهي مرتبطة بمستخدم SELinux ذو الاسم unconfined_u كما أن مستخدم لينكس root مرتبط مع مستخدم SELinux ذو الاسم unconfined_u هذا يعني أن أي مستخدم لينكس عادي يسمح له العمل وفق القواعد system_r و unconfined_r

لشرح ذلك لنقوم باستخدام التعليمة التالية:

id -Z

والتي سوف تعرض SELinux security context الخاصة بحساب root

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

حساب root مرتبط مع مستخدم SELinux ذو الاسم unconfined_u كذلك مستخدم SELinux ذو الاسم unconfined_u مسموح له العمل ضمن القواعد unconfined_r.

القواعد unconfined_r مسموح لها تشغيل العمليات ضمن المجال unconfined_t
الآن لنقم بفتح أربع جلسات SSH مع المستخدمين الأربعة وذلك من خلال أربع نوافذ terminal منفصلة.

• regularuser
• switcheduser
• guestuser
• restricteduser

(في الجزء السابق قمنا بخلق هذه الحسابات الأربعة)

لننتقل إلى الجلسة الخاصة بالمستخدم regularuser

إذا قمنا بتنفيذ التعليمة id –Z هنا:

[regularuser@localhost ~]$ id -Z

فسوف نحصل على التالي:

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

حساب مستخدم لينكس العادي ذو الاسم regulauser مرتبط بحساب مستخدم SELinux ذو الاسم unconfined_u الذي يعمل ضمن القواعد unconfined_r وهذه القواعد تسمح للمستخدم الوصول للعمليات ضمن المجال unconfined_t

لقد رأينا سابقاً عدد من مستخدمي SELinux:

• guest_u: هذا المستخدم لا يستطيع الوصول إلى X-Windows system (GUI) أو إلى الشبكة ولا يستطيع تنفيذ تعليمات su/sudo command
• xguest_u: هذا المستخدم يستطيع الوصول إلى أدوات GUI وإلى الشبكة وهو متاح للمتصفح Firefox
• user_u: هذا المستخدم له صلاحيات أكثر من حساب guest فهو يستطيع الوصول إلى أدوات GUI وإلى الشبكة ولكنه لا يستطيع تشغيل تعليمات su/sudo
• staff_u: له نفس صلاحيات user_u باستثناء أنه يستطيع تشغيل تعليمة sudo للحصول على صلاحيات root
• system_u: هذا الحساب مُعد لخدمات النظام وليس مخصص للمستخدم العادي.

تقييد عملية التحويل بين الحسابات :

كمدير نظام أنت تعرف الآن المستخدم الذي يملك صلاحيات SELinux الغير محدودة مثل حساب root وتريد تغير ذلك.

بشكل خاص أنت لا تريد السماح للمستخدم أن يقوم بتبديل حسابه وهذا يتضمن حساب root أيضاً.

لنرى قدرة المستخدم على تبديل الحساب إلى حساب أخر، نفترض بأن المستخدم على معرفة بكلمة السر الخاصة بالحساب الآخر.

[regularuser@localhost ~]$ su – switcheduser

Password:

[switcheduser@localhost ~]$

لنعد إلى التيرمينل الخاصة بالمستخدم root لنقم ببعض بربط حساب مستخدم لينكس regularuser مع مستخدم SELinux ذو الاسم user_u

semanage login -a -s user_u regularuser

a-: للإشارة إلى عملية الإضافة adding

s-: للإشارة إلى مستخدم SELinux

لقد قمنا بإضافة مستخدم لينكس ذو الاسم regularuser إلى مستخدم SELinux ذو الاسم user_u

هذا التغير لن يطبق إلى بعد أن يقوم المستخدم regularuser بتسجيل الخروج ومن ثم تسجيل الدخول مرة ثانية.

لنعد إلى التيرمنيل الخاصة بالمستخدم switcheduser

[switcheduser@localhost ~]$ logout

ومن ثم إلى التيرمنيل الخاصة بالمستخدم regularuser

[regularuser@localhost ~]$ logout

الآن لنقم بعملية تسجيل الدخول لحساب المستخدم regularuser

[regularuser@localhost ~]$ su – switcheduser

Password:

والنتيجة ستكون كالتالي:

su: Authentication failure

إذا قمنا بتنفيذ التعليمة id –Z لعرض SELinux context للمستخدم regularuser

سوف نرى نتيجة مختلفة عن النتيجة السابقة

الآن فإن مستخدم لينكس regularuser مرتبط مع المستخدم user_u الخاص ب SELinux

[regularuser@localhost ~]$ id -Z

user_u:user_r:user_t:s0

متى يجب أن نستخدم مثل هذه التقييد؟؟

إذا كان لديك فريق لتطوير التطبيقات (عدد من المطورين والمختبرين في فريق للبرمجة)

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

تقييد صلاحيات تشغيل سكربتات :

لنرى مثال أخرى عن تقييد الوصول للمستخدم من خلال SELinux

بشكل افتراضي فإن SELinux تسمح للمستخدمين المرتبطين مع الحساب guest_t بتنفيذ سكريبتات في المجلد home

يمكننا استخدام التعليمة التالية لفحص القيمة المنطقية

getsebool allow_guest_exec_content

النتيجة كالتالي:

guest_exec_content –> on

للتأكد من ذلك لنقم أولاً بتغيير مستخدم SELinux المرتبط مع مستخدم لينكس guestuser

semanage login -a -s guest_u guestuser

ومن ثم التأكد من ذلك باستخدام التعليمة التالية:

semanage login -l

كما ترى فإن مستخدم لينكس guestuser مرتبط مع مستخدم SELinux ذو الاسم guest_u

Login Name         SELinux      User MLS/MCS Range       Service

__default__          unconfined_u             s0-s0:c0.c1023            *

guestuser                 guest_u                                s0                           *

regularuser              user_u                                  s0                           *

root                         unconfined_u                0-s0:c0.c1023          *

system_u              system_u                        s0-s0:c0.c1023          *

من خلال التيرمينل الخاصة بالمستخدم guestuser سنقوم بعملية تسجيل الخروج ومن ثم إعادة تسجيل الدخول مرة أخرى.

سنقوم بإعداد bash script في المجلد home الخاص بالمستخدم , للتأكد من أننا في مجلد home الخاص بهذا المستخدم يمكننا استخدام التعليمة التالية:

[guestuser@localhost ~]$ pwd

والنتيجة:

/home/guestuser

لنقم بإعداد السكريبت:

#!/bin/bash

echo “This is a test script”

لإعطاء صلاحيات تنفيذية لهذه السكريبت

chmod u+x myscript.sh

عندما نقوم بتنفيذ هذه السكريبت

[guestuser@localhost ~]$ ~/myscript.sh

تكون النتيجة كالتالي:

This is a test script

لنعد إلى التيرمينل الخاصة بحساب root ولنقم بتغيير off to on ومن ثم التأكد من ذلك

setsebool allow_guest_exec_content off

getsebool allow_guest_exec_content

guest\_exec\_content –> off

لنعد إلى التيرمينل الخاصة بالمستخدم guestuser ولنقم بتشغيل هذه السكريبت مرة أخرى

[guestuser@localhost ~]$ ~/myscript.sh

والنتيجة هي أنه تم منع تنفيذ هذه السكريبت

-bash: /home/guestuser/myscript.sh: Permission denied

كما تلاحظ فإن SELinux تقوم بتطبيق طبقة حماية إضافية فوق DAC حتى ولو كان للمستخدم صلاحية كاملة للقراءة والكتابة فلن يكون له صلاحية للتنفيذ.

ما هي الفائدة من ذلك؟؟

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

سوف نتحدث عن رسائل الخطأ الخاصة ب SELinus بشكل مختصر ولكن الآن إذا كنت متحمس لرؤية عملية المنع في السجل /var/log/messages يمكنك استخدام التعليمة التالية:

grep “SELinux is preventing” /var/log/messages

والنتيجة كالتالي:

Aug 23 12:59:42 localhost setroubleshoot: SELinux is preventing /usr/bin/bash from execute access on the file . For complete SELinux messages. run sealert -l 8343a9d2-ca9d-49db-9281-3bb03a76b71a

في هذه الرسالة تظهر قيمة معرف ID ، يمكننا استخدام التعليمة sealer مع ID من أجل الحصول على معلومات أكثر (رقم ID سيكون مختلف لديك)

sealert -l 8343a9d2-ca9d-49db-9281-3bb03a76b71a

والنتيجة هي تفاصيل عن هذا الخطأ

SELinux is preventing /usr/bin/bash from execute access on the file .

*** Plugin catchall_boolean (89.3 confidence) suggests ***

If you want to allow guest to exec content

Then you must tell SELinux about this by enabling the ‘guest\_exec\_content’ boolean.

You can read ‘None’ man page for more details.

Do

setsebool -P guest\_exec\_content 1

*** Plugin catchall (11.6 confidence) suggests ***

…

SELinux قام بمنع /usr/bin/bash من تنفيذ هذا الملف.

النص التالي يخبرنا عن طريقة إصلاح هذا الخطأ

If you want to allow guest to exec content

Then you must tell SELinux about this by enabling the ‘guest\_exec\_content’ boolean.

…

setsebool -P guest\_exec\_content 1

تقييد الوصول الى الخدمات :

في الجزء الأول من هذه السلسلة تعرفنا على القواعد SELinux rules لنرى كيف تعمل هذه القواعد لمنع المستخدم من الوصول. القواعد في SELinux تكون بين المستخدم ومجال العملية process domain وهي التي تتحكم بالمجالات التي يسمح للمستخدم الوصول إليها. القواعد غير مهمة عندما نرى security contexts للملفات ولكن هذه القواعد مهمة عندما نتعامل مع المستخدمين والعمليات.

في البداية لنتأكد من أن httpd لا تعمل في النظام من خلال تنفيذ التعليمة التالية:

service httpd stop

الآن لننتقل إلى التيرمينل الخاصة بالمستخدم restricteduser ولنرى SELinux security context

[restricteduser@localhost ~]$ id -Z

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

هذا الحساب مرتبط بشكل تلقائي مع مستخدم SELinux ذو الاسم unconfined_u ويعمل ضمن القواعد unconfined_r ولكن هذا الحساب ليس له صلاحية لتشغيل أي عملية في النظام.

لنقم الآن بتشغيل httpd

[restricteduser@localhost ~]$ service httpd start

Redirecting to /bin/systemctl start httpd.service

Failed to issue method call: Access denied

لقد تم منعنا من تشغيل هذه الخدمة.

لنعد إلى التيرمينل الخاصة بحساب root ولنتأكد من أن حساب المستخدم restricteduser قم تم إضافته إلى الملف

/etc/sudoers

هذه العملية تسمح لهذا الحساب أن يستخدم صلاحيات root

visudo

وضمن هذا الملف يجب أن نضيف السطر التالي ومن ثم حفظ الملف والخروج منه

restricteduser ALL=(ALL) ALL

إذا قمنا بتسجيل الخروج من حساب restricteduser ومن ثم قمنا بعملية تسجيل الدخول، يمكننا بعدها تشغيل وإيقاف httpd باستخدام صلاحيات sudo

[restricteduser@localhost ~]$ sudo service httpd start

We trust you have received the usual lecture from the local System

Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.

#2) Think before you type.

#3) With great power comes great responsibility.
[sudo] password for restricteduser:

Redirecting to /bin/systemctl start httpd.service

كما يمكننا إيقاف httpd باستخدام التعليمة التالية:

[restricteduser@localhost ~]$ sudo service httpd stop
Redirecting to /bin/systemctl stop httpd.service

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

لننتقل إلى التيرمينل الخاصة بحساب root ولنقم بربط حساب مستخدم لينكس restricteduser مع مستخدم SELinux ذو الاسم user_u

semanage login -a -s user_u restricteduser

لنعد إلى التيرمينل الخاصة بالمستخدم restricteduser ولنقوم بعملية تسجيل الخروج ومن ثم تسجيل الدخول، الآن فإن هذا المستخدم مرتبط مع user_u (هذا يعني أنه يعمل ضمن user_r and user_t)

يمكننا التأكد من ذلك باستخدام التعليمة التالية:

seinfo -uuser_u -x

والنتيجة:

user_u

default level: s0

range: s0

roles:

object_r

user_r

يمكننا استخدام التعليمة seinfo لمعرفة المجالات domains التي يسمح للقواعد user_r بالدخول إليها

seinfo -ruser_r -x

يوجد عدد من المجالات domains المسموح ل user_r الوصول إليها

user_r

Dominated Roles:

user_r

Types:

git_session_t

sandbox_x_client_t

git_user_content_t

virt_content_t

policykit_grant_t

httpd_user_htaccess_t

telepathy_mission_control_home_t

qmail_inject_t

gnome_home_t

…

…

ولكن هل هذه القائمة تظهر أن httpd_t موجودة ضمن هذه المجالات، لمعرفة ذلك يمكننا استخدام التعليمة التالية:

seinfo -ruser_r -x | grep httpd

يوجد عدد من httpd مرتبطة بالمجالات ولكن httpd_t غير موجودة

httpd_user_htaccess_t

httpd_user_script_exec_t

httpd_user_ra_content_t

httpd_user_rw_content_t

httpd_user_script_t

httpd_user_content_t

إذا حاول المستخدم restricteduser القيام بتشغيل خدمة httpd فيجب أن يتم منعه من ذلك لأن العملية httpd تعمل ضمن المجال httpd_t وهذا المجال غير موجود ضمن القواعد user_r حتى ولو كان هذا الحساب قادر على الحصول على صلاحيات sudo
لنعد إلى التيرمينل الخاصة بالمستخدم restricteduser ولنقم بتشغيل httpd (يمكننا إيقاف تشغيل httpd لأننا نملك صلاحيات sudo)

[restricteduser@localhost ~]$ sudo service httpd start

سوف يتم منع هذه العملية:

sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted

تدقيق سجلات SELinux :

كمدير نظام من المهم أن تتعرف على رسائل الخطأ الخاصة ب SELinux والتي يتم تسجيلها في السجالات, هذه الرسائل يتم تسجيلها في الملفات التالية في نظام التشغيل CentOS 7

/var/log/audit/audit.log: هذا الملف يستخدم في حال كان auditd daemon يعمل

/var/log/messages: هذا الملف يستخدم عندما يكون auditd لا يعمل و rsyslogd يعمل

وإذا كان كل من auditd and rsyslogd يعملان فيتم استخدام /var/log/audit.log لتسجيل المعلومات التفصيلية بينما يستخدم الملف /var/log/message لحفظ معلومات بسيطة وسهلة للقراءة.

رسائل الخطأ في SELinux:

تعرفنا سابقاً على رسالة خطأ خاصة ب SELinux وقمنا باستخدام التعليمة grep للبحث عن الخطأ المطلوب ضمن الملف /var/log/messages

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

ausearch: يمكننا استخدام هذه التعليمة إذا كان auditd يعمل

ausearch -m avc -c httpd

في نظامنا تم تسجيل عدد من المدخلات ولكننا سنركز فقط على أخر دخل

—-

time->Thu Aug 21 16:42:17 2014

…

type=AVC msg=audit(1408603337.115:914): avc: denied { getattr } for pid=10204 comm=”httpd” path=”/www/html/index.html” dev=”dm-0″ ino=8445484 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

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

type=AVC and avc: AVC – Access Vector Cache

SELinux تستخدم ذاكرة مخبئة في قرارات التحكم بالمصادر والعمليات.

وهذه الذاكرة المخبئة تعرف باسم AVC وفي رسائل منع الوصول الخاصة ب SELinux يوجد حقلين من المعلومات الأولي تخبرنا بأن المدخلات قادمة من AVC log والثانية هي AVC event

denied [getattr]: محاولة الحصول على الصلاحية والنتيجة التي حصلت عليها وفي هذا المثال تم منع get attribute

pid=10204: مُعرف العملية process ID التي تحاول الوصول

comm: مُعرف العملية لا يفيد كثيراً، comm attribute يظهر التعليمة الخاصة بالعملية، وفي هذا المثال هي httpd (من خلال ذلك يمكننا معرفة أن رسالة الخطأ خاصة بسيرفر الويب)

path: مسار أو مكان المصادر التي تم الوصول إليها، وفي هذا المثال هو /www/html/index.html

dev and ino: الجهازdevice وعنوان inode

scontext: وهي security context لهذه العملية

tcontext: وهي security context of target resouuce وفي هذا المثال هي default_t

tclass: وهي class of the target resource وفي هذا المثال هي الملف.
مجال العملية process domina: httpd_t

ونوع الملف file’s type: default_t

هذا يعني أن العملية httpd تعمل ضمن المجال confined domain وسياسة SELinux تشترط أن هذا المجال لا يمكنه الوصول إلى أي من الملفات ذات النوع default_t ولذلك تم منع عملية الوصول.

التعليمة التالية تستخدم للحصول على رسائل الخطأ الموجودة ضمن الملف /var/log/message والمتعلقة ب SELinux

cat /var/log/messages | grep “SELinux is preventing”

سوف نناقش أخر رسالة والتي تظهر الخطأ الذي تم تسجيله عندما حاول المستخدم restricteduser تشغيل httpd

…

Aug 25 11:59:46 localhost setroubleshoot: SELinux is preventing /usr/bin/su from using the setuid capability. For complete SELinux messages. run sealert -l e9e6c6d8-f217-414c-a14e-4bccb70cfbce

يمكننا استخدام التعليمة sealert مع قيمة ID لرؤية التفاصيل (قيمة ID ستكون مختلفة لديك)

sealert -l e9e6c6d8-f217-414c-a14e-4bccb70cfbce
SELinux is preventing /usr/bin/su from using the setuid capability.
…
Raw Audit Messages

type=AVC msg=audit(1408931985.387:850): avc: denied { setuid } for pid=5855 comm=”sudo” capability=7 scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=capability

type=SYSCALL msg=audit(1408931985.387:850): arch=x86_64 syscall=setresuid success=no exit=EPERM a0=ffffffff a1=1 a2=ffffffff a3=7fae591b92e0 items=0 ppid=5739 pid=5855 auid=1008 uid=0 gid=1008 euid=0 suid=0 fsuid=0 egid=0 sgid=1008 fsgid=0 tty=pts2 ses=22 comm=sudo exe=/usr/bin/sudo subj=user_u:user_r:user_t:s0 key=(null)
Hash: su,user_t,user_t,capability,setuid

السطور الأولى من خرج التعلمية sealert تخبرنا بخطوات المعالجة.

Multilevel Security:

الحماية متعددة المستويات MLS هي جزء من SELinux security context

عندما تحدثنا عن security context للعمليات أو المستخدمين أو المصادر كان هناك ثلاث أنواع وهي:

• SELinux user
• SELinux role
• SELinux type or domain
•  sensitivity

لنفترض أن security context لملف الإعدادات الخاص ب FTP

ls -Z /etc/vsftpd/vsftpd.conf

هي كالتالي:

-rw——-. root root system_u:object_r:etc_t:s0 /etc/vsftpd/vsftpd.conf

في هذا المثال فإن sensitivity هي s0

الحساسية sensitivity هي جزء من hierarchical multilevel security mechanism والتدرج الهرمي يعني أن مستويات الحماية يمكن أن تكون أعمق وأعمق من أجل حماية النظام بشكل أكبر

المستوى 0 (s0) هو أقل مستوى حماية ويمكن أن يسمى “public”, يوجد مستويات حماية بقيم أعلى مثلاً internal, confidential or regulatory وتمثل بمستويات s1, s2 and s3

وهذا الأمر غير مشروط في السياسة، ويمكن لمدير النظام تحديد مستوى الحساسية sensitivity.

عندما يتم إعداد SELinux لتعمل ضمن MLS (من خلال تعديل ملف الإعدادات /etc/selinux/config) من الممكن أن تجعل بعض الملفات أو العمليات ضمن مستوى حماية محدد.

أقل مستوى حماية يسمى “current sensitivity” وأعلى مستوى حماية يسمى “clearance sensitivity”

التصنيف category يعمل مع الحساسية sensitivity حيث يتم تصنيف المصادر من خلال تخصيص وسم لكل مصدر والغاية من التصنيف هو التحكم بالوصول بشكل أفضل.عندما يتم تطبيق مجال من مستويات الحساسية يتم الفصل بين بداية ونهاية هذا المجال باستخدام ” – ” كما في المثال التالي (s0 – s2)

عندما يتم استخدام التصنيف يتم الفصل بين حدود المجال الخاص به باستخدام نقطة ” . ” بين حدود المجال

يتم الفصل بين قيم الحساسية والتصنيف باستخدام ” : ”

كما في المثال التالي:

user_u:object_r:etc_t:s0:c0.c2

يوجد مستوى حساسية واحد وهو s0

مستوى التصنيف هو c0.c2

يتم تحديد مستوى التصنيف في الملف /etc/selinux/targeted/setrans.conf

cat /etc/selinux/targeted/setrans.conf
#

# Multi-Category Security translation table for SELinux

#

#

# Objects can be categorized with 0-1023 categories defined by the admin.

# Objects can be in more than one category at a time.

# Categories are stored in the system as c0-c1023. Users can use this

# table to translate the categories into a more meaningful output.

# Examples:

# s0:c0=CompanyConfidential

# s0:c1=PatientRecord

# s0:c2=Unclassified

# s0:c3=TopSecret

# s0:c1,c3=CompanyConfidentialRedHat

s0=SystemLow

s0-s0:c0.c1023=SystemLow-SystemHigh

s0:c0.c1023=SystemHigh

لن نتعمق في تفاصيل الحساسية والتصنيف.

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

العملية يمكنها الكتابة في المصادر عندما يكون مستوى الحساسية والتصنيف لها أقل من المستوى الخاص بالمصادر.

الخلاصة:

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

لقد استخدمنا SELinux لتطبيق الحماية التي نحتاجها وتعرفنا على رسائل الخطأ الخاصة ب SELinux وطريقة التعامل معها.

يوجد العديد من الكتب الخاصة ب SELinux والتي يمكنك من خلالها إمضاء ساعات في محاولة اكتشاف الحزم والإعدادات والتعليمات الخاصة ب SELinux بالإضافة إلى تأثيرها على الحماية.

لا تقم بتجربة كل شيء على نظام يعمل ويقدم خدمة، عندما تتقن الأساسيات ابدأ اللعب مع SELinux في بيئة تجريبية تكون نسخة طبق الأصل للنظام الخاص بك وتأكد من أن audit daemons يعمل وراقب رسائل الخطأ وقم باللعب بإعدادات القيم المنطقية.

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

ترجمة لمقال :   An Introduction to SELinux on CentOS 7 – Part 3: Users لصاحبها Sadequl Hussain