مصادقة PAM تعمل يدويًا لكنها تفشل كخدمة OpenVPN
تسجيل دخول PAM يعمل من صدفة الجذر ويفشل تحت systemd يشير إلى المساعد، لا إلى كلمة المرور. افصل الصلاحيات والوصول إلى الملفات وSELinux.
يمكن أن تنجح المصادقة عبر PAM عندما تشغّل العميل يدويًا، وتفشل بـ AUTH_FAILED بمجرد أن يبدأ systemd الملف الشخصي نفسه. لا تتغير كلمة المرور بين هاتين المحاولتين؛ الذي يتغير هو مجموعة القيود المحيطة بالعملية التي تسأل PAM السؤال. تُجيب PAM عبر مساعد، والقدرة على تغيير بيانات اعتماده الخاصة هي بالضبط ما تزيله وحدة مُحصّنة. اعثر على ذلك المساعد والحد الذي يحتاجه قبل أن تلمس قائمة القدرات.
unix_chkpwd هو الملف الثنائي الذي يجيب على سؤال PAM
مع المصادقة بكلمة المرور المحلية، نادرًا ما يقرأ pam_unix ملف التجزئة بنفسه. إنه ينفّذ unix_chkpwd، الذي تثبّته التوزيعات بـ setuid root أو setgid shadow كي يمكن التحقق من كلمة مرور واحدة نيابةً عن عملية ليس من شأنها قراءة /etc/shadow. أزل القدرة على اكتساب تلك الهوية ولن يتمكن المساعد من إتمام التحقق، فتُرجع الوحدة فشل مصادقة عاديًا.
يبدو الفشل بعد ذلك كمشكلة بيانات اعتماد في كل سجل يمكن للعميل رؤيته. هذا هو الفخ: يبلّغ العميل بما قالته له PAM، وتبلّغ PAM فقط أن الحزمة قالت لا. تشغيل المساعد يدويًا كجذر لا يثبت شيئًا أيضًا، لأنه يمارس مسار صلاحيات لا تستخدمه الخدمة أبدًا. اقرأ الوحدة التي حمّلها systemd فعليًا، ثم اقرأ سجل النظام للمحاولة التي أجراها. هذان العرضان يفصلان مشكلة العزل عن مشكلة كلمة مرور خاطئة.
اقرأ الوحدة قبل أن تقرأ سجل كلمات المرور
قد تحمل وحدة مُحزَّمة ملف drop-in لم تكتبه أنت، والتكوين الفعلي هو النتيجة المدمجة. اطبع الوحدة كما يراها systemd، مع إعدادات العزل التي تحدد ما إذا كان المساعد يستطيع رفع صلاحياته. الفحص للقراءة فقط كافٍ في هذه المرحلة.
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -bيُظهر الأمر الأول من أين تأتي الوحدة وdrop-ins الخاصة بها، وهذا مهم لأن تجاوزًا أُضيف قبل أشهر يبقى أطول من ذاكرة سبب وجوده. ويطبع الثاني قيم العزل التي يعتمد عليها القسمان التاليان.
قارن ما تراه بمضيف عامل من التوزيع والإصدار نفسيهما. الاختلاف في User أو CapabilityBoundingSet أو NoNewPrivileges دليل ملموس؛ أما الاختلاف في تعليقات النثر فليس كذلك. اكتب القيم قبل تغيير أي شيء، لأن مقارنة لاحقة بهدف متحرك لا تثبت شيئًا. إذا كانت الخدمة تعمل بحساب غير مميز بمجموعة bounding فارغة، فليس لدى المساعد تقريبًا ما يعمل به.
تحويل بيانات الاعتماد والوصول إلى الملفات والسياسة ثلاث حدود
ابدأ بما يحدث أثناء exec. إن ملفًا ثنائيًا setuid أو ملفًا يحمل قدرات ملفات يحرّض على تحويل بيانات الاعتماد، فالهوية الناتجة ليست استمرارًا للمتصل. تحدد مجموعة bounding ما يجوز لمثل هذا الملف اكتسابه، و NoNewPrivileges يمنع مكاسب setuid وsetgid وقدرات الملفات منعًا باتًا. أي واحد من هذه الثلاثة يمكنه إيقاف المساعد مع إبقاء كل وظيفة خدمة أخرى سليمة.
بعد ذلك، افصل التجاوز التقديري الواسع عن الوصول الضيق للقراءة. CAP_DAC_OVERRIDE يتخطى الفحوص التقديرية في كل مكان تقريبًا، بينما CAP_DAC_READ_SEARCH يغطي القراءة واجتياز الأدلة مع صلاحيات إضافية خاصة به. إنهما أداتان مختلفتان بنطاقي تأثير مختلفين، وليس أي منهما تهجئة لعبارة دع PAM يقرأ ملف shadow.
أخيرًا، اسأل هل تسمح السياسة الإلزامية بالإجراء أصلًا. قدرة Linux لا تتجاوز SELinux، وحيازتها لا تثبت شيئًا عن قاعدة فرض النوع. تعامل مع رفض الوصول إلى الملف ورفض القدرة كدليلين مختلفين، لأنهما يسمّيان إصلاحين مختلفين وغالبًا مالكين مختلفين. اقرأ كل حقل في السجل بدلًا من الكلمة الواحدة denied. أي ملف تنفيذي قام بالإجراء، وفي أي نطاق عمل، وأي نوع من الأهداف لمس، وأي فئة من الكائنات كانت معنية، وأي إذن رفضته السياسة: كل ذلك يضيّق الإجابة بطريقة مختلفة.
استخرج الرفض من سجل التدقيق
على مضيف في وضع الفرض، سجل التدقيق هو المكان الوحيد الذي يسجل الرفض. استعلم عن الأحداث الأخيرة واقرأها مقابل الطابع الزمني لتسجيل الدخول الفاشل، لا مقابل وقت بدء تحقيقك.
ausearch -m AVC,USER_AVC -ts recentالنتيجة الفارغة ليست دليلًا على البراءة. إنها تعني إما أن التدقيق لا يجمع، أو أن نافذتك أفلتت المحاولة، ويجب استبعاد الاحتمالين قبل أن تستبعد السياسة.
يضع إرشاد استكشاف أخطاء SELinux من Red Hat فحوص التسمية والتكوين قبل توليد قواعد السماح، وهو الترتيب الصحيح لهذه المشكلة أيضًا. الملف المساعد خاطئ التسمية وثغرة السياسة ينتجان رفضًا مشابهًا لكنهما يحتاجان إصلاحين مختلفين. توليد قاعدة سماح لخطأ تسمية يخفي العيب ويترك تحديث الحزمة التالي يعيده. أكّد التسمية على المساعد المثبَّت قبل كتابة أي سياسة.
أثبت التغيير بتسجيل دخول مقبول وآخر مرفوض
غيّر فقط الحد الذي أثبتته، ثم اختبر النتيجتين. حساب يجب أن يصادق يجب أن ينجح، وحساب بكلمة مرور خاطئة يجب أن يفشل مع ذلك. التغيير الذي يجعل كل محاولة تنجح أزال المصادقة بدلًا من إصلاحها.
أجرِ محاولة اتصال حقيقية واقرأ السجل فورًا بعدها. السطر الذي يثبت الإصلاح هو إدخال pam_unix(openvpn:auth) لتلك المحاولة: يجب أن يقرأ نجاح المصادقة، ولا يجب أن يحمل أي سجل AVC الثانية نفسها.
journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpnيحتاج النفق العامل إلى إعادة اتصال أيضًا، لأن تغييرات العزل تكسر الاتصال الثاني أكثر من الأول في كثير من الأحيان. افحص المقبس المنشأ بعد إعادة الاتصال وتأكد من أن الوحدة نفسها لا تزال تخدمه.