أمن Linux / متقدم: التصميم المقيد والتغيير المتحقق / الدرس 17
التحقق من تغييرات الأمن بأدلة مميزة
بناء حالات قبول ورفض مفيدة وحفظ نطاق التنفيذ ومراجعة التغيير الفعال لا اكتمال القائمة.
في هذه الصفحة
أهداف الدرس
- فحص حفظ العمل المفيد ورفض السلطة الزائدة.
- فصل الحالات المخططة والنماذج المنفذة والتحقق الفعلي من المنصة.
فحص النتيجة المحمية التي يعد بها التغيير
يرتبط تغيير التقوية بادعاء محدد، مثل قراءة عامل التقارير جداول عامة مع عجزه عن إدارة حسابات المضيف. اختبر العمل المشروع والبدائل السليمة المرفوضة معا. قد تحقق خدمة لا تبدأ فحوص منع كثيرة وتفشل غرضها. اختر حد الإنفاذ الفعلي لكل ادعاء: استدلال سياسة أو تفسير إعداد أو حالة محملة أو سلوك نواة وتطبيق مرصود. ينفذ المساق نموذج السياسة فقط، ولا يشغل ماسحات أو معايير أمن أو اختبارات أذونات أو خدمات أو أوامر إدارية ضد المضيف.
استخدام نتائج صريحة تكشف المنح الخاطئ
يفحص البرنامج الأول قائمة سلطة خيالية مقابل مهمتين مشروعتين ومهمتين محظورتين، بتوقعات صريحة مستقلة في البيانات. إذا أضيف manage-host إلى المسموح، تفشل الحالة السلبية بدلا من قبول أي نجاح. يمنح ذلك الحكم قدرة تمييز، ولا يفحص اعتماد Linux أو سلوك العزل الفعلي. عامل التسميات كمتطلبات وأسند دليل الإنفاذ الحقيقي مستقلا. تجنب حساب المتوقع باستدعاء مساعد السياسة نفسه، فقد يجعل عيب مشترك المتوقع والفعلي متفقين دائريا.
allowed = {"read-public-schedules", "write-derived-summaries"}
cases = [("read-public-schedules", True), ("write-derived-summaries", True), ("read-attendee-contacts", False), ("manage-host", False)]
for operation, expected in cases:
assert (operation in allowed) is expected
assert len(cases) == 4
print("legitimate and excess-authority cases discriminate the policy")
legitimate and excess-authority cases discriminate the policy
يقارن البرنامج الكامل أربع تسميات بمجموعة ثابتة، دون ملف أو قدرة أو حساب أو خدمة. النتيجة دليل سياسة فقط ولا تثبت إنفاذ النظام.
مقارنة الفحوص المقصودة والمسجلة فعلا
قد يحذف الملخص الناجح الحالة السلبية الوحيدة التي تحمي الحد. يكشف البرنامج الثاني غياب منع سياسة إلزامية من قائمة تنفيذ معلنة، ولا ينفذ أيا من فحوصها. يحتاج سجل التحقق الفعلي مخرجات مرصودة وهوية البيانات والبيئة ومراجعة المصدر والقيود. أظهر المتجاوز وأسبابه. لا يثبت عدد أو درجة تغطية فحص العملية والفاعل والمورد والأثر الصحيحين. اكتمال الدليل وصحة كل اختبار سؤالان مختلفان للمراجعة.
intended = {"public-input-allowed", "scoped-output-allowed", "mandatory-policy-denial"}
recorded = {"public-input-allowed", "scoped-output-allowed"}
missing = sorted(intended - recorded)
assert missing == ["mandatory-policy-denial"]
assert not intended <= recorded
print("a green subset leaves the required denial check pending")
a green subset leaves the required denial check pending
يقارن البرنامج الكامل قائمتين مختلقتين دون إذن أو سياسة مسماة أو CI أو مضيف. يبقى الناقص متطلبا مخططا لا اختبارا فعليا ناجحا أو فاشلا.
مراجعة التصحيح المحدد والتبعيات المجاورة
إذا كسر قيد خدمة تبعية مشروعة، فحدد المورد والتصحيح المقترح بدقة بدلا من إزالة كل الضوابط. راجع المستدعين المجاورين والمسارات القابلة للكتابة والموارد الموروثة وافتراضات التعافي المتأثرة. قد تتضمن التهيئة تضمينات واستبدالات وافتراضات حزم وسلوكا يعتمد الإصدار لا يفسره نموذج نص بسيط. لا تدع فعالية التغيير لمجرد تعديل ملف. تحتاج فحوص الصيغة والتحميل والسلوك تصريحا ودعم بيئة مستقلين. احفظ العرض القديم والدليل على معالجة التصحيح سببه.
الإبلاغ عن الناجح وما بقي غير منفذ
يسمي تقرير التغيير المفيد الخاصية المقصودة والنتائج المحلية الفعلية ونتائج المنصة إن وجدت والحدود المفتوحة والاستثناءات والخطوة المسؤولة التالية. تثبت الأمثلة علاقات سلطة وقائمة مختلقتين فقط، ولا تختبر systemd أو AppArmor أو nftables أو SSH أو ثقة الحزم أو التخزين أو النواة. أبق القيد قرب الادعاء ولا تخفه في ملخص أخضر واسع. وسع الفحوص عند تغير أو فشل أو آلية مشتركة مبررة، وأوقف تكرار غير المتعلق بعد كفاية الدليل للقرار المحدد.
الأخطاء الشائعة وإصلاحها
تنجح الموانع لتعطل العمل
- لماذا يحدث؟
- يحذف المتطلب الإيجابي.
- كيف تصلحه؟
- اجمع العمل والبدائل المرفوضة.
- كيف تتجنب تكراره؟
- راجع الأمن والوظيفة كعقد محمي.
تسمى القائمة دليلا منفذا
- لماذا يحدث؟
- تخلط أسماء الفحوص بالنتائج.
- كيف تصلحه؟
- ارفق المخرجات واحفظ المخطط والمتجاوز.
- كيف تتجنب تكراره؟
- قارن المقصود والمسجل.
يثبت النص تغييرا أمنيا حيا
- لماذا يحدث؟
- يجهل التحميل والتشغيل.
- كيف تصلحه؟
- افصل مراجعة المصدر والإنفاذ.
- كيف تتجنب تكراره؟
- سجل الإصدار والقيود.
اختبر فهمك
1. لماذا تلزم حالة إيجابية لأقل الصلاحيات؟
اعرض الحل المشروح
تمنع سياسة رفض الجميع أو خدمة لا تبدأ من إرضاء الحزمة وتعطيل المنتج. أكد المدخل والمخرج المشروعين والمنح الزائد المرفوض، مع حاجة التسميات لدليل إنفاذ مستقل.
2. لم تسجل حالة السياسة الإلزامية. هل يدعى نجاحها؟
اعرض الحل المشروح
لا. أبقها منتظرة وحدد الملاحظة المصرح بها. لا يثبت نجاح العمل المحلي إرفاق AppArmor أو منعه. يحفظ التقرير الدليل ونقص التغطية.
أهم ما تعلمته
- تدعم الحالات المميزة أمنا مفيدا.
- يختلف المخطط والمخرج المنفذ.
- يحتاج الإعداد تحقق حالة قبل ادعاء التشغيل.