لا تجمع تقوية systemd مع إسقاط صلاحيات OpenVPN

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

طريقتان، ومالك واحد للتبديل

الطريقة الأولى تنتمي إلى الخدمة نفسها. إعدادات النسخة المجتمعية من OpenVPN لكل من user و group تغيّر الهوية بعد إعداد النفق والمفاتيح، و persist-key مع persist-tun تُبقي تلك الموارد قابلة للاستخدام بعد ذلك.

الطريقة الثانية تنتمي إلى مدير الخدمة. إعداد User= أو Group= في systemd يحدّد الهوية التي تبدأ العملية تحتها، وتوجيهات القدرات تحدّد ما يجوز لها الاحتفاظ به. والاختيار بين الطريقتين مسألة تغليف قبل أن تكون مسألة أمنية، وقد أجاب عنها مشرف الحزمة سلفًا. مهمتك أن تجد تلك الإجابة لا أن تخترع خيارًا ثالثًا.

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

حدّد أين تتغير الهوية

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

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

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

القدرات حدود لا منح

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

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

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

ارسم خريطة السلطة عبر دورة الحياة

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

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

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

الميزات التي تغيّر الحمل المحلي، مثل تفريغ قناة البيانات أو بناء يرتبط بطريقة مختلفة، قد تغيّر العمليات المطلوبة. راجع الخريطة عند تغيّر الحزمة، لا عند تعطّل شيء فقط.

دوّن الخطة واحتفظ بوصول للاستعادة

سجل النشر يجب أن يسمّي المدير وهوية بدء التشغيل والهوية المستقرة المقصودة وكل منحة مع العملية التي تتطلبها. ذلك السجل هو ما يجعل التغيير التالي قابلًا للمراجعة بدل أن يكون تجربة.

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

النجاح دورة حياة مفهومة بأدنى سلطة، لا عملية تصادف أنها تعمل باسم غير جذر.