root داخل کانتینر و root میزبان ممکن است اختیارهای متفاوت داشته باشند. امشب سه لایهٔ capability، فیلتر syscall و policy اجباری را با process واقعی مقایسه می‌کنیم.

این جلسه بخشی از دورهٔ لینوکس ۳۰۵ در ۶۰ شب است.

جایگاه در دوره: هدف‌های 352.1 آزمون 305-300.

محیط: VM containers و بستهٔ libcap2-bin؛ نمونه‌های runtime بعد از نصب Docker/LXD اجرا می‌شوند. این جلسه پایهٔ تحلیل آن‌هاست.

capsh --print
cat /proc/self/status
sudo capsh --drop=cap_net_raw -- -c 'capsh --print'

bounding/effective/permitted set یکسان نیستند. کاهش CAP_NET_RAW می‌تواند ساخت raw socket را محدود کند، ولی تمام ارتباط شبکه را نمی‌بندد. namespace scope نیز معنای capability را تغییر می‌دهد.

فیلتر و policy#

seccomp انتخاب syscall و برخی argumentها را محدود می‌کند؛ مسیر فایل را مانند AppArmor نمی‌فهمد. SELinux label/type و AppArmor profile روی resource access policy اعمال می‌کنند. NoNewPrivileges مسیر افزایش اختیار بعد exec را محدود می‌کند، نه همهٔ اختیارهای فعلی را.

برای process کانتینر در شب ۴۶، host PID را از docker inspect بگیر و CapEff، NoNewPrivs و Seccomp در /proc/PID/status را ثبت کن. داخل کانتینر same PID namespace numbering متفاوت است. AppArmor/SELinux label runtime را هم با inspect و log میزبان ببین.

آزمون: workload بدون capability اضافی روی پورت داخلی بالا باید کار کند. خطای بازکردن raw socket یا فایل غیرمجاز را با cause مناسب ثبت کن؛ یک 403 برنامه به‌تنهایی evidence MAC نیست.

بازگشت: capsh child بعد exit از بین می‌رود؛ host set را دائمی تغییر نداده‌ایم. در failure کانتینر، –privileged یا seccomp=unconfined راه حل عمومی نیست؛ نیاز واقعی را محدود کن.

پرسش: چرا حذف capabilityها، خطر mount writable /etc میزبان را به‌طور کامل رفع نمی‌کند؟

منبع: capabilities ، seccomp ، امنیت Docker .