ما هو sudo ولماذا نستخدمه؟ دليل عملي لفهم الصلاحيات في لينكس

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

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

نظرة سريعة: خريطة sudo في سطر

الجدول التالي يلخص جوهر sudo في محاوره الأساسية، قبل الدخول في التفاصيل:

ما هو sudo بالضبط؟

sudo اختصار لـ “superuser do” أو “substitute user do”. هو برنامج يسمح لمستخدم عادي بتنفيذ أمر محدد بصلاحيات مستخدم آخر — افتراضيًا root — وفق قواعد محددة مسبقًا. الفكرة ليست منح صلاحيات كاملة، بل منح صلاحية مؤقتة ومحددة لتنفيذ مهمة معينة، ثم العودة إلى الوضع العادي.

عندما تكتب sudo apt install nginx، لا تتحول إلى root. أنت تطلب من sudo أن تنفّذ أمر apt install nginx بصلاحيات root، ثم تنتهي العلاقة. العملية التي تبدأها sudo تعمل بصلاحيات مرتفعة، لكن جلستك أنت تبقى كمستخدم عادي. هذا الفرق الجوهري بين sudo و“أن تصبح root”.

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

لماذا لا نسجل الدخول كـ root مباشرة؟

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

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

كيف يعمل sudo داخليًا؟ setuid وsudoers

الآلية التي تجعل sudo قادرًا على منح الصلاحيات هي setuid bit. ملف sudo التنفيذي مملوك لـroot وموسوم بـsetuid، ما يعني أن أي مستخدم يشغّله يحصل على صلاحيات مالك الملف (root) أثناء تنفيذه. هذا هو الأساس التقني الذي يسمح للمستخدم العادي ببدء عملية sudo التي تعمل بصلاحيات root.

لكن sudo لا تمنح الصلاحيات تلقائيًا. إنها تقرأ ملف /etc/sudoers، وتتحقق من:

• هل هذا المستخدم موجود في أي قاعدة تسمح له؟
• هل الأمر المطلوب ضمن الأوامر المسموحة له؟
• هل يحتاج إلى كلمة مرور؟ (بعض القواعد تسمح بـNOPASSWD)
• هل هناك قيود على الوقت أو الجهاز؟

إذا نجح التحقق، تنفّذ sudo الأمر بصلاحيات root، ثم تعيد التحكم للمستخدم. وإذا فشل، ترفض الطلب وترمي “user is not in the sudoers file”.

sudo مقابل su: الفرق الذي يحدد الأمان

كثير من المبتدئين يخلطون بين sudo و su. الفرق ليس شكليًا:

sudo أكثر أمانًا لأنه لا يشارك كلمة مرور root، ويسجل كل أمر، ويقيد الصلاحيات. أما su فيفتح جلسة كاملة بصلاحيات root، وكل ما تفعله داخلها غير مسجل بالتفصيل.

ملف sudoers: القواعد والبنية

ملف /etc/sudoers هو قلب سياسة sudo. بنيته الأساسية:

user  host=(target_user)  command

مثال:

alice  ALL=(ALL)  /usr/bin/apt update, /usr/bin/apt upgrade

هذا يعني: أليس، على أي جهاز، يمكنها تشغيل أوامر apt update وapt upgrade بصلاحيات أي مستخدم (بما في ذلك root). لاحظ أن الأوامر محددة، لا “كل شيء”.

الملف يدعم أيضًا Aliases لتجميع المستخدمين والأوامر، وDefaults لضبط سلوك sudo العام. ويمكن تضمين ملفات إضافية من /etc/sudoers.d/، وهذا أفضل من تعديل الملف الرئيسي.

تحرير sudoers بأمان: visudo وملفات sudoers.d

القاعدة الأولى: لا تفتح /etc/sudoers بمحرر نصي عادي. استخدم visudo، لأنه يتحقق من صحة الصياغة قبل الحفظ. إذا أخطأت في الصياغة دون visudo، فقد تفقد القدرة على استخدام sudo تمامًا.

