newrole -r role_r -t domain_t (عادة يكون هناك نطاق وحيد فقط مسموح لكل دور، ولذلك يمكن إهمال المتغير -t غالباً). يتحقق هذا الأمر منك عبر طلب إدخال كلمة السر. تمنع هذه الميزة البرامج من تغيير الأدوار آلياً. لا يمكن تنفيذ هذه التغييرات إلا إذا كانت مسموحة صراحة في سياسة SELinux.
ssh بالنوع ssh_exec_t وعند تشغيل البرنامج، سينتقل تلقائياً إلى النطاق ssh_t) . تسمح آلية الانتقال التلقائي بين النطاقات هذه بمنح كل برنامج الصلاحيات التي يحتاجها فقط. هذا أحد المبادئ الأساسية في SELinux.
apt install selinux-basics selinux-policy-default آلياً الحزم اللازمة لإعداد نظام SELinux.
unconfined (سنشرح إدارة الوحدات لاحقاً في هذا القسم).
fixfiles relabel.
selinux=1 security=selinux إلى النواة لينكس. أما المتغير audit=1 فيفعّل سجلات SELinux التي تسجل كل الإجراءات التي منعها. أخيراً، يضع المتغير enforcing=1 القواعد في حيز التطبيق، إذ بدونه يعمل SELinux في وضع permissive الافتراضي حيث يكتفي بتسجيل الإجراءات الممنوعة لكنه يسمح بتنفيذها. عليك إذن تعديل ملف إعداد محمل الإقلاع GRUB لإضافة المتغيرات المطلوبة. إحدى الطرق السهلة لتنفيذ ذلك تعديل المتغير GRUB_CMDLINE_LINUX في الملف /etc/default/grub ثم استدعاء update-grub. سينشط SELinux بعد إعادة الإقلاع.
selinux-activate يؤتمت هذه الخطوات ويفرض عملية الوسم عند الإقلاع التالي (وبذلك يتفادى إنشاء ملفات جديدة غير موسومة قبل تنشيط SELinux أو أثناء تنفيذ عملية الوسم).
semodule. بالإضافة لذلك، يجب أن تتمكن من تعريف الأدوار التي يمكن أن يأخذها كل مستخدم، ويمكن تنفيذ هذا باستخدام الأمر semanage.
/etc/selinux/default/. بخلاف ملفات الإعداد الأخرى التي تجدها في /etc/، لا يجب تعديل أي من هذه الملفات يدوياً. بل يجب استخدام البرامج المخصصة لهذا الغرض.
/usr/share/selinux/default/. لتنشيط إحدى هذه الوحدات في الإعداد الحالي، عليك استخدام semodule -i module.pp.bz2. ترمز الإضافة pp.bz2 للعبارة policy package (مضغوطة باستخدام bzip2).
semodule -r module. أخيراً، يسرد الأمر semodule -l الوحدات المُثبّتة حالياً، كما يطبع أرقام إصدارها. يمكن تفعيل الوحدات اختيارياً عبر semodule -e كما يمكن تعطيلها عبر semodule -d.
#semodule -i /usr/share/selinux/default/abrt.pp.bz2#semodule -labrt 1.5.0 Disabled accountsd 1.1.0 acct 1.6.0 [...]#semodule -e abrt#semodule -d accountsd#semodule -labrt 1.5.0 accountsd 1.1.0 Disabled acct 1.6.0 [...]#semodule -r abrt#semodule -laccountsd 1.1.0 Disabled acct 1.6.0 [...]
semodule الإعدادات الجديدة فوراً ما لم تستخدم معه الخيار -n. يجدر بالملاحظة أن البرنامج يُعدِّل افتراضياً على الإعدادات الحالية (التي يشير لها المتغير SELINUXTYPE في /etc/selinux/config)، لكن يمكنك جعله يعدل على إعداد آخر عبر استخدام الخيار -s.
semanage.
-a للإضافة، -d للحذف، -m للتعديل، -l للعرض، و -t لذكر النوع (أو النطاق).
semanage login -l التقابلات الحالية بين هويات المستخدمين وهويات SELinux. يحصل المستخدمون الذين ليس لهم مدخلة تقابل صريحة على الهوية المذكورة في المدخلة __default__. يربط الأمر semanage login -a -s user_u user المستخدم المحدد بالهويّة user_u. وأخيراً، يُسقِط semanage login -d user مدخلة التقابل المسندة للمستخدم.
#semanage login -a -s user_u rhertzog#semanage login -lLogin Name SELinux User MLS/MCS Range Service __default__ unconfined_u SystemLow-SystemHigh * rhertzog user_u SystemLow * root unconfined_u SystemLow-SystemHigh * system_u system_u SystemLow-SystemHigh * #semanage login -d rhertzog
semanage user -l التقابلات بين هويات المستخدمين في SELinux والأدوار المسموحة. تحتاج إضافة هوية جديدة إلى تعريف الأدوار الموافقة لها بالإضافة لتعريف سابقة الوسم التي تستخدم لتعيين أنواع الملفات الشخصية (/home/user/*). إما أن تكون قيمة هذه السابقة user أو staff أو sysadm. استخدام السابقة ”staff“ ينتج ملفات لهذا النوع ”staff_home_dir_t“. تنشأ هويات SELinux الجديدة باستخدام semanage user -a -R roles -P prefix identity. أخيراً، يمكنك إزالة هوية مستخدم SELinux باستخدام semanage user -d identity.
#semanage user -a -R 'staff_r user_r' -P staff test_u#semanage user -lLabeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm SystemLow SystemLow-SystemHigh staff_r sysadm_r system_r staff_u staff SystemLow SystemLow-SystemHigh staff_r sysadm_r sysadm_u sysadm SystemLow SystemLow-SystemHigh sysadm_r system_u user SystemLow SystemLow-SystemHigh system_r test_u staff SystemLow SystemLow staff_r user_r unconfined_u unconfined SystemLow SystemLow-SystemHigh system_r unconfined_r user_u user SystemLow SystemLow user_r #semanage user -d test_u
/srv/www/، عليك تنفيذ semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" يتبعه restorecon -R /srv/www/. يسجل الأمر الأول قواعد الوسم الجديدة ويعيد الأمر الثاني ضبط أنواع الملفات وفق قواعد الوسم الجديدة هذه.
semanage port -m -t http_port_t -p tcp 8080.
getsebool لفحص هذه الخيارات (يعرض الأمر getsebool boolean خياراً واحداً، أما getsebool -a فيعرضها كلها). يغيّر الأمر setsebool boolean value القيمة الحالية للخيار البولياني. استخدام الخيار -P يجعل التغيير نهائياً، أي أن القيمة الجديدة ستصبح القيمة الافتراضية وسيحتفظ بها بعد إعادة الإقلاع. يمنح المثال التالي مخدمات الوب صلاحية الوصول لمجلدات بيوت المستخدمين (يفيد هذا عندما يملك المستخدمون مواقع شخصية في ~/public_html/).
#getsebool httpd_enable_homedirshttpd_enable_homedirs --> off #setsebool -P httpd_enable_homedirs on#getsebool httpd_enable_homedirshttpd_enable_homedirs --> on
/usr/share/doc/selinux-policy-doc/html/) وملفات أمثلة يمكن استخدامها كقوالب لإنشاء الوحدات الجديدة. ثَبِّت هذه الملفات وادرسها بعمق:
$cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile$cp /usr/share/doc/selinux-policy-doc/example.fc ./$cp /usr/share/doc/selinux-policy-doc/example.if ./$cp /usr/share/doc/selinux-policy-doc/example.te ./
.te هو الأهم بينها. فهو الذي يحدد القواعد. يُعرِّف الملف .fc ”سياقات الملفات“، وهي الأنواع التي تسند إلى الملفات المرتبطة بهذه الوحدة. تُستَخدَم البيانات من الملف .fc أثناء مرحلة وسم الملفات. أخيراً، يُعرِّف الملف .if واجهة الوحدة: وهي مجموعة من ”الدوال العامة“ التي تستطيع الوحدات الأخرى استخدامها للتفاعل مع هذه الوحدة الجديدة بشكل سليم.
myapp_domtrans“) بمن يستطيع تنفيذ التطبيق. أما الثانية (”myapp_read_log“) فتمنح صلاحيات القراءة على ملفات سجلات التطبيق.
.te. عليك إذن التصريح عن جميع الأنواع التي تستخدمها (باستخدام الماكرو gen_require)، واستخدام التعليمات التوجيهية القياسية لمنح الصلاحيات. لاحظ، على أي حال، أنك تستطيع استخدام الواجهات التي توفرها الوحدات الأخرى. يتفصّل القسم التالي أكثر في شرح طريقة تمثيل هذه الصلاحيات.
مثال 14.3. ملف example.if
## <summary>Myapp example policy</summary>
## <desc>
## <p>
## More descriptive text about myapp. The <desc>
## tag can also use <p>, <ul>, and <ol>
## html tags for formatting.
## </p>
## <p>
## This policy supports the following myapp features:
## <ul>
## <li>Feature A</li>
## <li>Feature B</li>
## <li>Feature C</li>
## </ul>
## </p>
## </desc>
#
########################################
## <summary>
## Execute a domain transition to run myapp.
## </summary>
## <param name="domain">
## Domain allowed to transition.
## </param>
#
interface(`myapp_domtrans',`
gen_require(`
type myapp_t, myapp_exec_t;
')
domtrans_pattern($1,myapp_exec_t,myapp_t)
')
########################################
## <summary>
## Read myapp log files.
## </summary>
## <param name="domain">
## Domain allowed to read the log files.
## </param>
#
interface(`myapp_read_log',`
gen_require(`
type myapp_log_t;
')
logging_search_logs($1)
allow $1 myapp_log_t:file r_file_perms;
')
example.te:
policy_module(myapp,1.0.0)######################################## # # Declarations # type myapp_t;
type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t)
type myapp_log_t; logging_log_file(myapp_log_t)
type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms };
allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)
|
يجب تعريف الوحدة باسمها ورقم إصدارها. هذه التعليمة إلزامية.
|
|
إذا كانت الوحدة تُعرّف أنواعاً جديدة، فعليها التصريح عنها باستخدام تعليمات كهذه. لا تتردد في إنشاء أنواع كثيرة بقدر الحاجة بدلاً من منح صلاحيات عديمة الجدوى.
|
|
تُعرّف هذه الواجهات النوع myapp_t كنطاق للعمليات الذي يجب استخدامه مع أي ملف تنفيذي موسوم بالنوع myapp_exec_t. ضمنياً، هذا يضيف الصفة exec_type إلى هذه الكائنات، التي تسمح بدورها للوحدات الأخرى بمنح صلاحيات تنفيذ هذه البرامج: مثلاً، تسمح الوحدة userdomain للعمليات ذات النطاقات user_t، و staff_t، و sysadm_t بتنفيذها. أما نطاقات البرمجيات المقيّدة الأخرى فلا تملك صلاحيات تنفيذها، إلا إذا منحتها القواعد صلاحيات مشابهة (هذه هي حالة dpkg ونطاقه dpkg_t، على سبيل المثال).
|
| logging_log_file هي واجهة تقدمها السياسة المرجعية. وهي تدل أن الملفات الموسومة بهذا النوع المحدد هي ملفات سجلات ويجب أن تستفيد من القواعد المختصة بالسجلات (مثلاً منح الصلاحيات لبرنامج logrotate بحيث يستطيع معالجتها).
|
|
تعليمة allow هي التعليمة الأساسية المستخدمة للسماح بتنفيذ إجراء. المتغير الأول هو نطاق العملية المخولة بتنفيذ الإجراء. أما المتغير الثاني فهو يُعرّف الكائنات التي سيسمح للعمليات من النطاق السابق بالتعديل عليها. صيغة هذا المتغير هي ”type:class“ حيث type هو النوع في SELinux ويحدد الصنف class طبيعة الكائن (ملف، مجلد، مقبس شبكي، fifo، الخ). أخيراً، يحدد المتغير الأخير الصلاحيات (الإجراءات المسموحة).
تُعرّف الصلاحيات بشكل مجموعة من الإجراءات المسموحة وهي تتبع هذا القالب: { operation1 operation2 }. لكن يمكنك أيضاً استخدام ماكروات تعبر عن الصلاحيات التي تفيدك. يسرد الملف /usr/share/selinux/devel/include/support/obj_perm_sets.spt الماكروات المتاحة.
تقدم صفحة الوب التالية قائمة شاملة نسبياً لأصناف الكائنات، والصلاحيات التي يمكن منحها.
|
avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1جدول 14.1. تحليل أثر SELinux
| الرسالة | الوصف |
|---|---|
avc: denied | هذا الإجراء قد مُنع. |
{ read write } | يحتاج هذا الإجراء لصلاحيات read و write. |
pid=1876 | نفّذت العملية ذات PID رقم 1876 الإجراء (أو حاولت تنفيذه). |
comm="syslogd" | كانت العملية تنفذ البرنامج syslogd. |
name="xconsole" | العنصر المستهدف اسمه xconsole. أحياناً قد يعطيك متغير ”path“ —يحوي المسار الكامل— بدلاً من هذا. |
dev=tmpfs | الجهاز الذي يستضيف الكائن الهدف هو tmpfs (نظام ملفات في الذاكرة). بالنسبة للأقراص الحقيقية، يمكن أن ترى القسم الذي يستضيف الكائن (مثلاً: ”sda3“). |
ino=5510 | الكائن مُعرّف برقم inode يساوي 5510. |
scontext=system_u:system_r:syslogd_t:s0 | هذا هو السياق الأمني للعملية التي نفّذت الإجراء. |
tcontext=system_u:object_r:device_t:s0 | هذا هو السياق الأمني للكائن الهدف. |
tclass=fifo_file | الكائن الهدف هو ملف FIFO. |
allow syslogd_t device_t:fifo_file { read write }. يمكن أتمتة هذه العملية، وهذا بالضبط ما يُقدِّمه الأمر audit2allow (من الحزمة policycoreutils). يفيد هذا الأسلوب فقط إذا كانت الكائنات المختلفة موسومة مسبقاً بشكل صحيح وفقاً للعملية التي يجب تقييدها. في جميع الحالات، عليك مراجعة القواعد المولدة بحذر والتحقق من صحتها على حسب معرفتك بالتطبيق. في الواقع، تميل هذه الطريقة لمنح صلاحيات أكثر مما يلزم فعلاً. الحل الأنسب غالباً هو إنشاء أنواع جديدة ومنح الصلاحيات على هذه الأنواع فقط. كما قد تصادفك أيضاً إجراءات لا يكون حظرها مصيرياً بالنسبة للتطبيق، وفي تلك الحالة قد تكون إضافة ”dontaudit“ فقط لتفادي تسجيل مدخلة في السجل رغم حظر الإجراء أفضل.
example.if، وexample.fc، وexample.te) مع القواعد الجديدة التي تريدها، يكفي استدعاء make NAME=devel لتوليد وحدة بالاسم example.pp (يمكنك تحميلها فوراً باستخدام semodule -i example.pp). إذا عَرَّفت عدة وحدات، سوف ينشئ make جميع ملفات .pp الموافقة لها.