الجذر في الطرفية، مرفوض تحت SELinux: لماذا يفشل الخطاف

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

الأمر نفسه، نطاقان أمنيان مختلفان

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

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

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

اقرأ سجل AVC بجوار خطأ الخطاف

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

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

ينبغي أن يطابق سياق المصدر النطاق الذي تعمل فيه الخدمة فعليًا، وينبغي أن يطابق سياق الهدف سم الملف أو الدليل الذي لمسته العملية. إذا لم يتوافق أي منهما مع الخطأ الذي تتبعه، فأنت تقرأ حدثًا آخر.

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

السم أو التكوين أو السياسة: ثلاثة إصلاحات

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

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

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

لماذا لا تكون وحدة السماح القديمة هي الجواب

نتائج البحث عن هذا العطل مليئة بوحدات جاهزة، غالبًا لأداة لم يعد الخطاف يستدعيها. تثبيت واحدة يمنح أذونات قد لا علاقة لها برفضك، ويترك عدم التطابق الحقيقي في مكانه بينما يضيف ثغرة دائمة.

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

المقارنة المنضبطة تكون بين الرفض الذي يمكنك قراءته والتغيير الذي تقترحه. إن إرشادات استكشاف أخطاء SELinux وإصلاحها من Red Hat تضع فحوص الوسم والتكوين قبل السياسة المولّدة لهذا السبب بالتحديد. إذا لم يكن هناك رفض مقابل في السجل، فمن المحتمل ألا تكون SELinux مشكلتك، و مشكلات المسار أو العزل أو الأذونات لا تزال قائمة.