دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". المحاضرة 6: "الفرص" ، الجزء 1

معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكنز. 2014 سنة

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

المحاضرة 1: "مقدمة: نماذج التهديد" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 2: "السيطرة على هجمات القراصنة" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 3: "تجاوزات العازلة: المآثر والحماية" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 4: "فصل الامتيازات" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 5: "من أين تأتي أنظمة الأمن؟" الجزء 1 / الجزء 2
المحاضرة 6: "الفرص" الجزء 1 / الجزء 2 / الجزء 3

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

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

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



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

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

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



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

يمكن لمثل هذا المستخدم ، على سبيل المثال ، جمع شيء مثل foo.f ، حيث f هو كود المصدر لـ Fortran ، وإضافة هنا - o / sysx / stat .



كان لديهم ملف آخر في النظام / sysx ، والذي كان ملف فوترة لجميع عملاء النظام. أضرارها ستلحق المزيد من الضرر. كان من الممكن بطريقة مماثلة "سؤال" المترجم لتجميع الملف / sysx / bill المصدر ووضعه في ملف خاص في / sysx . وفي حالتهم ، نجحت. على الرغم من حقيقة أن المستخدم نفسه لم يكن لديه حق الوصول للكتابة إلى هذا الملف أو الدليل ، فقد استخدم المترجم ، الذي كان لديه هذا الامتياز الإضافي - ترخيص للملفات المنزلية. بفضل امتيازات المترجم ، تمكن من استبدال الملفات بما يتعارض مع نوايا المطور.



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

الأول ، الأساسي ، يعتمد على حقيقة أنه إذا اتصل المستخدم بالمترجم ، فيجب أن يكون قادرًا على الوصول إلى الملف المصدر ، مثل foo.f. وإذا كان هناك مستخدم آخر لم يتم تنشيطه أو لم يتصل بالمترجم ، فلن يتمكن مثل هذا المستخدم من الوصول إلى شفرة المصدر للمستخدم "الصحيح".

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

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

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

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

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

الجمهور: يمكن للمرء مشاركة امتيازات المترجم.

البروفيسور: نعم ، سيكون هذا تصميمًا جيدًا آخر يحتمل أن يشارك أوراق اعتماده. نحن نعلم أنه في الواقع لا يحتاج مترجم فورتران إلى الامتيازين في نفس الوقت. لذا ، ربما ، بالتحدث في Unix ، يمكننا إنشاء مترجم مثل world / bin / fortcc ، وسيكون مجرد برنامج عادي بدون امتيازات إضافية. وبعد ذلك سنقوم بإنشاء / bin / fortlog ، والذي سيكون برنامجًا خاصًا مع بعض الامتيازات الإضافية ، وسيقوم بجمع إحصائيات حول ما يحدث في المترجم ، وستدعو وظيفة fortcc fortlog . لذا ، ما هي الامتيازات التي نمنحها لقلعة الحصن هذه؟



الجمهور: ربما إذا كنت تستخدم شيئًا مثل setuid أو fortlog ، فيمكن لأي مستخدم آخر أيضًا تسجيل أي بيانات عشوائية من خلاله.

البروفيسور: نعم ، لذا فهي ليست رائعة. لأن الطريقة الوحيدة في Unix لمنح امتيازات إضافية لـ fortlog هي أن تصبح مالكها ، لا أعرف ، ربما إنشاء Fort UID و setuid . وفي كل مرة تقوم بتشغيل Fortlog ، يتحول إلى UID للقلعة . وربما لا تزال هناك حاجة إلى بعض ملف الإحصائيات الخاصة هنا. ولكن بعد كل شيء ، يمكن للجميع تسمية هذا الحصن .



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

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

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

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

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

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

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

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



وبالتالي ، هناك بعض الأذونات التي يمكنك الحصول عليها من هذا الكائن ، وتحتاج إلى تحديد ما إذا كان سيتم السماح بالعملية بهذا الاسم الذي تم منحه للتطبيق ، أي اسم السلسلة -> الكائن -> تم إنشاء الإذن . هذا ما يحصل التطبيق لرؤية العملية.

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

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

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



هذا نوع من المعادل الأخلاقي لهذه المشكلة المربكة في نماذج الشبكات.

الجمهور: تؤثر الأذونات الحالية أيضًا على ذلك.

الأستاذ: نعم.

الجمهور: لأن الفليفلة تستخدم بشكل أساسي DAC - التحكم في الوصول التقديري.

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



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

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

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

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



بمعنى ما ، عند تشغيل برنامج التحويل البرمجي Fortran ، فإنه يفتح الملف نيابة عن المستخدم ، وتحتاج إلى تكرار نفس المنطق الذي نراه هنا في الرسم التخطيطي ، باستثناء أنه يجب على برنامج التحويل البرمجي Fortran توصيل شيء آخر لعملية Sur UID . بدلاً من استخدام الامتيازات الحالية ، يجب عليه ببساطة تكرار الاسم -> كائن -> فحص الإذن ومحاولة القيام بذلك مع مجموعة مختلفة من الامتيازات لعملية UID الخاصة بنا .

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

الجمهور: إذا قمت بفحوصات في التطبيق ، فلا يمكنك ببساطة إجراء فحوصات أخرى.

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

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

أقرب ما يكون إلى حل المشكلة هو قدرات واصف الملف على Unix .



في عالم الاحتمالات ، هناك بديل لهذا المخطط هو أنه بدلاً من اتباع اسم السلسلة -> كائن -> إذن وتحديد ما إذا كان سيتم استخدامه بناءً على الأذونات الخارجية لعملية معالجة UID ، يمكنك استخدام مخطط بسيط للغاية.

افترض أن لديك إمكانيات تتعلق بكائن معين. وقد تحتوي هذه الميزات على عدد من القيود فيما يتعلق بما يمكنك القيام به مع هذا الكائن.



ولكن في الأساس ، إذا كانت لديك فرص لهذا الكائن ، فيمكنك الوصول إليه. . , , , .
, Capability , , , , . . Capability , - , — .

Capability , . , ?

, , . , . , , .

, , , « ». , , Capsicum ? ?

: , , , Capability .

: , , , , . — . Unix , 0, , 1, . . , , . , - , , . PID , , PID:57 , . , , . , , , , , .. .



, , , . , -, - , .

, , , Unix , , , /etc/pwd .

. . , . , « »?



, , integer . , . , .

, . , ? , . , .

, , Capability , Fortran . sysx/fort ? , ?

: , . , , output- . , , .

: , . , Fortran /sysx/stat . , .

, , . , , «» Unix . , , , Fortran , , , , , .

. fort1 , , - , , foo.f , , , — o , . , . , .

, , , . ! , , , , setuid Fortran .



, setuid - , . , . , , , , .

, , , , . , , , Capability , , , , .

26:30

:

دورة معهد ماساتشوستس للتكنولوجيا "أمن أنظمة الكمبيوتر". 6: «», 2


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! كيفية بناء البنية التحتية للمبنى. الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