systemd-nspawnがまだ「安全なコンテナのセットアップに適さない」のはなぜですか？
これは systemd-nspawn のmanページに記載されています
これらのセキュリティ対策は講じられていますが、systemd-nspawnは安全なコンテナー設定には適していません。セキュリティ機能の多くは回避される可能性があるため、主にコンテナーからホストシステムへの偶発的な変更を回避するのに役立ちます。このプログラムの使用目的は、デバッグとテスト、およびブートとシステム管理に関連するパッケージ、ディストリビューション、およびソフトウェアのビルドです。
この質問そのものが後に尋ねられた 2011年のメーリングリストで だが、答えは時代遅れのようだ。
systemd-nspawnには、現在CLONE_NEWNETオプションを使用して--private-networkを実行するコードが含まれています。これはプライベートなAF_UNIX名前空間の問題をカバーしているようです。私は、言及されているCAP_NET_RAWおよびCAP_NET_BINDの問題を推測しています。
この時点で残っている問題と、たとえばsystemd-nspawnが現在実行できることに加えて、たとえばLXCは何をしますか？
LXCはコンテナーを実行できるため、少し優れています非特権ユーザーとして。これはsystemd-nspawnで可能ですが、（複数の代わりに）1人のユーザーしか必要としないシナリオでのみ可能であり、コンテナーシナリオでのマルチプロセスでは困難または安全性が低下する可能性があります。 docker、lxc、systemd-nspawnが本質的に堅牢なセキュリティメカニズムではない理由を知りたい場合は、次をお読みください： https://opensource.com/business/14/7/docker-security-selinux =。基本的に、コンテナーは引き続きカーネルにアクセスでき、カーネルのエクスプロイトはマシン全体を制御できます。 Linuxのようなモノリシックカーネルでは、カーネルの悪用は珍しくありません。