كيفية عدم السماح الخفي عامل الميناء لتركيب نظام الملفات الجذر المضيف في الحاوية

العربية
#1

لدي إعداد الحاوية التالية.

على خادم معدني عارية يتم تثبيت اثنين من الشياطين عامل الميناء وتشغيلها.

  1. عامل الميناء الرئيسي الخفي يدير حاويات طلبي تعريض 80/443 إلى العالم الخارجي.
  2. البرنامج المساعد عامل الميناء الخفي يدير بعض الحاويات التي يقدمها العميل والتي تتواصل مع طلبي عبر 80/443.

أود منح العميل حق الوصول إلى واجهة برمجة التطبيقات (2376) من البرنامج المساعد عامل الميناء الخفي بحيث يمكن للعميل نشر / بدء / إيقاف حاوياته الخاصة. سيتمكن العميل فقط من الوصول إلى واجهة برمجة التطبيقات وليس إلى المضيف (سش).

المشكلة التي أواجهها حاليا هي ، ماذا لو كان العملاء يديرون حاوية تفعل شيئا غير آمن مثل docker run -v /:/host/root Ubuntu rm -rf /host/root.

سؤالي هو ماذا يمكنني أن أفعل لمنع البرنامج المساعد عامل الميناء الخفي من تصاعد الجذر / أو أي دليل آخر خارج /home/user/,

  • هل هو خيار لبدء الخفي عامل الميناء في /home/user/?
  • هل يمكنني استخدام بعض لسم (وحدات الأمن لينكس سيلينوكس / أبارمور) السحر لمنع الخفي عامل الميناء لتركيب بعض أو كل مسارات المضيف باستثناء المستخدمين المنزل أو فار/عامل الميناء/ليبس?
  • يمكن --userns-remap مساعدتي لتحقيق هدفي?
  • هل هي أي خيارات أخرى متاحة باستثناء نظام رصد السفن?

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

#2

سيمنع سيلينوكس أي شيء لم يتم تصنيفه بشكل صحيح ليتم تركيبه كمجلد داخل حاوية عامل ميناء ، كدليل ، هنا باستخدام ملف واحد ، تنطبق نفس السياسة على الدلائل:

$ sestatusSELinux status:                 enabledSELinuxfs mount:                /sys/fs/selinuxSELinux root directory:         /etc/selinuxLoaded policy name:             targetedCurrent mode:                   enforcingMode from config file:          enforcingPolicy MLS status:              enabledPolicy deny_unknown status:     allowedMax kernel policy version:      30

باستخدام ملف العينة:

$ cat sample_script.sh echo 'Hello, world'

سياق الأمان الافتراضي هو:

$ ls -lrtZ sample_script.sh -rw-------. 1 david david unconfined_u:object_r:user_home_t:s0 20 Oct  3 17:18 sample_script.sh

محاولة استخدام هذا الملف داخل حاوية فشل كما هو متوقع:

$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.shbash: sample_script.sh: Permission denied

وسيتم تسجيل رفض أفك:

$ sudo ausearch -m avc -ts recenttime->Mon Oct  3 17:39:28 2016type=AVC msg=audit(1475512768.444:784): avc:  denied  { read } for  pid=28720 comm="bash" name="sample_script.sh" dev="dm-13" ino=101062112 scontext=system_u:system_r:svirt_lxc_net_t:s0:c457,c992 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0

بعد تغيير سياق الأمان إلى عامل ميناء واحد يمكن استخدامه:

$ sudo chcon -Rt svirt_sandbox_file_t sample_script.sh$ ls -lrtZ sample_script.sh -rw-------. 1 david david unconfined_u:object_r:svirt_sandbox_file_t:s0 20 Oct  3 17:18 sample_script.sh

الحاوية لديها الآن حق الوصول إلى الملف:

$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.shHello, world

مزيد من المعلومات حول عامل الميناء وسيلينو في وثائق ريد هات الرسمية و هذه المقالة بقلم دان والش.

#3

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

#4

ماذا عن أبارمور هل من الممكن هناك كذلك?

#5

لا أصدق ذلك. لم أسمع أبدا عن قدرة أبارمور على فعل أي شيء من هذا القبيل. إنها تقنية مختلفة نوعا ما وأقل أمانا، كما تعلم.