Co sprawia, że ​​systemd-nspawn nadal „nie nadaje się do bezpiecznych konfiguracji kontenerów”?

Jest to podane na stronie podręcznika systemd-nspawn

Należy pamiętać, że pomimo zastosowania tych środków bezpieczeństwa systemd-nspawn nie nadaje się do bezpiecznych konfiguracji kontenerów. Wiele funkcji bezpieczeństwa można obejść i dlatego są one przede wszystkim przydatne w celu uniknięcia przypadkowych zmian w systemie hosta z kontenera. Przeznaczeniem tego programu jest debugowanie i testowanie, a także budowanie pakietów, dystrybucji i oprogramowania związanego z uruchamianiem systemu i zarządzaniem systemami.

To samo pytanie zostało następnie zadane na liście mailingowej w 2011 r. , Ale odpowiedź wydaje się nieaktualna.

systemd-nspawn zawiera kod do wykonania CLONE_NEWNETprzy użyciu --private-networkopcji teraz. To wydaje się pokrywać z prywatnej AF_UNIXemisji przestrzeni nazw, a Chyba CAP_NET_RAWi CAP_NET_BINDkwestie wymienione.

Jakie problemy pozostają w tym momencie i co robi na przykład LXC oprócz tego, co systemd-nspawnobecnie można zrobić?

LXC jest nieco lepszy, ponieważ może uruchamiać kontenery jako nieuprzywilejowani użytkownicy . Jest to możliwe w przypadku systemd-nspawn, ale tylko w scenariuszach, w których potrzebujesz tylko jednego użytkownika (zamiast wielu), co może być trudne lub mniej bezpieczne w przypadku wielu procesów w scenariuszach kontenerowych. Jeśli chcesz wiedzieć, dlaczego docker, lxc i systemd-nspawn z natury nie są solidnym mechanizmem bezpieczeństwa, przeczytaj to: https://opensource.com/business/14/7/docker-security-selinux . Zasadniczo kontenery nadal mają dostęp do jądra, a każdy exploit jądra przejmuje kontrolę nad całą maszyną. W monolitycznym jądrze, takim jak Linux, exploity jądra nie są rzadkie.