داکر (Docker) همچنان محبوب‌ترین محیط اجرای کانتینر (Container Runtime) برای بسیاری از کاربران و آزمایشگاه‌های خانگی است؛ اما یک ویژگی پیش‌فرض در آن می‌تواند ریسک امنیتی جدی ایجاد کند: اجرای سرویس daemon و کانتینرها با دسترسی root.
ریسک پیش‌فرض: داکر و دسترسی روت
در نصب تازه داکر، فرایند daemon با نام dockerd به یک Unix socket متصل می‌شود که مالک آن کاربر root است. اگر در Dockerfile پارامترهای مشخصی تغییر داده نشود، محیط‌هایی که dockerd ایجاد می‌کند نیز با دسترسی root اجرا می‌شوند. همین موضوع می‌تواند دامنه آسیب (Blast Radius) کانتینرهای آسیب‌پذیر را افزایش دهد.
چرا اشتراک کرنل مسئله را جدی‌تر می‌کند
برخلاف ماشین‌های مجازی (Virtual Machines) که کرنل و سیستم‌عامل تازه‌ای شبیه‌سازی می‌کنند، کانتینرها کرنل (Kernel) را با ماشین میزبان (Host) به اشتراک می‌گذارند. وقتی dockerd دسترسی کامل root به سیستم دارد، کد مخرب در یک تصویر کانتینر (Container Image) می‌تواند راحت‌تر از محدوده کانتینر خارج شود و به میزبان آسیب بزند. همچنین اگر به‌اشتباه یک دایرکتوری سیستمی را به کانتینر سوار کنید (Mount)، سرویس متن‌باز شما به فایل‌های حیاتی آن پوشه دسترسی سوپریوزر (Superuser) پیدا می‌کند.
راهکار پیشنهادی: حالت بدون روت (Rootless Mode)
دو روش برای امن‌تر کردن آزمایش‌های داکر وجود دارد: تغییر Dockerfile برای اجرای کانتینر با دسترسی غیر root، یا بازنویسی کاربر در فایل‌های docker run یا compose.yml. اما این کارها برای هر کانتینر تکراری و خسته‌کننده می‌شود. راهکار بهتر، فعال‌سازی حالت rootless است که مشکل دسترسی سوپریوزر dockerd را نیز برطرف می‌کند. در این حالت، کانتینر و daemon پشت یک کاربر بدون امتیاز ویژه قرار می‌گیرند و محیط داکر معیوب نمی‌تواند به دسترسی کامل root روی میزبان برسد.
برای فعال‌سازی یک‌باره حالت rootless می‌توان از دستورهای زیر استفاده کرد:
- نصب uidmap: sudo apt install uidmap -y
- دریافت اسکریپت rootless: curl -fsSL https://get.docker.com/rootless | sh
- تنظیم مسیر: export PATH=/usr/bin:$PATH
- تعیین سوکت داکر: export DOCKER_HOST=unix:///run/user/1000/docker.sock
محدودیت‌های حالت Rootless
حالت rootless نیز بدون محدودیت نیست. در این حالت نمی‌توان پورت‌های ممتاز (Privileged Ports) زیر ۱۰۲۴ را برای کانتینرها نگاشت (Map) کرد. برای برنامه‌های بهره‌وری معمولی، ابزارهای آرشیو یا سرویس‌های پشتیبان‌گیری مشکل بزرگی نیست، اما ابزارهای شبکه وضعیت متفاوتی دارند. برای نمونه، Pi-hole برای سرویس DNS اصلی به پورت 53 نیاز دارد و اجرای آن در حالت rootless نیازمند تغییر برخی فایل‌های پیکربندی است. علاوه بر شبکه، ممکن است با محدودیت‌های ذخیره‌سازی (Storage) نیز روبه‌رو شوید، به‌ویژه اگر آزمایش‌ها شامل سوارسازی‌های (Mount) OverlayFS باشد. محدودکردن منابع کانتینرها از طریق cgroups v2 و استفاده از پروفایل‌های سفارشی AppArmor هم در این حالت دشوارتر است.
جمع‌بندی
با وجود این محدودیت‌ها، فعال‌سازی حالت rootless برای کاربرانی که با ابزارهای بهره‌وری، تصاویر کانتینر غیرمعمول و ابزارهای آرشیو داده کار می‌کنند، ایده منطقی و امن‌تری است. داکر به‌طور پیش‌فرض با دسترسی root اجرا می‌شود و همین ویژگی، ریسکی است که بسیاری از کاربران آن را دست‌کم می‌گیرند.