هل سبق لك أن قمت بعمل صعب من أجل مصلحة المجتمع ، لكنك لم تلاحظ جهودك ، لأنك استفدت لفترة طويلة حتى أنك معتاد على ذلك؟ هذا هو نوع العمل الذي يقوم به جميع أفراد
مجتمع SELinux .
وفي 18 فبراير من هذا العام ، بفضل عملهم إلى حد كبير ، تم إنقاذ العالم من الضعف الخطير في ضرب الحاويات
CVE-2019-5736 .
على الرغم من وجود أنظمة تشغيل أخرى ومشاريع مفتوحة المصدر أخرى تستخدم عناصر التحكم في النوع والفئة ، فمن النادر أن يتم تضمين جميع المكونات التي تم تكوينها مع SELinux خارج الصندوق ، بشكل افتراضي ، وتكون جاهزة للعمل. بل إنه نادراً ما يغطي هذا التكوين جميع المستويات ، وصولاً إلى الحل لتنسيق الحاوية ، والتي تعمل على أساسها السحابة العامة.
يستخدم Red Hat OpenShift آليات التحكم في الوصول القسري لنظام Linux ، مثل فرض النوع (TE) والأمن متعدد الفئات (MCS) منذ ثماني سنوات. تم استخدام SELinux في OpenShift منذ عام 2011. في Red Hat OpenShift Online ، وهي خدمة استضافة متاحة للجمهور حيث يقوم الآلاف من المطورين بتشغيل رمز الحاوية يوميًا ، تم استخدام SELinux منذ البداية. ماذا عن إصدار OpenShift المستخدم ، على سبيل المثال ، في مركز بيانات مشغل الهاتف المحمول المفضل لديك؟ في الواقع ، يتم تضمين وحدة الأمن SELinux في منصة Red Hat OpenShift Container Platform بشكل افتراضي ، افتراضيًا! وليس فقط قيد التشغيل ، ولكن تكوينها بالكامل وجاهزة للحماية من التهديدات الحقيقية.
بخلاف توزيعات Kubernetes الأخرى ، يعمل Red Hat على سد الفجوة بين Linux ومنصة تزامن الحاوية المثبتة فوقه. أي أن Red Hat OpenShift تراقب وتزيل التهديدات الأمنية في جميع أجزاء المجموعة ، وليس فقط في طبقة واحدة. ويتم ذلك بشكل افتراضي - من اليوم الأول من العمل.
يستخدم OpenShift هذا التكوين افتراضيًا في Red Hat Enterprise Linux (لا تحتاج حتى إلى معرفة ما هو موجود). لا يقتصر الأمر على تشغيل setenforce 1. على جهاز كمبيوتر محمول ، ويمكن تمديد قواعد التحكم في الوصول للأنواع والفئات التي ينطبق عليها المستأجر للعمل مع الحاويات على مجموعة Kubernetes إلى مئات العقد التي يمكن استخدامها من قبل الآلاف من المستأجرين الآخرين.
فكر في كيفية تهيئة SELinux مع MCS بعد بضع سنوات من الاستخدام في شركة كبيرة تقوم بتوزيع بيانات اعتماد OpenShift من اليسار واليمين. الآن تخيل أنك قدمت بيانات اعتمادك لتسجيل الدخول إلى مجموعة OpenShift ، كما نفعل في openshift.com. غالبًا ما يفشل ولاء SELinux في التعرف على كل ما تفعله في حل OpenShift. إذا بدا لك أن نظام التشغيل ليس مهمًا هذه الأيام ، فكر فيما إذا كنت محميًا من ثغرة أمنية CVE-2019-5736 حتى شهر فبراير. في OpenShift ، يتم
حماية CVE-2019-5736 من البداية ، ويمكنك الانتقال إلى هذا الحل
الآن .
علامات سيلينو
إحدى ميزات الأمان الافتراضية الأكثر فاعلية المطبقة في Red Hat OpenShift هي Linux-Enhanced Linux (SELinux). SELinux هي وحدة أمان kernel Linux توفر التحكم في الوصول المستند إلى سياسة الأمان. طريقة عمل SELinux هي تعيين علامات (أسماء) لجميع عمليات وكائنات نظام التشغيل. وبالتالي ، يتم تمييز وتصنيف كل عنصر من العناصر المشاركة في عمليات kernel ، ثم يتم منح حق الوصول استنادًا إلى مجموعة من القواعد الحالية.
تحدد قواعد السياسة العلاقة بين العمليات المميزة والكائنات المميزة. يتم تطبيق القواعد التي يحددها المستخدم في السياسات على مستوى النواة. افتراضيًا ، يتم رفض أي شيء غير مسموح به تلقائيًا - عن طريق القياس باستخدام جدار الحماية الذي يمنع الوصول إلى جميع العمليات التي لم يتم تكوين أذونات صريحة لها. توضح الرسوم التوضيحية أدناه حالات الاستخدام البسيطة.
تخيل نظامًا تحتاج فيه إلى تحديد أنواع الكائنات مثل القطط والكلاب. القط والكلب أنواع من العمليات.
* جميع الرسومات من قبل ماريين دوفيفئة الكائنات التي ستتفاعل بها العمليات هي الخلاصة. أضف أنواع الخلاصة: cat_chow و dog_chow (Ohm-nom-nom).
وضعنا إذنًا للكلب لتناول طعام الكلاب (dog_chow) ، ولغذاء القط (cat_chow). نكتب هذه الأذونات كقاعدة سياسة SELinux:
allow cat cat_chow:food eat; allow dog dog_chow:food eat;
وفقًا لهذه القواعد ، سيسمح لعملية "القط" على مستوى النواة بتناول الطعام باستخدام علامة cat_chow وللكلب - الطعام مع علامة dog_chow.
لكننا نتذكر أنه في SELinux ، بشكل افتراضي ، كل شيء محظور. لذلك ، إذا حاول الكلب أن يأكل cat_chow ، فإن القلب لن يسمح بذلك.
هذا هو التحكم في الكتابة ، والذي يلعب دورًا رئيسيًا في حماية النظام المضيف من عمليات الحاوية. يمكن لعمليات الحاوية فقط قراءة وتشغيل الملفات من دليل / usr وكتابة البيانات فقط إلى ملفات الحاوية. يحمي هذا التقييد المضيف من الحاويات بشكل موثوق ، لكنه لا يحمي بعض الحاويات من الآخرين ، لأنها جميعها تحمل نفس النوع. لحماية الحاويات من بعضها البعض ، ستحتاج إلى تطبيق التحكم في علامة MCS.
MCS لا سحب القط من الذيل
لا يرتبط استخدام MCS بشكل مباشر بحماية OpenShift من
CVE-2019-5736 ، لكن من المفيد أن تتعرف على هذا الموضوع من أجل فهم مبادئ استخدام SELinux في OpenShift بشكل أفضل. تعيين تسميات MCS من وجهة نظر المستخدم أو مسؤول النظام أمر بسيط للغاية. تحتاج فقط إلى تكوين مجموعة من الفئات التي هي علامات نصية بسيطة (على سبيل المثال ، Fido أو Spot) ، وإضافة مستخدمين إليها. يقوم مسؤول النظام أولاً بإعداد الفئات ثم يضيف مستخدمين إليها ، وبعد ذلك يمكن للمستخدمين استخدام هذه التصنيفات كما يحلو لهم. هذا مناسب لأن MCS يسمح لك باستخدام علامات SELinux القياسية لإدارة الكائنات. دعنا ننتقل مرة أخرى إلى النظام التخيلي من المثال أعلاه.
أضف جزءًا آخر من الملصق الذي سيتم تطبيقه على عملية الكلب وإطعام الكلب. قم بتعيين العملية "كلب" للكلب: random1 (Fido) والكلب: random2 (Spot).
دعنا نحدد dog_chow: random1 (Fido) و dog_chow: random2 (Spot) تسميات لأغذية الكلاب.
وفقًا لمبادئ تشغيل MCS ، إذا تمت مراعاة قواعد التحكم القسري حسب النوع وكانت علامات MCS التعسفية متطابقة تمامًا ، عندئذٍ يُسمح بالدخول ، وفي جميع الحالات الأخرى يتم رفضه.
محاولات Fido (dog: random1) للأكل cat_chow: سيتم رفض الطعام بسبب عناصر التحكم في الكتابة القسرية.
الدفاع في العمق
تعد وحدة أمان SELinux الافتراضية التي يستخدمها OpenShift مثالًا أساسيًا للدفاع في العمق. يستخدم OpenShift ، مثل العديد من الأنظمة الأساسية المستندة إلى Kubernetes ، سياسات
SCC / PSP التي تحظر تشغيل الحاويات بامتيازات الجذر. يحمي هذا القيد أيضًا من
CVE-2019-5736 . في OpenShift ، يتم حظر الحاويات التي يملكها المستخدم الجذر افتراضيًا ، ولكن
يمكن تغيير هذه المعلمة. حتى لو سمحت للحاويات بالعمل كجذر ، فإن تكوين SELinux القياسي في OpenShift لا يزال يحمي من
CVE-2019-5736 . هذا مستوى آخر من الحماية يؤتي ثماره حقًا في هذا الموقف وهو بعيد عن المستوى الوحيد في OpenShift. يمكن العثور على مزيد من المعلومات في المستند
10 مستويات أمان حاوية .
لمزيد من المعلومات حول
CVE-2019-5736 ، بما في ذلك تصحيح Red Hat Enterprise Linux الخاص
بوقت تشغيل الحاوية ، راجع
مراجعة الثغرة الأمنية لـ Red Hat .