sudo visudo

للتحقق من الصياغة دون فتح المحرر:

sudo visudo -c

الطريقة الأفضل هي وضع القواعد في ملفات منفصلة داخل /etc/sudoers.d/، بصلاحيات 0440، ثم تضمينها من الملف الرئيسي. هذا يسهل إدارة القواعد وحذفها دون لمس الملف الأساسي.

sudo visudo -f /etc/sudoers.d/ops

أخطاء تكوين sudo الشائعة والخطيرة

sudo ليست آمنة بطبيعتها. أمانها يعتمد على القواعد التي تكتبها. هذه أكثر الأخطاء شيوعًا:

الأوامر التي تمنح shell كاملًا دون أن تدري

أخطر خطأ في sudoers هو السماح بأمر “يبدو بريئًا” لكنه يسمح بالهروب إلى shell. هذه الأوامر لا تنفذ مهمة محددة فقط، بل تتيح تنفيذ أي أمر آخر. أمثلة:

• vim / vi: يمكنك من داخله تشغيل :!bash للحصول على shell.
• less / more: يمكنك من داخله تشغيل !bash.
• find: يدعم -exec، فيمكنك تنفيذ أي أمر.
• awk: يدعم system() لتنفيذ أوامر.
• python / perl / ruby: يمكنك تشغيل os.system() أو ما يعادلها.
• tar / zip: تدعم خيارات تنفيذ أوامر خارجية.

مشروع GTFOBins يحصر مئات هذه الأوامر. القاعدة: أي أداة تسمح بتنفيذ أوامر خارجية، أو فتح محرر، أو تشغيل shell، هي أداة تمنح root كاملًا. إذا احتجت إلى تحرير ملف كـroot، استخدم sudoedit، لأنه ينسخ الملف ويعيده دون منح shell.

لماذا sudo su وsudo -i يبطلان مزايا sudo؟

من الشائع أن يكتب المستخدم sudo su أو sudo -i للحصول على shell كـroot. هذا يبدو مريحًا، لكنه يلغي معظم ما يجعل sudo آمنة:

• يفقد التسجيل الدقيق. الأوامر التي تُنفَّذ داخل shell تفقد سياق sudo، فلا يُسجَّل من نفّذ ماذا.
• يمنح صلاحية دائمة للجلسة. أي خطأ أو عملية خبيثة تستفيد من shell المفتوح.
• يتجاوز مبدأ الامتياز الأقل. أنت لا تحتاج root لكل شيء داخل الجلسة.

القاعدة العملية: استخدم sudo لكل أمر على حدة، ولا تفتح shell دائمًا. إذا كنت تحتاج إلى عدة أوامر، نفّذها واحدًا واحدًا، أو اكتب سكريبتًا محدودًا. هذا يحافظ على سجل التدقيق وحدود الصلاحية.

أفضل ممارسات sudo في الإنتاج

• لا تمنح ALL=(ALL) ALL إلا لمن يحتاجها فعلًا. ابدأ بقواعد محددة، ووسّع عند الحاجة.
• استخدم مجموعات بدل المستخدمين. أضف المستخدمين إلى مجموعة مثل sudo أو wheel، وامنح الصلاحيات للمجموعة.
• قيّد NOPASSWD بأوامر محددة. لا تستخدمه على “ALL” أبدًا.
• اضبط timestamp_timeout. القيمة الافتراضية غالبًا خمس دقائق. قلّلها إذا كانت البيئة حساسة.
• راقب /var/log/auth.log أو /var/log/secure. ابحث عن محاولات فاشلة أو أوامر غير متوقعة.
• حدّث sudo. ثغرات sudo موجودة، وآخرها CVE-2025-32462 وCVE-2025-32463 التي سمحت برفع الصلاحيات محليًا.
• استخدم visudo دائمًا. ولا تعدل sudoers بمحرر عادي.

