Що робить systemd-nspawn ще "непридатним для безпечних налаштувань контейнерів"?

Про це йдеться на сторінці man для systemd-nspawn

Зауважте, що навіть якщо ці заходи безпеки вжиті systemd-nspawn, не підходить для безпечних налаштувань контейнерів. Багато можливостей захисту можна обійти, і тому в першу чергу корисні, щоб уникнути випадкових змін хост-системи з контейнера. Передбачуване використання цієї програми - це налагодження та тестування, а також створення пакетів, дистрибутивів та програмного забезпечення, що стосується завантаження та управління системами.

Згодом саме це запитання було поставлено у списку розсилки в 2011 році , але, здається, відповідь застаріла.

systemd-nspawn містить код для виконання CLONE_NEWNETза допомогою --private-networkпараметра зараз. Це, мабуть, охоплює AF_UNIXпроблему приватного простору імен, і, мабуть, згадуються CAP_NET_RAWі CAP_NET_BINDпроблеми.

Які проблеми залишаються на даний момент і що робить, наприклад, LXC на додаток до того, що systemd-nspawnзараз можна зробити?

LXC трохи краще, оскільки він може запускати контейнери як непривітні користувачі . Це можливо для systemd-nspawn, але лише для сценаріїв, коли вам потрібен лише один користувач (замість кількох), що може бути важко або менш безпечно для багатопроцесових процесів у контейнерних сценаріях. Якщо ви хочете знати, чому docker, lxc та systemd-nspawn по суті не є надійним механізмом захисту, прочитайте це: https://opensource.com/business/14/7/docker-security-selinux . В основному контейнери все ще мають доступ до ядра, і будь-яке ядро ​​використовує контроль над всією машиною. У такому монолітному ядрі, як Linux, експлуатація ядра не рідкість.