OpenVZと比較したLXCのセキュリティ
何年もの間、私は自分のサーバーでOpenVZを使用していますが、DebianとUbuntuのサポートは中止されました。現在のリリースは現在LXCに重点を置いているようですが、快適さの点では悪い考えではありません。
しかし、セキュリティについてはどうでしょうか？ LXCがOpenVZと同じレベルのプロセスとコンテナー分離を提供しないことを一度読んだことを覚えています。残念ながら、このドキュメントはもう見つかりませんが、少なくともLXCのデフォルト設定には、いくつかのセキュリティ問題がある可能性があることに同意します。たとえば、完全にカスタマイズされたrootfsで、（古いバージョンのLXCで）chvt 1を使用してLXCコンテナからホストの端末を変更し、Ctrl + Cを押すと、X11環境の再起動で終了しました。今日それを再現します。私は知っています。すべてのコンテナーソリューションは同じカーネルを使用しており、カーネルハックはコンテナーのブレイクアウトにつながる可能性があります。しかし、コンテナからホストや他のコンテナに影響を与えることはそれほど簡単ではありません。
OpenVZとLXCにはどの程度のセキュリティが期待できますか？
私のサーバーは一部のゲストポートをインターネットに公開しているので、この点については本当に気にしていますが、現在使用されているツールをアップグレードする必要があるため、決定を下す必要があります。私のサーバーには低パフォーマンスのCPUがあるため、KVMまたは同様のものを使用することはオプションではありません。
PS：私はvzctl 4.7.2-1での実際のOpenVZ実装について話しています。 vzctlの一部の新しい実装では、LXCテクニックを使用しています。
最初：両方のプロジェクトは素晴らしいです。両方のプロジェクトを成功させたいです！
私の個人的な見解は、LXCには 関連するもの を含むより多くの脆弱性レコードがあるということです。そして、私にとって、OpenVZは、新しいOpenVZ 7を含め、優れた、より簡単で安全なエクスペリエンスを提供します。
OpenVZおよびLXCからの文書化された脆弱性の履歴を通じて：
- OpenVZで見つかった つの脆弱性 から、修正されていない場合でも、特権の昇格やコードの実行を許可していません
- 8つの脆弱性 LXCで見つかりました、1つ 2019に文書化 ホストマシンでのルート権限によるコード実行の許可、およびその他の 許可された権限の昇格
追加のポイント：
- OpenVZの venet ネットワークモデルは、より安全で隔離されています[1]
venetネットワーク（OpenVZ）上のコンテナーは、隣接するコンテナーのネットワークトラフィックを傍受できません[1]
[1] https://wiki.openvz.org/Differences_between_venet_and_veth
この記事 で述べたように：
OpenVZは、「ボトムアップ、すべて含まれる原則」によってセキュリティを実現します。コンテナは互いに非常にしっかりと隔離されています。長年にわたっていくつかの問題と脆弱性がありましたが、一般に、それらは素晴らしい仕事をしたと言えます。何よりもまずセキュリティが彼らの心にあったからです。コンテナの分離だけでなく、ネットワークのセキュリティも。 1つのコンテナで信頼できないクライアントへのルートアクセスを許可する場合、そのコンテナが隣接するコンテナ、ノード、またはサブネット全体のネットワークトラフィックを盗聴することを望まないでしょう。そのため、OpenVZは「venet」ネットワークインターフェースを導入し、非常にきちんとした整然とした（エンドユーザーにとって）非常にシンプルな方法でこれに取り組みました。
（免責事項：私はnot OpenVZの権威です。この回答は、私の回答よりももっと意見が多いので、遠慮なく批判してください！）
OpenVZは、カーネル全体と統合しないため、「より安全」である可能性があり、攻撃対象領域が少し低くなります。ただし、本質的にはOpenVZが名前空間、ひいてはLXCとDockerのインスピレーションとなったものです。私は、これらのより完全なソリューションが完全であることは、長い間続けられるとは思えません。
WhiteWinterWolfが指摘した大きな違いの1つは、LXCが最終的にユーザー名前空間を使用できるようになり、非特権ユーザーがコンテナーを実行できるようになり、コンテナーから抜け出すコードが非特権ユーザーの特権を確実に保持するようになることです。また、名前空間ベースのコンテナーは、最終的に完全にSELinuxラベル付けされる可能性があります。 Dockerコンテナーは通常すでに存在しており、Dan Walshは、含まれているプロセスに対してランダムに生成されたカテゴリーを使用して、コンテナー間の分離の追加レイヤーをSELinuxが自動的に強制する方法に取り組んでいます。
つまり、要約すると、コンテナの方が優れています。-一部のコンテナブレークアウトを部分的に阻止し（非特権UIDに制限する）、コンテナ内の特権昇格を無意味にすることができます。 -それらはよりサポートされ、より積極的に開発されており、特にSELinuxサポートから大きな恩恵を受けます。
そして、さらに悪いのは次の理由です。-それらのTCBはカーネル全体で非常に大きく、バグが時々発生し、エクスプロイトやブレイクアウトにつながります。 -ユーザーの名前空間は、一種のEdgeケースのように感じます。通常、SCIのバグ（ブレークアウト後に再現できる）または特権サービスに対する混乱した代理攻撃（最初からコンテナーの外部に存在し続ける可能性が高い）によって特権の昇格を達成します。そのため、コンテナーを実行するUIDを実行中のコンテナーに厳密に制限する必要があります。
要約すると、防御を徹底的に練習し続け、含まれているプロセスに外の世界とどのように相互作用させ、コンテナをどのように実行するかについて考え続けます。違いはありますが、ご覧のとおりごくわずかです。
LXCに固有の最も新しく、最も有望なセキュリティ技術の1つは、権限の低いコンテナの使用です。これは、Linuxカーネル内でLXCが緊密に統合されているためにのみ可能です。これは、LXC内のユーザーをコンテナー所有者からのある種の「サブユーザー」と見なすことを可能にするユーザーの名前空間に依存しています。
コンテナーの所有者がrootである場合、ほとんどのコンテナーのようなシステムに必要であるため、これはセキュリティーの点で（または少なくとも顕著に）何も変更しません。ただし、ここでの「魔法」とは、コンテナーを非特権ユーザーが所有できるということです。この場合、コンテナーのルートユーザーは、システム上でコンテナーの所有者と同じ特権を持ちます。非特権ユーザー。
これらすべてについての良い情報源は、LXCプロジェクトに関わる開発者の1人である StéphaneGrabersのブログ からのものです。