كيف تشغّل الخدمات دون صلاحيات root؟

لماذا لا تشغّل كل شيء بصلاحيات root؟

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

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

حساب مخصص لكل خدمة

النهج التقليدي هو إنشاء مستخدم نظام منفصل لكل خدمة، بحيث يملك ملفات تلك الخدمة فقط ولا يمكنه تسجيل الدخول. قد يبدو حساب النظام الخاص بتطبيق ويب كما يلي:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin appsvc

كل خيار مهم. يجعل --system الحساب حساب خدمة، وليس حساباً لتسجيل دخول مستخدم بشري. يتجاوز --no-create-home إنشاء الدليل الرئيسي الذي لا يحتاج إليه. ويعني --shell /usr/sbin/nologin أنه حتى إذا تمكّن مهاجم بطريقة ما من الاستيلاء على الحساب، فلن يستطيع فتح shell باستخدامه. يوجد الحساب فقط لامتلاك عملية وملفاتها.

بعد ذلك، امنح هذا المستخدم الملفات التي يحتاج إليها فقط، ولا تمنحه غير ذلك:

sudo chown -R appsvc:appsvc /opt/myapp

تقرأ الخدمة الآن من دليلها الخاص وتكتب فيه، ولا تكون لها حاجة إلى أي مكان آخر على القرص. وإذا استُغلت الخدمة، تقتصر الملفات التي يستطيع المهاجم تغييرها على /opt/myapp؛ ولا يزال بإمكان الحساب قراءة أي ملف متاح للقراءة العامة، لكنه لا يستطيع تعديل بقية النظام.

دع systemd يشغّله بهذا الحساب

بعد إنشاء الحساب، اطلب من systemd تشغيل الخدمة باستخدامه. يكفي سطر واحد في ملف الوحدة:

[Service]
ExecStart=/opt/myapp/bin/server
User=appsvc
Group=appsvc

يعني User=appsvc أن العملية تبدأ بامتيازات الحساب المحدودة بدلاً من امتيازات root. هذه هي الطريقة المعتادة والصحيحة لتشغيل تطبيق باستخدام systemd، ومن المفيد تطبيقها على كل خدمة تنشئ لها ملف وحدة. لكن خفض الامتيازات لن يفيد إذا كان systemd يراقب العملية الخطأ. لذلك، إذا استمرت الوحدة في الإبلاغ عن أنها نشطة بعد خروج البرنامج الخفي بهدوء، فتحقق من أنك اخترت Type= الصحيح لطريقة بدء العملية.

أو تجاوز الحساب بالكامل باستخدام DynamicUser

يمكن لـsystemd اتخاذ خطوة إضافية وإنشاء مستخدم مؤقت لك، بحيث لا يكون موجوداً إلا أثناء تشغيل الخدمة. عيّن DynamicUser=yes، ولن تحتاج إلى إدارة أي حساب:

[Service]
ExecStart=/opt/myapp/bin/server
DynamicUser=yes
StateDirectory=myapp

عند البدء، يخصّص systemd معرّف مستخدم غير مستخدم؛ وعند التوقف، يحرّره. تحصل الخدمة أيضاً على /tmp خاص، وعرض للقراءة فقط لمعظم نظام الملفات، ودليل حالة قابل للكتابة ضمن /var/lib/myapp، ويُنشئه StateDirectory= ويمنحه للخدمة. لم يكن أي من ذلك ممكناً في SysV init، حيث كان خفض الصلاحيات متروكاً لما ينفذه برنامج start النصي الخاص بكل خدمة. وكان هذا القصور سبباً كبيراً في انتقال التوزيعات إلى systemd منذ البداية. بالنسبة إلى خدمة مستقلة لا تحتاج إلا إلى دليل الحالة الخاص بها، يُعد DynamicUser=yes أسهل طريقة للحصول على عزل قوي، لأنّه لا يوجد حساب دائم يمكن للمهاجم استهدافه أصلاً.

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

كيف ينسجم ذلك مع بقية الإجراءات

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

قبل المتابعة، راجع قائمة تقوية شاملة للخادم كله، وأنشئ نسخة مخصصة تعمل انطلاقاً منها:

FAQ

لماذا يجب ألا أشغّل خدمة بصفة root؟

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

كيف أنشئ مستخدماً لا يستطيع تسجيل الدخول؟

شغّل sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME. تعني shell ‏nologin أن الحساب لا يستطيع فتح جلسة تفاعلية حتى إذا سُرقت بيانات اعتماده، ويضع --system علامة عليه بوصفه حساب خدمة، بينما يتجاوز --no-create-home إنشاء دليل home لا يحتاج إليه. امنحه ملكية ملفاته الخاصة فقط باستخدام chown.

ما هو DynamicUser في systemd؟

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

هل يغني التشغيل كمستخدم غير root عن جدار الحماية؟

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

ما الملفات التي يجب أن يملكها مستخدم الخدمة؟

الملفات التي تحتاج إليها الخدمة فعلياً فقط، ولا شيء أكثر. امنح الحساب ملكية دليل العمل والبيانات الخاصة به، واترك كل ما عدا ذلك مملوكاً لـroot. النمط الجيد هو sudo chown -R svc-app:svc-app /opt/svc-app لدليل التطبيق، بينما تظل ملفات الإعداد ضمن /etc مملوكة لـroot ولا يستطيع الخدمة قراءتها إلا. الهدف هو أنه إذا تم اختراق العملية، تقتصر الملفات التي يمكنها تغييرها على بياناتها الخاصة، لا على بقية النظام.