Bubblewrap

العديد من أدوات تشغيل الحاويات مثل systemd-nspawn وdocker وغيرها تركّز على توفير بنية تحتية لمسؤولي الأنظمة وأدوات التنسيق (مثل Kubernetes) لتشغيل الحاويات.

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

مساحات أسماء المستخدمين

هناك ميزة في نواة لينكس تسمى مساحات أسماء المستخدمين تسمح للمستخدمين غير المميزين باستخدام ميزات الحاويات. يستخدم Bubblewrap هذه الميزات لبناء بيئة العزل (sandbox)، مما يسمح لأي مستخدم باستخدام الأداة.

تاريخيًا، دعمت bubblewrap أيضًا وضع setuid للأنظمة التي لا تدعم مساحات أسماء المستخدمين غير المميزة. ومع ذلك، تمت إزالة هذا.

كود bubblewrap الأصلي وُجد قبل مساحات أسماء المستخدمين - فهو يرث كودًا من xdg-app helper والذي يُشتق بدوره بشكل بعيد من linux-user-chroot.

أمان النظام

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

بشكل خاص، يستخدم bubblewrap PR_SET_NO_NEW_PRIVS لتعطيل ثنائيات setuid، وهي الطريقة التقليدية للخروج من أشياء مثل بيئات chroot.

أمان بيئة العزل

bubblewrap هي أداة لبناء بيئات العزل. bubblewrap ليست بيئة عزل كاملة وجاهزة بسياسة أمان محددة.

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

أي برنامج يبني وسائط سطر الأوامر لـ bubblewrap (غالبًا إطار عمل أكبر مثل Flatpak أو libgnome-desktop أو sandwine أو سكربت مخصص) هو المسؤول عن تعريف نموذج الأمان الخاص به، واختيار وسائط سطر أوامر مناسبة لـ bubblewrap لتنفيذ هذا النموذج.

بعض جوانب أمان بيئة العزل التي تتطلب عناية خاصة موصوفة في قسم القيود أدناه.

المستخدمون

يمكن مشاركة هذا البرنامج من قبل جميع أدوات الحاويات التي تعمل دون صلاحيات الجذر، مثل:

• Flatpak
• rpm-ostree unprivileged
• bwrap-oci

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

التثبيت

يتوفر bubblewrap في مستودعات الحزم لمعظم توزيعات لينكس ويمكن تثبيته منها.

إذا كنت بحاجة إلى بناء bubblewrap من المصدر، يمكنك القيام بذلك باستخدام meson:

meson _builddir
meson compile -C _builddir
meson test -C _builddir
meson install -C _builddir

الاستخدام

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

يوجد سكربت تجريبي أكبر في الكود المصدري، لكن إليك نسخة مختصرة تشغّل صدفة جديدة مع إعادة استخدام /usr الخاص بالمضيف.

bwrap \
    --ro-bind /usr /usr \
    --symlink usr/lib64 /lib64 \
    --proc /proc \
    --dev /dev \
    --unshare-pid \
    --new-session \
    bash

هذا مثال غير مكتمل، لكنه مفيد لأغراض التوضيح. في أغلب الأحيان، بدلاً من إنشاء حاوية باستخدام شجرة نظام ملفات المضيف، قد ترغب في استهداف chroot. هناك، بدلاً من إنشاء الارتباط الرمزي lib64 -> usr/lib64 في tmpfs، ربما تكون قد أنشأته بالفعل في نظام الملفات الجذري الهدف.

العزل

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

ينشئ bubblewrap دائمًا مساحة أسماء تثبيت جديدة، ويمكن للمستخدم تحديد أجزاء نظام الملفات التي يجب أن تكون مرئية في بيئة العزل بالضبط. أي دليل من هذا القبيل تحدده يُثبَّت مع خيار nodev افتراضيًا، ويمكن جعله للقراءة فقط.

بالإضافة إلى ذلك يمكنك استخدام ميزات النواة هذه:

مساحات أسماء المستخدمين (CLONE_NEWUSER): يخفي هذا كل شيء باستثناء uid وgid الحاليين عن بيئة العزل. يمكنك أيضًا تغيير قيمة uid/gid داخل بيئة العزل.

مساحات أسماء IPC (CLONE_NEWIPC): ستحصل بيئة العزل على نسخة خاصة بها من جميع أشكال IPC المختلفة، مثل الذاكرة المشتركة SysV والإشارات (semaphores).

مساحات أسماء PID (CLONE_NEWPID): لن ترى بيئة العزل أي عمليات خارجها. بالإضافة إلى ذلك، سيشغّل bubblewrap عملية pid1 بسيطة داخل الحاوية للتعامل مع متطلبات جمع العمليات الفرعية في بيئة العزل. وهذا يتجنب ما يُعرف الآن باسم مشكلة pid 1 في Docker.

