بعد إسقاط الصلاحيات: أي ملفات OpenVPN ما زالت تعمل؟
الواصفات التي فُتحت قبل الإسقاط تستمر في العمل، أما المسارات التي تُعاد فتحها لاحقًا فلا. حدد أيًا من ملفات التشغيل الثلاثة يحتاج إعدادك إلى إعادة فتحه.
لا يثبت طول مدة التشغيل إلا أن الإقلاع نجح بالصلاحيات التي كانت لدى الخدمة في تلك اللحظة. أما الأعطال المهمة هنا فتأتي لاحقًا: عميل جديد يتصل، وقائمة إبطال تُستبدل، وأداة مساعدة تحتاج إلى كتابة ملف. كل واحد من هذه حدث فتح جديد ينفذه الحساب غير المميز، وله سؤال أذونات خاص به ورسالة خطأ خاصة به. ثلاثة قرارات تفصل إعدادًا يستمر في العمل عن إعداد يفشل عند الحدث التالي.
افصل ما حُمل مبكرًا عما يُفتح لاحقًا
الواصف مقبض على وصف ملف مفتوح، وقد ثُبت نمط الوصول عند إنشاء ذلك الوصف. تغيير مستخدم العملية لاحقًا لا يغلق المقبض، ولهذا يستمر ملف المفتاح الذي قُرئ بصلاحية الجذر في العمل بعد الإسقاط. والنمط لا يتغير أيضًا: المقبض المفتوح للقراءة لا يصبح قابلًا للكتابة، والمقبض القابل للكتابة لا يُسحب لمجرد أن الحساب فقد حقوقه على المسار. هاتان الحقيقتان تفسران معظم السلوك المفاجئ في هذه التقارير.
النصف الآخر هو الذاكرة. يمكن للخدمة أن تحلل شهادة وتحتفظ بالمادة المحللة وتغلق الملف، فما يبقى قيد الاستخدام بيانات لا ملف مفتوح. لذا فإن استمرار حركة المرور لا يثبت أن واصفًا مفتوح، ولا أن اسم المسار يمكن الوصول إليه. إنه يثبت فقط أن المادة اللازمة للجلسة الحالية حُصل عليها في وقت سابق.
الفتح اللاحق معاملة مختلفة. يجري تحت بيانات الاعتماد الحالية والسياق الأمني الحالي ومنظور التركيب الحالي، لذا قد يُرفض عند الاتصال التالي مسار كان مقروءًا عند الإقلاع. والتدوير يضيف فخًا: كتابة ملف جديد فوق اسم المسار نفسه تُبقي واصفًا قائمًا مرتبطًا بالكائن القديم، فيبدو إعادة التحميل ناجحًا بينما ما زالت الخدمة تستخدم المحتوى السابق. قارن الـ inode الذي تحتفظ به العملية بالـ inode على القرص قبل أن تصدق أن التدوير نُفذ.
سمِّ القراءات الثلاث وقت التشغيل ومتى تقع كل واحدة
ثلاثة موارد تُفتح عادة بعد التهيئة بوقت طويل، وتفشل في لحظات مختلفة. ملف تهيئة خاص بعميل يُقرأ عندما يتصل ذلك العميل تحديدًا، لذا قد ينكسر لمستخدم واحد بينما يستمر الآخرون. تُستشار بيانات الإبطال أثناء مصادقة الأقران ومرة أخرى عند استبدال الملف. أما المجلد المؤقت فلا يُلمس إلا عندما تكتب أداة أو إضافة شيئًا.
لا ينتمي أي من الثلاثة إلى مسار الإقلاع، ولهذا قد يفشل خادم ظل سليمًا لأسابيع عند الاتصال التالي. والفئة تحدد أيضًا صاحب الإصلاح: الأولان إذن قراءة على التهيئة تحت حساب الخدمة، والثالث موقع قابل للكتابة بغرض ضيق.
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key يجيب عن سؤال أضيق مما يفترض معظم الناس. إنه يبقي ملف المفتاح مفتوحًا عبر عمليات إعادة الضبط الموثقة لـ SIGUSR1 و ping-restart، ولا يفعل شيئًا لملفات CCD أو بيانات الإبطال أو الملفات التنفيذية المساعدة أو إعادة تشغيل العملية بالكامل. تلك ما زالت تتبع مسارات فتحها الخاصة، تحت الحساب الذي يعمل في تلك اللحظة.
أثبت الحساب والمنظور الذي يملكه فعلًا
اسأل الخدمة العاملة أي حساب تستخدم بدلًا من الوثوق بملف الوحدة، ثم قارن الجواب بما تضبطه الوحدة. عدم التطابق هو أول ما يجب حله، لأن كل فحص أذونات لاحق يجري بصفة من تكون العملية فعلًا. ثم امش في المسار مكونًا بعد مكون؛ فالعبور يُقيَّم في كل مستوى، لذا يبقى الملف المقروء داخل مجلد غير قابل للعبور غير مقروء. نمط الملف النهائي هو السؤال الأخير لا الأول.
تضيف النطاقات وصناديق الخدمة حدودًا لا تصفها الملكية وبتات النمط. المسار الظاهر في صدفتك قد يكون غائبًا أو للقراءة فقط داخل chroot أو نطاق تركيب أو وحدة تخفي مجلدات المنزل. وتضيف وحدات الأمان طبقة أخرى، فقد يُرفض عند الفتح ملف يبدو مقروءًا.
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceالقراءة الناجحة في صدفة المدير لا تختبر أيًا من تلك الشروط المجتمعة. شغل الفحص بحساب الخدمة، بالنطاق والصندوق نفسيهما، أو اقبل أن النتيجة تصف صدفتك لا الخادم. الأمر الثالث هو النسخة الرخيصة من ذلك الاختبار: يطبع نمط كل مكون ويفشل عند أول مكون لا يستطيع حساب الخدمة عبوره.
امنح الكتابة وقت التشغيل مجلدًا خاصًا بها
القراءة نصف الجرد فقط. قد تحتاج أداة مساعدة إلى إنشاء ملف حالة، وقد تحتاج إضافة إلى كتابة حالة بجانب تهيئتها، وهذه الكتابات لا يغطيها جعل شجرة التهيئة قابلة للكتابة. امنح المجلد المحدد إذن الكتابة الذي تحتاجه وظيفته، بمالك ونمط تستطيع تفسيرهما. فضّل الوصول للقراءة فقط لكل ما يُقرأ فقط.
أبق أذونات المفتاح الخاص منفصلة عن ملفات السياسة. المفتاح الذي يجب إعادة قراءته بعد إعادة ضبط له متطلب مختلف عن ملف عميل يُقرأ عند كل اتصال، ونمط متساهل واحد للاثنين يمنح وصولًا أكثر مما تطلبه المشكلة. حساب خدمة مخصص بملكية ضيقة أسهل في التدقيق من مجموعة واسعة. وعندما يجب أن يصمد المفتاح عبر إعادات الضبط، persist-key يزيل إعادة القراءة بدلًا من توسيع المجلد.
احسم القرار من الحدث الذي يمكنك إعادة إنتاجه
نفق حي يثبت مسارًا واحدًا في الشيفرة. الحدث الذي يحتاج الملف هو الاختبار الوحيد الذي يغطي الفتح الذي يهمك، سواء كان اتصال عميل جديد أو ملف إبطال بديلًا أو إعادة ضبط لينة مسموحة أو إعادة تشغيل مخططة. اختر الحدث وشغّله واحتفظ بالخطأ الأول لا الأخير.
في إعادة الضبط اللينة، تُظهر إشارة واحدة وسجل الوحدة ما إذا كان المفتاح قد قُرئ مرة أخرى. أرسل الإشارة ثم اقرأ الأسطر الأخيرة التي كتبتها الوحدة:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerلا تستنتج أن خدمة مخترقة لم تعد قادرة على تعديل الملفات لمجرد إسقاط الصلاحيات. ما تستطيعه بعد يعتمد على بيانات اعتمادها المتبقية وقدراتها والمجلدات التي تستطيع الكتابة فيها وأي واصف قابل للكتابة ما زال بيدها. تقليص الصلاحيات يضيق السلطة، وجرد عمليات الفتح وقت التشغيل هو ما يبين مدى ذلك. اكتب هذا الحد بجانب التهيئة حتى لا يضطر الشخص التالي إلى اكتشافه من جديد.