bwrap ddsec
1.0.0
ملف تعريف sandboxing بدون امتيازات لـ BubbleWrap
تركز العديد من أدوات تنفيذ الحاويات ، مثل Systemd-Nspawn ، Dockeretc. ، على توفير البنية التحتية لمسؤولي النظام وأدوات التنسيق (على سبيل المثال ، Kubernettes) لتنفيذ الحاويات.
هذه الأدوات ليست مناسبة لمنحهم للمستخدمين دون امتيازات ، لأنه من التافهة تحويل هذا الوصول إلى غلاف جذر مع امتيازات كاملة في المضيف.
يوجد نظام عزل على مستوى Linux kernel يسمى مساحات اسم المستخدم "مساحات المستخدم" التي تحاول السماح للمستخدمين دون امتيازات باستخدام وظائف الحاوية. على الرغم من أنه تم تحقيق تقدم كبير ، إلا أنه لا يزال هناك مخاوف في هذا الصدد وليست متاحة للمستخدمين دون امتيازات في العديد من توزيعات الإنتاج مثل CentOS / Red Hat Enterprise Linux 7 ، Debian Jessie ، إلخ.
انظر ، على سبيل المثال ، CVE-2016-3135 ، وهو ثغرة جذر محلية قدمها المستخدمون. هذا المنشور في مارس 2016 لديه المزيد من النقاش.
يمكن اعتبار BubbleWrap تنفيذًا كاملاً لمجموعة فرعية من مساحات اسم المستخدم. التركيز على المجموعة الفرعية - ذات صلة على وجه التحديد بـ CVE السابق ، لا يسمح BubbleWrap بالتحكم في IPTABLES.
كان رمز BubbleWrap الأصلي موجودًا قبل مساحات أسماء المستخدمين: يرث رمز مساعد XDG -APP والذي ، بدوره ، منزعج بواسطة Linux-User-Chroot.
يعتقد المشرفون في هذه الأداة أنه حتى عند استخدامه مع البرنامج النموذجي المثبت في هذا التوزيع ، فإنه لا يسمح بتصعيد الامتياز. ومع ذلك ، يمكن أن يزيد من قدرة المستخدم الذي قام بتسجيل الدخول لتنفيذ هجمات رفض الخدمة.
على وجه الخصوص ، يتم استخدام BubbleWrap pr_set_no_new_privs لإلغاء تنشيط setuid binary ، وهي الطريقة التقليدية للخروج من أشياء مثل chroots.
يمكن مشاركة هذا البرنامج من خلال جميع أدوات الحاويات التي لا تقوم بالعمليات الجذرية ، مثل:
Flatpak RPM-OSTREETE بدون امتيازات BWRAP-OCI نود أيضًا أن يكون هذا متاحًا في مجموعات Kubernetes / onShift. إن وجود القدرة على استخدام المستخدمين بدون امتيازات من شأن وظائف الحاوية من شأنه أن يسهل بشكل كبير تحقيق سيناريوهات تنقية تفاعلية ومماثلة.
يعمل BubbleWrap عن طريق إنشاء مساحة جديدة للأسماء الفارغة تمامًا ، حيث يكون الجذر في TMPFs غير مرئي للمضيف ، وسيتم تنظيفه تلقائيًا عندما تنتهي العملية الأخيرة. بعد ذلك ، يمكنك استخدام خيارات سطر الأوامر لإنشاء نظام ملفات الجذر وبيئة العملية والأمر للتنفيذ في مساحة الاسم.
يوجد تسلسل أوامر عرض أكبر في الكود المصدري ، ولكن يوجد هنا إصدار صغير ينفذ قذيفة جديدة تعيد استخدام الملف /usr.
BWRAP-RO-bind /usr /usr-symlink usr /lib64 /lib64-Broc /Proc-dev /dev-share-pid bash هذا مثال غير مكتمل ، ولكنه مفيد للأغراض التوضيحية. في كثير من الأحيان ، بدلاً من إنشاء حاوية باستخدام شجرة نظام الملفات المضيف ، تريد الاشتراك في chroot. هناك ، بدلاً من إنشاء LIB64 -> usr/lib64 الرابط الرمزي ، قد يكون TMPFS قد أنشأته بالفعل في الجذر الوجهة.
الهدف من BubbleWrap هو تنفيذ تطبيق في مربع رملي ، حيث تقيد الوصول إلى أجزاء من نظام التشغيل أو بيانات المستخدم ، مثل دليل البدء.
تقوم BubbleWrap دائمًا بإنشاء مساحة جديدة لأسماء التجميع ، ويمكن للمستخدم تحديد الأجزاء التي يجب أن تكون مرئية في صندوق الرمل. سيتم تثبيت أي من هذه الدلائل المحددة بواسطة شكل محدد مسبقًا ويمكن القيام به فقط القراءة.
بالإضافة إلى ذلك ، يمكنك استخدام وظائف kernel هذه:
مسافات اسم المستخدم (clone_newuser): هذا يخفي كل شيء باستثناء UID وعلبة الرمل الحالية. يمكن أن يغير أيضًا ما يجب أن تكون قيمة UID / GID في صندوق الرمل.
مسافات أسماء IPC (clone_newipc): سيحصل مربع الرمل على نسخته الخاصة من جميع أشكال مؤشر أسعار المستهلك المختلفة ، مثل الذاكرة المشتركة SYSV ومصابيح المرور.
مسافات أسماء PID (clone_newpid): لن يرى صندوق الرمل أي عملية خارج صندوق الرمل. بالإضافة إلى ذلك ، ستقوم BubbleWrap بتنفيذ Trivial PID1 داخل حاويةها للتعامل مع متطلبات جني الأطفال في صندوق الرمال. هذا يتجنب ما يعرف الآن باسم مشكلة Docker Pid 1.
المساحات dehttp: //linux.die.net/man/2/clone أسماء الشبكة (clone_newnet): لن يرى Sandbox الشبكة. بدلاً من ذلك ، سيكون لديك مساحة اسم الشبكة الخاصة بك مع جهاز حلقة مقلوب فقط.
مساحة أسماء UTS (clone_newuts): سيكون لدى المربع الرملي اسم المضيف الخاص به.
مرشحات SECCOMP: يمكن أن تمر مرشحات SECCOMP التي تحد من المكالمات على النظام الذي يمكن تنفيذه في منطقة الاختبار. لمزيد من المعلومات ، راجع SecComp.
يشبه Firejail Flatpak قبل أن يتم تقسيم BubbleWrap إلى شعور بأنه يجمع بين أداة setuid مع العديد من وظائف صندوق Sandboxing المحددة. على سبيل المثال ، يعرف Firejail Pulseaudio ، بينما BubbleWrap لا.
يعتقد مؤلفو BubbleWrap أنه من الأسهل بكثير مراجعة برنامج setuid صغير والحفاظ على خصائص مثل تصفية Pulseaudio كعملية دون امتيازات ، كما هو الحال الآن في Flatpak.
بالإضافة إلى ذلك ، يعتقد cgwalters أن محاولة تضمين طرق الملفات في القائمة البيضاء هي فكرة سيئة بالنظر إلى الطرق التي لا تعد ولا تحصى التي يتعين على المستخدمين من خلالها معالجة الطرق والطرق التي لا حصر لها يمكن لمسؤولي النظام تكوين نظام. تتمثل نهج BubbleWrap في الاحتفاظ فقط ببعض إمكانيات Linux المحددة مثل Cap_sys_admin ، ولكن دائمًا ما يصل إلى نظام الملفات مثل UID. هذا يغلق تماما هجمات Tocttou وغيرها.
يتطلب Sandstorm.io مسافات لأسماء المستخدمين دون امتيازات لتكوين صندوق الرمل الخاص به ، على الرغم من أنه يمكن أن يتكيف بسهولة للعمل في وضع setuid. يعتقد cgwalters أن رمزها جيد جدًا ، لكن لا يزال من المنطقي التوحيد في BubbleWrap. ومع ذلك ، فإن Kentonv (من Sandstorm) يشعر أنه على الرغم من أن هذا أمر منطقي من حيث المبدأ ، فإن تكلفة التغيير تتجاوز الفوائد العملية في الوقت الحالي. يمكن إعادة تقييم هذا القرار في المستقبل ، ولكن اليوم لا يتم تطبيقه بنشاط.
تعمل RunC حاليًا على دعم الحاوية دون جذر ، دون الحاجة إلى أي امتياز آخر أثناء تثبيت RunC (باستخدام مسافات اسم المستخدم دون امتيازات بدلاً من setuid) ، وإنشاء الحاويات وإدارتها. ومع ذلك ، فإن الوضع القياسي لاستخدام RUNC يشبه systemd nspawn الذي تم تصميمه ليتم استدعاؤه بواسطة الجذر.
يعتقد مؤلفو BubbleWrap أن RunC و Systemd-Nspawn غير مصممين لتصبح setuid ، وبعيدا عن الاعتراف بهذه الطريقة. ومع ذلك ، مع الحاويات دون جذر ، يمكن لـ RunC الامتثال لبعض حالات الاستخدام المقبولة بواسطة BubbleWrap (مع فائدة إضافية تتمثل في كونها وقت تنفيذ OCI كامل وموحد).
BINCTR هو مجرد مظروف لـ RUNC ، لذلك يرث جميع تعويضات التصميم الخاصة به.
