شرح linPEAS بالعربي: من نتيجة ملونة إلى فهم صلاحيات لينكس والمسارات والخدمات

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

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

ابدأ بسؤال أصغر من «كيف أوصل إلى root؟»

السؤال الكبير يحفزك، لكنه قد يخليك تتعامل مع كل معلومة كأنها وعد بنهاية معينة. بدل ذلك ابدأ بسؤال محدد: هل حساب المتدرب يستطيع تغيير ملف إعداد تعتمد عليه خدمة تعليمية؟ هذا السؤال يحدد المستخدم والأصل والقدرة المطلوبة. إذا كانت الإجابة غير معروفة، تجمع المعلومات اللازمة لها. وإذا كانت لا، تبحث عن سؤال آخر تدعمه المخرجات بدل إجبار القصة على مسار أنت متوقعه مسبقًا.

مشروع PEASS-ng يقدم linPEAS كأداة تبحث عن مؤشرات لمسارات محتملة لتصعيد الصلاحيات المحلي، ويستخدم ألوانًا للمساعدة في ملاحظة الإعدادات. هذا وصف دورها، وليس تعهدًا بأن كل نتيجة قابلة للاستغلال. كذلك تختلف إصدارات الأداة والبيئات التي تعمل عليها؛ سجل النسخة والمصدر ونظام التشغيل والحساب. لا تنقل أوامر خيارات من فيديو قديم قبل مراجعة توثيق النسخة التي تستخدمها، خصوصًا إذا لم تعرف مقدار الجمع الذي ستجريه.

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

id يشرح السياق، لكن لا يشرح النظام كاملًا

في بداية المراجعة المحلية استخدم id لتعرف المستخدم والمجموعات في سياق العملية الحالية. التوثيق يميز معلومات الهوية الفعلية والفعالة، ويعرض معلومات المستخدم والمجموعات حسب الخيارات. في مثالنا التعليمي، نفترض حسابًا اسمه trainee ضمن مجموعة labreaders. ظهور المجموعة معلومة مهمة، لكنه لا يخبرك وحده أي ملفات يستطيع قراءة محتواها أو تغييرها. تحتاج تربط المجموعة بحقوق الأصل الذي تسأل عنه، وبالبيئة التي تراها العملية.

احتفظ بمخرجات الهوية مع وقت الفحص، ولا تخلط بين حساب لجلسة SSH وحساب لعملية خدمة ثم تتوقع أن النتائج متطابقة. وإذا طلبت id لاسم مستخدم آخر، انتبه أنك تجمع معلومات عن الحساب المحدد، وليس أنك بدأت عملية بتلك الهوية. كذلك تغيير إعداد عضوية ثم قراءة معلومات الحساب لا يغني عن التأكد من سياق الجلسة المستخدمة في المقارنة. وضح في ملاحظاتك هل راجعت تعريف الحساب أم الهوية الموجودة في الجلسة.

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

اقرأ المسار من بدايته، مو من آخر ملف فيه

إذا ظهرت ملاحظة على /opt/labreport/config.ini، فلا تتوقف عند سطر صلاحية config.ini. راجع مكونات المسار: الجذر، ثم opt، ثم labreport، ثم الملف. الأداة namei مفيدة لأنها تعرض تسلسل المسار، وتبين الروابط الرمزية، ومع الخيار -l تعرض معلومات الملكية والصلاحيات لكل جزء. أمر القراءة في لابنا هو namei -l /opt/labreport/config.ini . هذا مسار افتراضي أنشأته للتمرين، وقد لا يوجد على جهازك.

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

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

متى تحتاج getfacl بدل الاكتفاء بالشكل المختصر؟

قائمة الصلاحيات المعتادة تعطيك بداية، لكنها قد لا تعرض كل تفاصيل قائمة التحكم بالوصول. getfacl يقرأ ACL الخاصة بالملف أو المجلد، ويعرض عناصر تسمح لك بفهم حقوق مستخدمين ومجموعات إضافية وحدودها. في الحالة التعليمية استخدم getfacl /opt/labreport/config.ini ثم راجع ما ظهر عن المستخدم والمجموعة، مع الانتباه إلى mask والحقوق الفعالة التي يوضحها الإخراج عند اختلافها. لا تكتفِ برؤية اسم مجموعة وتعتبر كل الحقوق المكتوبة نافذة كما توقعتها.

الفائدة العملية تظهر عندما يقول متدرب: السطر يعرض rw لكني لا أستطيع تنفيذ ما توقعت. بدل افتراض خلل في الأداة، قارن ACL والسياق والمسار. وقد يكون سؤال الوصول متعلقًا بمجلد أب أو أصل آخر. أضف إلى ورقة العمل عمودًا يوضح أي حق راجعته وعلى أي أصل. كلمة «الصلاحيات» واسعة؛ حدد هل الحديث عن قراءة محتوى، أو كتابة ملف، أو عبور مجلد، أو شيء آخر يرتبط بعمل التطبيق.

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

الخدمة تقرأ ماذا، وتعمل باسم من؟

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

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

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

حالة تعليمية: تنبيه صحيح واستنتاج أولي غلط

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

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

اكتب الاستنتاج على مرحلتين: ثبت وجود كتابة للمجموعة على مجلد النتائج؛ ولم يثبت في هذه المراجعة تأثير على إعداد الخدمة أو ملف تشغيلها. إذا وجد أثر آخر موثق، صفه مستقلًا. بهذه الصياغة يستطيع المدرّب أو مالك النظام مراجعة كلامك بسهولة. أما جملة «linPEAS أعطاني ثغرة root» فهي تختصر كل ما ينبغي إثباته في عنوان جذاب، وتخفي الفجوة التي كان التمرين أصلًا فرصة لتعلم سدها.

كيف تقلل الضجيج وتحتفظ بما يهم؟

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

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

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

تمرّن على التقرير، مو على اللون بس

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

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

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

مصادر المراجعة: المشروع الرسمي https://github.com/peass-ng/PEASS-ng ، وتوثيق id https://man7.org/linux/man-pages/man1/id.1.html ، وnamei https://man7.org/linux/man-pages/man1/namei.1.html ، وgetfacl https://man7.org/linux/man-pages/man1/getfacl.1.html . إذا بدأت من ويندوز، ارجع أيضًا إلى مقال winPEAS في المجتمع وقارن طريقة فصل المؤشر عن الأثر بين النظامين.