SUID وSGID وSticky Bits هي أذونات خاصة قوية يمكنك تعيينها للملفات القابلة للتنفيذ والدلائل على Linux. سنشاركك الفوائد – والمخاطر المحتملة – لاستخدامها.
لقد تم استخدامها بالفعل
إن بناء الأمن في نظام تشغيل متعدد المستخدمين يطرح العديد من المعضلات. خذ على سبيل المثال مفهوم كلمات المرور (الذي يبدو أساسياً). يجب تخزينها جميعاً بحيث يتمكن النظام في كل مرة يقوم فيها شخص ما بتسجيل الدخول من مقارنة كلمة المرور التي يكتبها بالنسخة المخزنة. ومن الواضح أن كلمات المرور هي مفاتيح المملكة، لذا يجب حمايتها.
في Linux، يتم حماية كلمات المرور المخزنة بطريقتين: فهي مشفرة، ولا يمكن لأحد الوصول إليها إلا إذا كان لديه root يمكن لأصحاب الامتيازات الوصول إلى الملف الذي يحتوي على كلمات المرور. قد يبدو هذا جيدًا، لكنه يمثل معضلة: إذا كان بإمكان الأشخاص الذين لديهم امتيازات الوصول إلى الملف فقط root أصحاب الامتيازات يمكنهم الوصول إلى كلمات المرور المخزنة، فكيف يمكن لأولئك الذين لا يتمتعون بهذا الوصول تغيير كلمات المرور الخاصة بهم؟
رفع مكانتك
عادةً، يتم تشغيل أوامر وبرامج Linux بنفس مجموعة الأذونات التي يتمتع بها الشخص الذي يقوم بتشغيل البرنامج. عندما root تشغيل أمر passwd لتغيير كلمة المرور، فهو يعمل مع rootأذونات ‘s. وهذا يعني أن الأمر passwd يمكنه الوصول بحرية إلى كلمات المرور المخزنة في ملف /etc/shadow.
ما سيكون مثاليًا هو مخطط يمكن لأي شخص على النظام من خلاله تشغيل برنامج passwd، ولكن مع الاحتفاظ ببرنامج passwd rootامتيازات مرتفعة. وهذا من شأنه أن يمنح أي شخص القدرة على تغيير كلمة المرور الخاصة به.
السيناريو أعلاه هو بالضبط ما يحدده بت تعيين معرف المستخدم (SUID) يقوم بتشغيل البرامج والأوامر بأذونات مالك الملف، وليس أذونات الشخص الذي يقوم بتشغيل البرنامج.
أنت ترفع من مكانة البرنامج
ولكن هناك معضلة أخرى. إذ يجب منع الشخص من التدخل في كلمة مرور أي شخص آخر. ويشتمل نظام التشغيل لينكس على SUID إن نظام التشغيل Windows XP لديه نظام يسمح له بتشغيل التطبيقات باستخدام مجموعة من الأذونات المستعارة مؤقتًا – ولكن هذا لا يمثل سوى نصف القصة الأمنية.
آلية التحكم التي تمنع شخصًا ما من العمل باستخدام كلمة مرور شخص آخر موجودة داخل برنامج passwd، وليس نظام التشغيل ومخطط SUID.
إن البرامج التي يتم تشغيلها بامتيازات مرتفعة قد تشكل مخاطر أمنية إذا لم يتم إنشاؤها بعقلية “الأمان من خلال التصميم”. وهذا يعني أن الأمان هو أول شيء تفكر فيه، ثم تبني على ذلك. لا تكتب برنامجك، ثم تحاول إعطائه طبقة من الأمان بعد ذلك.
الميزة الأكبر للبرمجيات مفتوحة المصدر هي يمكنك إلقاء نظرة على الكود المصدر بنفسك أو الرجوع إلى مراجعات الأقران الموثوقة لها. في الكود المصدري لـ passwd البرنامج، هناك فحوصات، حتى تتمكن من معرفة ما إذا كان الشخص الذي يقوم بتشغيل البرنامج هو root. يُسمح بقدرات مختلفة إذا كان شخص ما root (أو شخص يستخدم sudo).
هذا هو الكود الذي يكشف ما إذا كان شخص ما root.
فيما يلي مثال يؤخذ فيه هذا في الاعتبار. لأن root يمكن تغيير أي كلمة مرور، ولا يحتاج البرنامج إلى عناء إجراء الفحوصات التي يقوم بها عادةً لمعرفة كلمات المرور التي يحق للشخص تغييرها. لذا، بالنسبة إلى root، هو – هي يتخطى هذه الفحوصات ويخرج من وظيفة الفحص.
مع الأوامر والأدوات الأساسية لنظام Linux، يمكنك أن تكون على ثقة من أنها تتمتع بحماية أمنية وأن الكود قد تمت مراجعته عدة مرات. بالطبع، هناك دائمًا خطر الثغرات الأمنية غير المعروفة حتى الآن. ومع ذلك، تظهر التصحيحات أو التحديثات بسرعة لمواجهة أي ثغرات أمنية يتم تحديدها حديثًا.
إنه برنامج تابع لجهة خارجية – وخاصة أي برنامج ليس مفتوح المصدر – تحتاج إلى توخي الحذر الشديد عند استخدامه SUID نحن لا نقول لا تفعل ذلك، ولكن إذا فعلت ذلك، فأنت تريد التأكد من أنه لن يعرض نظامك للخطر. أنت لا تريد رفع امتيازات برنامج لن يحكم نفسه بنفسه والشخص الذي يديره بشكل صحيح.
أوامر Linux التي تستخدم SUID
فيما يلي بعض أوامر Linux التي تستخدم بت SUID لمنح الأمر امتيازات مرتفعة عند تشغيله بواسطة مستخدم عادي:
ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd
لاحظ أن أسماء الملفات مميزة باللون الأحمر، مما يشير إلى تعيين بت SUID.
عادةً ما يتم تمثيل الأذونات على ملف أو دليل بثلاث مجموعات من ثلاثة أحرف: rwx. هذه تعني القراءة والكتابة والتنفيذ. إذا كانت الأحرف موجودة، فهذا يعني أنه تم منح هذا الإذن. إذا تم وضع شرطة (-) بدلاً من وجود خطاب موجود، على الرغم من عدم منح هذا الإذن.
هناك ثلاث مجموعات من هذه الأذونات (من اليسار إلى اليمين): تلك الخاصة بمالك الملف، ولأعضاء مجموعة الملف، وللآخرين. عندما SUID عندما يتم تعيين بت على ملف، فإن “s” يمثل إذن التنفيذ الخاص بالمالك.
إذا كان SUID إذا تم تعيين بت على ملف لا يحتوي على إمكانيات قابلة للتنفيذ، فإن الحرف “S” الكبير يشير إلى ذلك.
سنلقي نظرة على مثال. يكتب المستخدم العادي ديف كلمة المرور يأمر:
passwd
ال passwd موجهات الأوامر dave للحصول على كلمة المرور الجديدة الخاصة به. يمكننا استخدام ps يأمر لرؤية تفاصيل العمليات الجارية.
سوف نستخدم ps مع grepفي نافذة طرفية مختلفة وابحث عن passwd العملية. سنستخدم أيضًا الخيارين -e (كل عملية) و-f (تنسيق كامل) مع ps.
نكتب الأمر التالي:
ps -e -f | grep passwd
تم الإبلاغ عن خطين، الخط الثاني منهما هو grep عملية البحث عن الأوامر التي تحتوي على السلسلة “passwd”. ومع ذلك، فإن السطر الأول هو الذي يثير اهتمامنا، لأنه السطر الخاص بـ passwd عملية dave تم إطلاقه.
يمكننا أن نرى passwd تتم العملية بنفس الطريقة كما لو كانت root لقد أطلقها.
ضبط بت SUID
من السهل تغيير SUID بت مع chmod. ال u+s يحدد الوضع الرمزي SUID بت و u-s الوضع الرمزي يمسح SUID قليل.
لتوضيح بعض مفاهيم بت SUID، قمنا بإنشاء برنامج صغير يسمى htg. إنه موجود في الدليل الجذر لـ dave المستخدم، وليس لديه SUID مجموعة بتات. عند تنفيذها، تعرض معرفات المستخدم الحقيقية والفعّالة (معرف فريد).
الحقيقي معرف فريد ينتمي إلى الشخص الذي أطلق البرنامج. المعرف الفعال هو الحساب الذي يتصرف البرنامج كما لو كان قد تم إطلاقه من خلاله.
نكتب ما يلي:
ls -lh htg
./htg
عندما نقوم بتشغيل النسخة المحلية من البرنامج، نرى أن المعرفات الحقيقية والفعّالة تم ضبطها على daveلذا، فهو يتصرف تمامًا كما ينبغي لبرنامج عادي.
دعونا ننسخها إلى /usr/local/bin الدليل حتى يتمكن الآخرون من استخدامه.
نكتب ما يلي باستخدام chmod لضبط SUID بت، ثم تحقق من أنه تم ضبطه:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
لذا، تم نسخ البرنامج، وتم تعيين بت SUID. سنقوم بتشغيله مرة أخرى، ولكن هذه المرة سنقوم بتشغيل النسخة في /usr/local/bin المجلد:
htg
بالرغم من dave تم تشغيل البرنامج، وتم تعيين المعرف الفعال على root المستخدم. لذا، إذا mary عند تشغيل البرنامج يحدث نفس الشيء كما هو موضح أدناه:
htg
الهوية الحقيقية هي mary، والمعرف الفعال هو rootيتم تشغيل البرنامج بأذونات المستخدم الجذر.
بت SGID
معرف المجموعة المحددة (SGID) البت مشابه جدًا لـ SUID بت. عندما SGID عندما يتم تعيين بت على ملف قابل للتنفيذ، يتم تعيين المجموعة الفعالة على مجموعة الملف. يتم تشغيل العملية بأذونات أعضاء مجموعة الملف، وليس أذونات الشخص الذي أطلقها.
لقد قمنا بتعديل htg البرنامج بحيث يظهر المجموعة الفعالة أيضًا. سنقوم بتغيير مجموعة htg البرنامج المراد استخدامه maryالمجموعة الافتراضية، maryسوف نستخدم أيضًا u-s و g+s الأنماط الرمزية مع chown لإزالة SUID بت وضبط SGID.
وللقيام بذلك، نكتب ما يلي:
sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
يمكنك رؤية SGID بت يُشار إليه بالحرف “s” في أذونات المجموعة. لاحظ أيضًا أن المجموعة مضبوطة على mary والآن أصبح اسم الملف مميزًا باللون الأصفر.
قبل أن نقوم بتشغيل البرنامج، دعنا نحدد المجموعات dave و mary تنتمي إلى. سوف نستخدم id الأمر مع الخيار -G (المجموعات)، لطباعة جميع معرفات المجموعة. ثم سنقوم بتشغيل htg برنامج كـ dave.
نكتب الأوامر التالية:
id -G dave
id -G mary
htg
معرف المجموعة الافتراضية لـ mary هو 1001، والمجموعة الفعالة لـ htg البرنامج هو 1001. لذا، على الرغم من أنه تم إطلاقه بواسطة dave، فهو يعمل بأذونات الأعضاء في mary المجموعة. الأمر نفسه كما لو dave انضم إلى mary مجموعة.
دعونا نطبق SGID بت إلى دليل. أولاً، سننشئ دليلاً يسمى “work”، ثم نغير مجموعته إلى “geek”. ثم سنضبط SGID بت في الدليل.
عندما نستخدم ls للتحقق من إعدادات الدليل، سنستخدم أيضًا -d خيار (الدليل) حتى نتمكن من رؤية تفاصيل الدليل، وليس محتوياته.
نكتب الأوامر التالية:
sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work
ال SGID تم تعيين البت والمجموعة “geek”. سيؤثر هذا على أي عناصر تم إنشاؤها داخل work دليل.
نكتب ما يلي لإدخال work الدليل، قم بإنشاء دليل يسمى “demo”، وتحقق من خصائصه:
cd work
mkdir demo
ls -lh -d demo
ال SGID يتم تطبيق المجموعة “bit” و”geek” تلقائيًا على الدليل “demo”.
دعنا نكتب ما يلي لإنشاء ملف بـ أمر اللمس وتحقق من خصائصه:
touch useful.sh
ls -lh useful.sh
تتم تعيين مجموعة الملف الجديد تلقائيًا إلى “geek”.
الجزء اللزج
حصلت البتة اللاصقة على اسمها من الغرض التاريخي الذي استخدمت من أجله. فعند تعيينها على ملف قابل للتنفيذ، فإنها تشير إلى نظام التشغيل بأن أجزاء النص من الملف القابل للتنفيذ يجب أن تبقى في المبادلة، مما يجعل إعادة استخدامها أسرع. وفي لينكس، لا تؤثر البتة اللاصقة إلا على الدليل – ولن يكون تعيينها على ملف منطقيًا.
عند تعيين البت اللاصق على دليل، لا يمكن للأشخاص حذف الملفات التي تخصهم داخل هذا الدليل إلا. ولا يمكنهم حذف الملفات التي تخص شخصًا آخر، بغض النظر عن مجموعة أذونات الملفات التي تم تعيينها على الملفات.
يتيح لك هذا إنشاء دليل يمكن لأي شخص استخدامه كمخزن مشترك للملفات، وكذلك العمليات التي يقوم بتشغيلها. وتكون الملفات محمية لأنه لا يمكن لأي شخص حذف ملفات أي شخص آخر.
لنقم بإنشاء دليل يسمى “shared”. سنستخدم o+t الوضع الرمزي مع chmod لتعيين البت اللاصق على هذا الدليل. سننظر بعد ذلك إلى الأذونات على هذا الدليل، بالإضافة إلى /tmp و /var/tmp الدلائل.
نكتب الأوامر التالية:
mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp
إذا تم تعيين البت اللاصق، فسيتم تعيين البت القابل للتنفيذ لمجموعة “other” من أذونات الملف على “t”. كما يتم تمييز اسم الملف باللون الأزرق.
ال /tmp و /var/tmp المجلدات هي مثالان على الدلائل التي تم تعيين كافة أذونات الملفات فيها للمالك والمجموعة والآخرين (لهذا السبب يتم تمييزها باللون الأخضر). يتم استخدامها كمواقع مشتركة للملفات المؤقتة.
من الناحية النظرية، من الممكن لأي شخص أن يقوم بأي شيء باستخدام هذه الأذونات. إلا أن البت اللاصق يتغلب عليها، ولا يمكن لأحد حذف ملف لا ينتمي إليه.
تذكيرات
فيما يلي قائمة مراجعة سريعة لما تناولناه أعلاه للرجوع إليه في المستقبل:
SUIDيعمل فقط على الملفات.- يمكنك التقديم
SGIDإلى الدلائل والملفات. - يمكنك فقط تطبيق البت اللاصق على الدلائل.
- إذا كان “
s“, “g“، أو “t“تظهر المؤشرات بأحرف كبيرة، البت القابل للتنفيذ (x) لم يتم تعيينه.
ضع هذه النقاط في الاعتبار وستكون على الطريق الصحيح.