مساحات أسماء الشبكة (CLONE_NEWNET): لن ترى بيئة العزل الشبكة. وبدلاً من ذلك سيكون لها مساحة أسماء شبكة خاصة بها مع جهاز استرجاع (loopback) فقط.

مساحة اسم UTS (CLONE_NEWUTS): سيكون لبيئة العزل اسم مضيف خاص بها.

مرشحات Seccomp: يمكنك تمرير مرشحات seccomp التي تحد من استدعاءات النظام (syscalls) التي يمكن تنفيذها في بيئة العزل. لمزيد من المعلومات، انظر Seccomp.

القيود

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

• إذا لم تكن تقوم بتصفية أوامر TIOCSTI باستخدام مرشحات seccomp، فإن الوسيط --new-session مطلوب للحماية من تنفيذ أوامر خارج بيئة العزل (انظر CVE-2017-5226).

• كل شيء يُثبَّت داخل بيئة العزل يمكن استخدامه لتصعيد الامتيازات. على سبيل المثال، إذا قمت بربط مقبس D-Bus داخل بيئة العزل، فيمكن استخدامه لتنفيذ أوامر عبر systemd. يمكنك استخدام xdg-dbus-proxy لتصفية اتصالات D-Bus.

• بعض التطبيقات تنشر آليات العزل الخاصة بها، وقد يتم تقييدها بالقيود التي يفرضها عزل bubblewrap. على سبيل المثال، بعض متصفحات الويب التي تُهيئ عملياتها الفرعية عبر seccomp بحيث لا يكون لها وصول إلى نظام الملفات. إذا قمت بتقييد استدعاءات النظام ولم تسمح باستدعاء نظام seccomp، فلن يتمكن المتصفح من تطبيق هذه القيود. وبالمثل، إذا كانت هذه القواعد مُجمَّعة في ملف غير متاح داخل بيئة العزل، فلن يتمكن المتصفح من تحميل هذه القواعد من هذا الملف ولن يتمكن من تطبيق هذه القيود.

مقارنة مع مشروع مشابه: Firejail

Firejail تشبه Flatpak قبل فصل bubblewrap عنها من حيث أنها تجمع بين أداة setuid والكثير من ميزات العزل المخصصة لسطح المكتب. على سبيل المثال، يعرف Firejail عن Pulseaudio، بينما لا يعرف bubblewrap ذلك.

يعتقد مؤلفو bubblewrap أنه من الأسهل بكثير تدقيق برنامج setuid صغير، والاحتفاظ بميزات مثل تصفية Pulseaudio كعملية غير مميزة، كما يحدث الآن في Flatpak.

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

مقارنة مع مشروع مشابه: Sandstorm.io

يتطلب Sandstorm.io مساحات أسماء مستخدمين غير مميزة لإعداد بيئة العزل الخاصة به، على الرغم من أنه يمكن تكييفه بسهولة للعمل في وضع setuid أيضًا. يعتقد @cgwalters أن كودهم جيد إلى حد ما، لكن لا يزال من المنطقي التوحيد على bubblewrap. ومع ذلك، يرى @kentonv (من Sandstorm) أنه على الرغم من أن هذا منطقي من حيث المبدأ، فإن تكلفة التحويل تفوق الفوائد العملية في الوقت الحالي. يمكن إعادة تقييم هذا القرار في المستقبل، لكن لا يتم السعي وراءه بنشاط اليوم.

مقارنة مع مشروع مشابه: runc/binctr

runC يعمل حاليًا على دعم الحاويات بدون جذر، دون الحاجة إلى setuid أو أي امتيازات أخرى أثناء تثبيت runC (باستخدام مساحات أسماء مستخدمين غير مميزة بدلاً من setuid)، وإنشاء الحاويات وإدارتها. ومع ذلك، فإن الوضع القياسي لاستخدام runC مشابه لـ systemd nspawn من حيث أنه أداة مخصصة ليتم استدعاؤها بواسطة root.

يعتقد مؤلفو bubblewrap أن runc وsystemd-nspawn غير مصممين ليكونا setuid، وأنهما بعيدان عن دعم مثل هذا الوضع. ومع ذلك، مع الحاويات بدون جذر، ستتمكن runC من تلبية حالات استخدام معينة يدعمها bubblewrap (مع فائدة إضافية كونها بيئة تشغيل OCI معيارية وكاملة).

binctr هو مجرد غلاف لـ runC، لذا فهو يرث جميع مقايضات تصميمه.

ما قصة الاسم؟!

تم اختيار اسم bubblewrap للتعبير عن أن هذه الأداة تعمل كأصل للتطبيق (فهي تغلّفه بمعنى ما) وتنشئ طبقة واقية (بيئة العزل) حوله.

(قطة Bubblewrap من dancing_stupidity)