لماذا يؤدي نقل شهادة VPN إلى كسر تسمية SELinux

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

ما تفعله إعادة التسمية بالتسمية فعليًا

يحمل الملف سياق SELinux الخاص به كبيانات سمات مرتبطة بالـ inode. تغيير الاسم داخل نظام ملفات واحد يغيّر مدخل المجلد ولا شيء آخر، وهذا سريع وذري، وهو سبب بقاء السياق بعد النقل. لا تُستشار أي سياسة، ولا يُطبَّق أي افتراضي، ولا تُطبع أي تحذيرات.

النسخ يتصرف بشكل مختلف. تُنشئ النسخة inode جديدًا في مجلد الوجهة، وتخصّص السياسة سياقًا من نوع ذلك المجلد، لذا ينتهي الملف المنسوخ عادةً بتسمية صحيحة بينما يبقى المنقول خاطئًا. هذا الفرق الوحيد يفسر معظم الالتباس في هذه الفئة من التذاكر.

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

اقرأ التسمية الحالية مقابل التسمية المتوقعة

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

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

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

استعد التعيين بدلًا من اختراع استثناء

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

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

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

لماذا لا يمثل chcon الحل

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

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

عندما تكون التسمية صحيحة ويظل الوصول فاشلًا

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

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

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