حاوية تطبيق Docker مقابل حاوية LXC مخصّصة للخدمات المنزلية ذات الامتيازات: أيّهما ينطوي على مخاطر أكبر؟

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

قارن حدود النشر المتكافئة أولًا

يُعد Docker وLXC من تقنيات حاويات Linux التي تشترك في نواة المضيف، لكنهما عادةً ما يعبئان وحدات مختلفة. يعزل Docker عادةً تطبيقًا واحدًا أو مكدس Compose. أما LXC فينشئ حاوية نظام خفيفة بفضل مستخدميها وقاعدة حزمها وخدماتها ونظام ملفات نظام التشغيل الخاص بها.

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

تتناول مقارنة ZimaSpace الحالية بين Docker والتثبيتات الأصلية داخل LXC مسائل التعبئة والصيانة. تعزل هذه المقالة قرار الأمان عندما تطلب الخدمة امتيازات تُضعف حدود الحاويات العادية.

ابدأ بالامتياز المحدد الذي تتطلبه الخدمة

قد تعني عبارة «خدمة منزلية مميّزة» عدة أذونات غير مترابطة: قراءة جهاز USB تسلسلي، أو استخدام عقدة عرض GPU، أو التحكم في واجهة شبكة، أو تركيب نظام ملفات، أو ربط منفذ منخفض الرقم، أو الوصول إلى Bluetooth، أو قراءة بيانات SMART، أو إدارة حاويات أخرى. ولا تحمل هذه الأذونات الدرجة نفسها من المخاطر على المضيف.

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

إذا كانت الخدمة تحتاج فقط إلى /dev/dri/renderD128، أو مسارًا واحدًا للتسلسل بحسب المعرّف، أو دليل إعدادات واحدًا للقراءة فقط، يمكن لكل من Docker وLXC إتاحة ذلك المورد المحدود. ويصبح الفرق الأمني مهمًا عندما يتطلب النشر قدرات واسعة أو عدة واجهات مع المضيف.

ينشئ LXC غير المميّز حدًا أقوى لتعيين الجذر

في LXC غير المميّز، يُعيَّن UID 0 داخل الضيف إلى UID فرعي عادي على مضيف Proxmox. وقد تبدو العملية كأنها تعمل بصلاحيات الجذر داخل الحاوية، مع افتقارها إلى هوية جذر المضيف خارج مساحة أسماء المستخدمين الخاصة بها. ويقلل ذلك من عواقب كثير من أخطاء أذونات الملفات وبعض عمليات الهروب من الحاوية.

يصف مشروع Linux Containers تعيين جذر LXC غير المميّز بأنه الحدّ الأمني الأساسي في التصميم، مع إضافة AppArmor وseccomp والقدرات قيودًا إضافية على العمليات وموارد المضيف.

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

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

يمكن لـ Docker تقليل مخاطر الجذر دون نقل التطبيق إلى LXC

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

يشغّل الوضع عديم الجذر في Docker كلًا من العفريت والحاويات من دون امتيازات جذر المضيف. ويمكن أن يقلل ذلك من مخاطر العفريت وبيئة التشغيل عندما يدعم التطبيق وميزات التخزين أو الشبكات المطلوبة قيود الوضع عديم الجذر.

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

يمكن لمقبس Docker محو حدود التطبيق

تطلب بعض لوحات المعلومات، وأدوات التحديث التلقائي، وأدوات النسخ الاحتياطي، وخدمات المراقبة الوصول إلى /var/run/docker.sockيتيح المقبس للعميل توجيه عفريت Docker على المضيف لإنشاء حاويات، وتركيب مسارات المضيف، وإتاحة الأجهزة، وتغيير الشبكات. لذلك قد تتمكن خدمة مخترقة من التحكم في المضيف بشكل غير مباشر، من دون استغلال هروب من النواة.

يوضح تحليل Netdata سبب تصرف الوصول إلى مقبس Docker كما لو كان إدارةً للمضيف: إذ تطلب العملية من العفريت ذي الامتيازات تنفيذ إجراءات قوية على المضيف بالنيابة عنها، من دون هروب تقليدي من الحاوية.

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

يرجّح ربط الأجهزة النموذجَ ذي طبقات الأذونات الأقل

يمكن تمرير وحدة معالجة رسومات (GPU)، أو منسّق USB، أو موالف، أو مُسرّع Coral، أو مزوّد طاقة غير منقطع (UPS)، أو محوّل تسلسلي إلى أيٍّ من عمليتي النشر. في Docker المباشر، يتيح المضيف الوصول إلى الجهاز لحاوية التطبيق. وفي LXC، يتيح Proxmox الوصول إلى الجهاز لحاوية النظام، التي تشغّل الخدمة أصلاً، أو قد تمرّره مجددًا إلى Docker متداخل.

قد يكون LXC مخصصًا أنظف عندما تحتاج عدة عمليات مترابطة إلى الجهاز نفسه، وعندما ينبغي لمستخدمي Linux أو مجموعاته إدارة الوصول. وقد يكون Docker أنظف عندما تحتاج صورة واحدة إلى جهاز واحد، ويُوصَف الربط مباشرةً في Compose.

تجنب منح أيٍّ من الحاويتين إمكانية الوصول إلى جميع الأجهزة لمجرد صعوبة منح إذن لجهاز واحد. ويشير Proxmox إلى أن أمان LXC يجمع بين مساحات الأسماء وAppArmor وseccomp وقيود الأجهزة. ويؤدي الوصول الواسع إلى الأجهزة إلى إزالة جزء من هذا الحدّ الفاصل متعدد الطبقات، تمامًا كما يحدث في وضع Docker ذي الامتيازات.