بدائل sudo: doas وsudo-rs

رغم هيمنة sudo، هناك بدائل تستحق المعرفة:

• doas: أداة من OpenBSD، أصغر بكثير من sudo، وملف تكوينها أبسط. تقدم 95% من وظائف sudo بكود أقل. عيبها أن بعض الميزات المتقدمة (مثل المجموعات والقيود الزمنية) محدودة، وقد تكون أقل نضجًا على لينكس.
• sudo-rs: إعادة كتابة لـsudo بلغة Rust، تهدف إلى تقليل فئة الأخطاء المرتبطة بإدارة الذاكرة. بدأت بعض التوزيعات مثل postmarketOS تستخدمها افتراضيًا في 2026.

بالنسبة لمعظم المستخدمين، sudo القياسية كافية وآمنة عند التكوين الصحيح. البدائل مفيدة في سياقات محددة: doas للبساطة، وsudo-rs للبيئات التي تريد تقليل سطح الهجوم في الكود نفسه.

قائمة تحقق نهائية

• هل تستخدم sudo لأمر واحد بدل sudo su؟ ← نعم، هذا هو الاستخدام الصحيح
• هل تفتح sudoers بـvisudo؟ ← دائمًا، ولا تفتحه بمحرر عادي
• هل قواعدك محددة بأوامر معينة؟ ← تجنب ALL=(ALL) ALL
• هل تستخدم NOPASSWD؟ ← فقط لأوامر محددة، لا لـALL
• هل تسمح بأدوات مثل vim أو less أو find؟ ← هذه تمنح shell كاملًا
• هل تستخدم wildcards في مسارات الأوامر؟ ← حدد المسارات بدقة
• هل timestamp_timeout منخفض؟ ← اضبطه حسب حساسية البيئة
• هل تحدّث sudo بانتظام؟ ← ثغرات رفع الصلاحيات موجودة
• هل تراقب سجلات sudo؟ ← auth.log أو secure
• هل تعرف من في مجموعتك يستطيع sudo؟ ← راجع sudoers دوريًا

روابط ومصادر مفيدة

فيما يلي روابط رسمية وأدوات يمكنك الرجوع إليها:

• sudo — الموقع الرسمي
• sudoers(5) — دليل الصفحة الرسمي
• sudo(8) — دليل الأمر
• GTFOBins — كتالوج الأوامر التي تفتح shell
• sudo-rs — إعادة كتابة sudo بلغة Rust
• doas — دليل OpenBSD

أسئلة شائعة

هل sudo أكثر أمانًا من su دائمًا؟

عند التكوين الصحيح، نعم في الغالب. sudo يسجل الأوامر، ويقيد الصلاحيات، ولا يشارك كلمة مرور root. لكن sudo سيئة التكوين (ALL=(ALL) ALL أو NOPASSWD: ALL) قد تكون أخطر من su، لأنها تمنح صلاحيات واسعة دون تتبع كافٍ.

لماذا يطلب sudo كلمة مروري أنا وليس كلمة مرور root؟

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

هل يمكن استغلال sudo لرفع الصلاحيات؟

نعم، إذا كانت القواعد سيئة. السماح بـvim أو less أو find أو python يمنح shell كاملًا. وكذلك wildcards الواسعة، والسكريبتات في مجلدات قابلة للكتابة. راجع قواعدك، واستخدم GTFOBins للتحقق من الأوامر الخطرة.

ماذا أفعل إذا فقدت القدرة على استخدام sudo؟

إذا أفسدت sudoers، فقد لا تستطيع استخدام sudo. الحل هو الإقلاع في وضع الاسترداد (recovery mode) أو من LiveUSB، ثم إصلاح الملف أو استعادة نسخة احتياطية. هذا سبب إضافي لاستخدام visudo دائمًا.

هل أحتاج إلى sudo على الخادم؟

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