(免責事項:私は違います OpenVZ の権威。この回答は、私の通常の回答よりも独断的なものですので、お気軽に批判してください!)
OpenVZ は、カーネル全体と統合されていないという点で「より」安全である可能性があるため、攻撃対象領域が少し低くなります。ただし、基本的には OpenVZ が名前空間のインスピレーションとなり、最終的には LXC と Docker になりました。これらのより完全な解決策が、まあ、完全であるということが、長く続くとは思えません。
WhiteWinterWolf が指摘したように、大きな違いの 1 つは、LXC が最終的にユーザー名前空間を使用できるようになったことです。これにより、特権のないユーザーがコンテナーを実行できるようになり、コンテナーから抜け出す含まれるコードが特権のないユーザーの特権を保持できるようになります。また、名前空間ベースのコンテナーは、最終的に完全に SELinux でラベル付けされる可能性があります。通常、Docker コンテナーは既に存在しており、Dan Walsh は、含まれるプロセスに対してランダムに生成されたカテゴリを使用して、SELinux がコンテナー間の追加の分離レイヤーを自動的に強制する方法に取り組んでいます。
要約すると、コンテナの方が優れている理由は次のとおりです。-コンテナのブレイクアウトを部分的に阻止し（権限のないUIDに制限する）、コンテナ内の権限昇格を無関係にすることができます-コンテナはよりサポートされ、より積極的に開発されており、特にSELinux サポートから大きな恩恵を受けます。
さらに悪いのは、- TCB がカーネル全体にわたって非常に大きく、バグが時々発生し、エクスプロイトやブレイクアウトにつながる.- ユーザーの名前空間は、私には一種のエッジ ケースのように感じます。通常、SCI のバグ (ブレイクアウト後に再現できる) または特権サービスに対する混乱した代理攻撃 (そもそもコンテナーの外に存在し続ける可能性が高い) を介して特権エスカレーションを達成します。そのため、コンテナを実行する UID を実行中のコンテナに厳密に制限する必要があります。
要約すると、多層防御を実践し続け、包含されたプロセスが外部の世界とどのように相互作用するか、およびコンテナーをどのように実行するかについて考え続けてください。違いはありますが、ご覧のとおりごくわずかです。