تنقل عمليات ربط أدلة المضيف المخاطر في اتجاهات مختلفة

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

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

استخدم عمليات تحميل للقراءة فقط عندما يكون ذلك ممكنًا، وافصل الإعدادات عن البيانات الضخمة، وتجنب ربط جذر المضيف، /proc, /sys, /devأو أدلة بيانات Docker على نطاق واسع. وإذا كان يجب على الخدمة إعادة كتابة بيانات NAS المحمية، فلا يمكن لعزل التطبيقات أن يحل محل اللقطات الاحتياطية والنسخ المستقلة.

يمكن لامتيازات الشبكة إنشاء نطاق أوسع للأضرار من الوصول إلى نظام الملفات

قد تطلب الخدمات المنزلية، مثل بوابات VPN، ومرشحات DNS، وأدوات اكتشاف الشبكة، وتكاملات Home Assistant، وأنظمة المراقبة، استخدام شبكة المضيف أو المقابس الخام أو التقاط الحزم أو تعديل الجدار الناري أو الوصول إلى عدة شبكات VLAN. ويمكن لهذه القدرات كشف حركة المرور والسماح للخدمة بالتأثير في الأجهزة الأخرى.

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

اختر الحدّ الفاصل الذي يتيح لك تحديد أضيق مسار للشبكة. فقد يؤدي استخدام VLAN منفصلة، وعنوان مخصص، وقواعد جدار ناري صريحة، ومنع الوصول إلى إدارة NAS، إلى تقليل المخاطر بدرجة أكبر من تبديل تقنيات الحاويات مع إبقاء الخدمة على كل شبكة موثوقة.

تفشل LXC ذات الامتيازات وDocker ذات الامتيازات بطرق مختلفة

تتلقى حاوية Docker ذات الامتيازات الكاملة قدرات واسعة في Linux وإمكانية الوصول إلى الأجهزة عبر خدمة Docker تعمل بصلاحيات الجذر. أما LXC ذات الامتيازات فتمنح مساحة مستخدم كاملة للضيف، مع علاقة هوية أقرب بكثير إلى جذر المضيف. ولا ينبغي التعامل مع أيٍّ منهما كحاوية تطبيقات عادية غير مميّزة.

تحذّر إرشادات Tigera الأمنية من أن الوضع المميّز في Docker يتجاوز ضوابط العزل الرئيسية. كما تحذّر مناقشات مجتمع Proxmox من أن تمكين التعشيش أو إتاحة وصول واسع إلى نظام ملفات المضيف داخل LXC قد يكشف سطحي /proc و/sys على المضيف عند تهيئته بإهمال.

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

تحدد التحديثات والاسترداد ما إذا كان العزل سيظل قابلًا للاستخدام

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

يجعل LXC المخصص بيئة التشغيل قابلة للاستبدال باعتبارها ضيفًا واحدًا في Proxmox. ويمكن نسخ قاعدة حزمها وملفات خدماتها ومستخدميها وتعيينات أجهزتها احتياطيًا معًا. يكون الاسترداد نظيفًا عندما تُوثّق عمليات الربط وخرائط UID وأجهزة المضيف وقواعد الشبكة خارج الضيف.

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

استخدم اختبار تقليل الامتيازات قبل اختيار Docker أو LXC

1. أدرج كل جهاز ومسار على المضيف وإمكانية وشبكة وواجهة API وميزة نواة يطلبها الخدمة.
2. أزل الوضع المميّز بالكامل، ثم أعد كل متطلب واحدًا تلو الآخر.
3. شغّل التطبيق كمستخدم غير جذر أو داخل LXC غير مميّز حيثما كان ذلك مدعومًا.
4. استبدل عمليات الربط القابلة للكتابة والواسعة بمسارات ضيقة للقراءة فقط أو خاصة بمجموعات البيانات.
5. أزل الوصول إلى مقبس Docker أو ضع وكيلًا مقيّدًا بين الخدمة والعفريت.
6. اختبر افتراضات الاختراق بالتحقق من الملفات والأجهزة والشبكات الموجودة على المضيف التي لا يزال الوصول إليها ممكنًا.
7. استعد الخدمة على مضيف Docker أو LXC نظيف باستخدام إعدادات مُرقّمة الإصدارات فقط.

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

ما الحد الفاصل المناسب للخدمة المنزلية المميّزة؟

اختر حاوية تطبيق Docker عندما

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

اختر LXC غير مميّز مخصصًا عندما

اختر LXC عندما تحتاج الخدمة إلى بيئة Linux أكثر اكتمالًا، أو عدة برامج خدمية مترابطة، أو تكامل مباشر مع systemd، أو أذونات معقدة لمجموعات الأجهزة. حافظ على تعيين مساحة أسماء المستخدمين، وأبقِ قيود AppArmor وseccomp مفعّلة، ووثّق كل نقطة تحميل وكل تعيين للأجهزة على المضيف.

اختر آلة افتراضية بدلًا من ذلك عندما

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

الأسئلة الشائعة

هل LXC مميّز أكثر أمانًا من حاوية Docker مميّزة؟

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

هل يضيف تشغيل Docker داخل LXC غير مميّز طبقة أمان أخرى؟

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

هل تحتاج الخدمات المنزلية المقتصرة على الشبكة المحلية إلى حاويات غير مميّزة؟

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

الحكم النهائي

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