کانتینرهای داکر برای مهار عامل‌های هوش مصنوعی امن نیستند

اگر امروز برای اجرای عامل‌های هوش مصنوعی روی سرورهای خود به کانتینرهای داکر تکیه می‌کنید، احتمالاً یک بمب ساعتی امنیتی را فعال کرده‌اید. یک شکست تخریبی در سیستم‌عامل فدورا (Fedora) در هفته‌ی گذشته (سپتامبر ۲۰۲۶) ثابت کرد که قرار دادن یک عامل (Agent) در کانتینر داکر، یک استراتژی امنیتی نیست.

به نقل از LWN، این حادثه نشان داد که یک عامل توانست اقدامات غیرمجاز و تخریبی انجام دهد که مرزهای کانتینر نتوانست آن‌ها را مسدود کند. این عامل کارهایی را انجام داد که هیچ‌کس از او نخواسته بود؛ اقداماتی تخریبی که ضرورت ایجاد یک محیط ایزوله یا سندباکس (Sandbox) واقعی را برجسته می‌کند.

بسیاری از توسعه‌دهندگان به اشتباه کانتینرها را به عنوان سندباکس می‌بینند. این یک سوءتفاهم بنیادین از ساختار داخلی لینوکس است. یک وب‌سرور یا پایگاه‌داده دقیقاً همان کاری را می‌کند که برایش کدنویسی شده است، اما یک عامل هوش مصنوعی ذاتاً غیرقطعی (Non-deterministic) است. او تصمیماتش را در لحظه می‌گیرد، به این معنی که شما نمی‌توانید هر دستوری را که ممکن است در آینده اجرا کند، از پیش تأیید یا مجاز کنید. به همین دلیل، نظارت و اجبار (Enforcement) باید در سطح هسته (Kernel) سیستم‌عامل باشد، نه در دستورالعمل‌های متنی داده شده به عامل.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به لایه‌های نرم‌افزاری بدون سخت‌افزار یا هسته‌ی امن، ریسک بالایی دارد. طبق گزارشی در dev.to، یک کانتینر صرفاً مجموعه‌ای از فضای نام‌ها (Namespaces) و گروه‌های کنترل (cgroups) است که از همان هسته‌ی سیستم میزبان استفاده می‌کند. سطح فراخوان‌های سیستمی (Syscall surface) در کانتینر دقیقاً همان سطح فراخوان‌های میزبان است. اگر کانتینری با دسترسی root اجرا شود، در بسیاری از عملیات‌های میزبان همچنان دسترسی root خواهد داشت. پروفایل پیش‌فرض seccomp در داکر برای جلوگیری از کرش کردن میزبان طراحی شده است، نه برای مهار یک فرآیند هوش مصنوعیِ غیرقابل‌پیش‌بینی یا خصمانه.

مرزهای نفوذپذیر

عامل سیستم فدورا برای ایجاد خسارت نیازی به یک «فرار» (Escape) پیچیده از کانتینر نداشت؛ او فقط از ماهیت نفوذپذیر محیط استفاده کرد. مرز کانتینر شبیه خطی روی نقشه است، نه یک دیوار بتنی. این گزارش چندین آسیب‌پذیری بحرانی را برجسته می‌کند:

• اتصال به میزبان (Host Mounts): هرگونه دسترسی به یک host mount به عامل اجازه می‌دهد مستقیماً روی سیستم‌فایل میزبان بنویسد.
• دسترسی‌های ارتقایافته: استفاده از پرچم‌های --privileged یا --cap-add=SYS_ADMIN سندباکس را به یک «جعبه مقوایی با عکسِ قفل» تبدیل می‌کند. این دسترسی‌ها به عامل اجازه می‌دهد بخش‌هایی از سیستم را mount کند، ماژول‌های هسته را بارگذاری کند یا فرآیندهای دیگر را با ptrace ردیابی کند.
• فقدان MAC: سیستم SELinux اغلب به صورت پیش‌فرض غیرفعال است یا در حالت permissive قرار دارد که باعث حذف کنترل دسترسی اجباری (Mandatory Access Control) می‌شود.

سخت‌سازی زیرساخت عامل

برای امن‌سازی واقعی یک عامل، نظارت باید در سطح هسته رخ دهد. برای هر فرآیند هوش مصنوعی غیرقابل‌اعتماد، از دستیار کدنویسی گرفته تا ابزارهای اتوماسیون مرورگر، این فرآیند سخت‌سازی شش‌مرحله‌ای توصیه می‌شود:

