کانتینر ها از سیستم محافظت نمی کنند. خوانده و شنیده ام که بسیاری تصور می کنند که کانتینر های Docker به نوعی جعبه ابزار و برنامه های کاربردی هستند – بدین معنی که تصور می کنند می توانند برنامه ها را به صورت رندوم با استفاده از Docker بر روی سیستمشان اجرا کنند. آنها بر این باورند که کانتینر هایDocker حقیقتاً می توانند از سیستم و هاست آنها محافظت کنند.
- شنیده ام مردم می گویند که کانتینر های Docker به قدری امن هستند که گویی فرایندها را در VM و یا KVM جداگانه اجرا می کنید.
- می دانم که یرخی تصاویر رندوم را از Docker دانلود کرده و در هاست خود قرار می دهند.
- حتی دیده ام که سرور مجازی PaaS ( به غیر از سرور مجازی OpenShift ) به کاربران خود اجازه می دهند تا عکسهای خودشان را آپلود کرده و یک سیستم چند مستأجره (multi-tenant) ایجاد کنند.
- همکاری دارم که می گوید: ” Docker تقریباً کدهای رندوم را از اینترنت دانلود کرده و آنها را به عنوان کاربر root اجرا می کند. ”
دیگر تصور نکنید که Docker و هسته ی لینوکس ، از شما در مقابل بدافزار ها محافظت می کنند.
نگران شدید؟
اگر Docker را بر روی یک سیستم چند مستأجره اجرا نمی کنید و تدابیر امنیتی مناسب را برای خدماتی که در قالب یک کانتینر ارائه و اجرا می شوند ، به کار گرفته اید ، جایی برای نگرانی وجود ندارد. فقط تصور کنید فرایندها و برنامه های ویژه ای که در قالب کانتینر اجرا می شوند ، مانند همان فرایندها و برنامه های ویژه ای باشند که خارج از کانتینر اجرا می شوند.
بعضی به اشتباه تصور می کنند که استفاده از کانتینرها بهتر و سریع تر از اجرای ماشینهای مجازی است. کانتینر ها از نظر امنیتی بسیار ضعیف تر هستند ، که در ادامه ی مطلب به آن خواهیم پرداخت.
اگر شما نیز با من هم عقیده هستید ، با کانتینر های Docker باید به عنوان ” یک ابزار خدمت رسانی ” برخورد شود _ به این معنی که به گونه ای با کانتینری که سرور مجازی Apache در آن اجرا می شود ، برخورد شود که گویی سرور مجازی Apache بر روی خود سیستم شما اجرا می شود .
یعنی اقدامات زیر را انجام دهید:
- امتیازات ویژه را در کوتاهترین زمان ممکن حذف کنید.
- هر زمان که ممکن است برنامه های خود را به صورت non-root اجرا کنید.
- با root درون کانتینر مانند root خارج از کانتینر برخورد کنید.
در حال حاضر به همگان گفته می شود معیار استاندارد ایمنی سیستم بر اساس ارزیابی های بین المللی این است که با برنامه های ویژه ی داخل کانتینر و برنامه های ویژه ی خارج از آن یکسان برخورد شود.
تصاویر رندوم Docker را بر روی سیستم خود باز نکنید. از نظر من تحولات کانتینر Docker از بسیاری جهات به تحولات سیستم لینوکس در سال ۱۹۹۹ شبیه است. در آن زمان هر مدیر شبکه ای که در مورد سیستم جدید و جالب لینوکس می شنید ، این اقدامات را انجام می داد:
- در اینترنت در یا هر سایت دیگر که می توانست به دنبال پکیج این برنامه می گشت .
- برنامه را بر روی سیستم خود دانلود می کرد.
- برنامه را از طریق RPM یا make install بر روی سیستم خود نصب می کرد.
- ·برنامه را به عنوان یک برنامه ی ویژه و ممتاز اجرا می کرد.
چه مشکلی می توانست پیش بیاید؟
حدود دو هفته بعد ، این مدیران اخباری در مورد یک بدافزار که برنامه ی zlib را درگیر می کند ، شنیدند و مجبور به پیگیری و بررسی صحت این خبر شدند ؛ و با اینکه امید داشتند و دعا می کردند که این خبر صحیح نباشد ، اما در هر حال نرم افزار آنها در خطر بود.
اینجا بود که Red Hat و تعدادی از همکاران مورد اعتماد آنها برای سر و سامان دادن به اوضاع وارد صحنه شدند. Red Hat امکانات زیر را در اختیار مدیران شبکه ها گذاشت:
- یک مرجع مطمئن برای دریافت نرم افزار تا بتوانند نرم افزارهای مورد نیاز خود را از آنجا دانلود کنند.
- یک برنامه ایمنی آپدیت شده تا بتوانند آسیبهای وارده را ترمیم کنند.
- یک تیم ایمنی پاسخگو تا آسیبهای وارد شده را پیدا کرده و کنترل کنند.
- تیمی از مهندسین که بسته های نرم افزاری را کنترل و بررسی کنند و ایمنی آنها را افزایش دهند.
- صدور گواهی Common Criteria تا ایمنی سیستمهای عامل را کنترل کنند.
فقط از کانتینر های ارائه شده از منابع مطمئن استفاده کنید. من عقیده دارم که بهتر است شما همچنان بسته های نرم افزاری و پکیج کدهای خود را از همان منابع قبلی تهیه کنید. اگر مطمئن نیستید که کدها از منابع داخلی یا خارجی مورد اعتماد به دست شما رسیده اند ، صرفاً به تکنولوژی کانتینر برای حفاظت از هاست خود اطمینان نکنید.
پس مشکل چیست؟ چرا کانتینرها از سیستم محافظت نمی کنند ؟
مشکل بزرگ این است که سیستم لینوکس name space ندارد. در حال حاضر Docker از ۵ namespace برای تغییر و جایگزینی نمایش فرایندها در سیستم استفاده می کند : Process, Network, Mount, Hostname, Shared Memory
با اینکه این امر می تواند نوعی ایمنی نسبی برای کاربر ایجاد کند ، اما این ایمنی به اندازه ی ایمنی ایجاد شده در KVM جامع نیست. در محیط KVM هیچگاه فرایندها و برنامه های در حال اجرا در ماشین مجازی در ارتباط مستقیم با مرکز هاست نیستند. هیچ یک از این برنامه ها و فرایندها به فایلهای سیستمی مانند /sys ، /sys/fs و /proc/ دسترسی ندارند. در این محیط node دستگاه با مرکز KVM مرتبط است نه هاست. بنابراین برای اینکه یک فرایند یا برنامه بتواند در VM امتیاز ویژه داشته باشد ، باید بتواند از مرکز VM گذشته ، نقطه ی آسیب پذیر HyperVisor را یافته ، از سد کنترل های SELinux که در VM بسیار محکم هستند، عبور کرده و سرانجام به مرکز هاست حمله کند.
زمانی که برنامه ای را در کانتینر اجرا می کند ، درست مثل این است که در ارتباط مستقیم با هسته ی هاست هستید.
زیر مجموعه های اصلی هسته ی هاست( موارد زیر) namespace نیستند:
- SELinux
- Cgroups
- فایلهای سیستمی زیر مجموعه ی /sys
- ·/proc/sys ، /proc/sysrq-trigger ، /proc/irq ، /proc/bus
دستگاههای زیر نیز namespace نیستند :
- /dev/mem
- ابزارهای فایلهای سیستمی /dev/sd
- ماژولهای کرنل
اگر بتوانید به عنوان یک فرایند یا برنامه ی ویژه با یکی از این زیرمجموعه ها یا دستگاهها ارتباط برقرار کنید ، می توانید کل سیستم را در اختیار بگیرید.