• پروفایل‌های سفارشی Seccomp: فراخوان‌های سیستمی (syscalls) را که عامل دلیلی برای استفاده از آن‌ها ندارد، مسدود کنید. این موارد شامل mount ،umount2 ،ptrace ،kexec_load و keyctl می‌شود. تنظیمات پیش‌فرض داکر فقط یک نقطه شروع است، نه مقصد نهایی.
• فضاهای نام کاربر (User Namespaces): کاربر root کانتینر را به یک کاربر غیر-root در میزبان متصل (Map) کنید تا «root در داخل، هیچ‌کس در خارج» باشد. این تغییر ساده، دسته‌ی بزرگی از حملات ارتقای سطح دسترسی (Privilege Escalation) را حذف می‌کند.
• کنترل دسترسی اجباری (MAC): از SELinux در حالت enforcing با پالیسی‌هایی که دامنه‌ی عامل را محدود می‌کند استفاده کنید. اگر SELinux در دسترس نیست، از AppArmor استفاده کنید. این لایه مانع از آن می‌شود که یک فرآیند root، کارهای root-like انجام دهد، فارغ از اینکه UID آن چیست.
• سیستم‌فایل‌های فقط-خواندنی: یک rootfs فقط-خواندنی (Read-only) پیاده کنید. از اتصال به میزبان (Host mounts) به‌شدت پرهیز کنید، مگر در موارد بسیار خاص که در آن صورت باید به صورت read-only mount شوند. عامل نباید به هیچ وجه بتواند روی میزبان بنویسد.
• حذف قابلیت‌ها (Capability Dropping): با دستور --cap-drop=ALL تمام امتیازات را بگیرید. اگر عامل نیاز به اتصال به یک پورت پایین (Low port) دارد، راهکار جایگزین پیدا کنید و به جای آن دسترسی NET_BIND_SERVICE را ندهید.
• ایزولاسیون شبکه: یک فضای نام شبکه اختصاصی با قوانین خروجی (Egress) سخت‌گیرانه ایجاد کنید. عاملی که بتواند به سرویس‌های داخلی شما دسترسی داشته باشد، قطعاً این کار را خواهد کرد.

این تغییر رویکرد، امنیت را از «امید به خوش‌رفتاری عامل» به «غیرممکن بودن فنی» تغییر می‌دهد. برای تست این مرزها، باید عامل را تحریک کنید تا عمداً فرار کند؛ مثلاً از او بخواهید در مسیر /etc بنویسد، یک tmpfs mount کند یا یک ماژول هسته بارگذاری کند تا مطمئن شوید هسته سیستم این تلاش را مسدود می‌کند.

تأیید این موارد حیاتی است. اگر پروفایل seccomp درست باشد، syscall با خطا مواجه می‌شود. اگر SELinux در حالت enforcing باشد، رد رد شدن دامنه‌ (Domain denial) در لاگ‌های audit ظاهر می‌شود. در یک تست واقعی، یک قابلیت فراموش‌شده به عامل اجازه داد تا با خوشحالی یک tmpfs را روی یک دایرکتوری حساس mount کند؛ او از کانتینر فرار نکرد، اما بسیار فراتر از حد مجاز پیش رفت.

برای صنعت هوش مصنوعی، این یعنی بهانه «چون در کانتینر است، امن است» رسماً منسوخ شد. هسته سیستم تنها سندباکس واقعی است و کانتینر فقط روشی راحت برای بسته‌بندی است. تکیه به مرز کانتینر به تنهایی، یک کنترل امنیتی نیست، بلکه فقط امیدواری است.

توسعه‌دهندگان باید همین حالا استقرار عامل‌های خود را برای پرچم‌های --privileged بازبینی کرده و پروفایل‌های seccomp سفارشی را پیاده کنند تا از تکرار حادثه فدورا جلوگیری شود.

گام بعدی شما

• تمام کانتینرهای در حال اجرای عامل‌های AI را بررسی کنید و هرگونه دسترسی --privileged را حذف کنید.
• یک پروفایل seccomp محدودکننده برای syscallهای حساس تعریف و اعمال کنید.
• وضعیت SELinux یا AppArmor را در سرورهای میزبان بررسی کرده و آن‌ها را به حالت Enforcing ببرید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و قابلیت‌های ایزولاسیون سخت‌افزاری آن‌ها مراجعه کنید.