Red HatのRHELソースコード配布方式の変更
- 2023年6月、Red HatはRed Hat Enterprise Linux（RHEL）の背後にあるソースコード配布方式を変更するという、物議を醸す決定を下した
- この決定は、Rocky Linux、AlmaLinux、Oracle Linuxなど、RHELのダウンストリーム・リビルドの今後の存続可能性について多くの疑問を投げかけた
- 各ディストリビューションはその後、コミュニティを落ち着かせるための発表を行った
- 多くのオープンソースコミュニティでは、Red Hatの決定を強欲な企業の影響力として解釈した
- 人々はDebianへ移行する、あるいはすでに移行したと語り、避難先を求めている
セキュリティの重要性と難しさ
- セキュリティは難しく、退屈で、不快で、きちんと実施するには多大な努力が必要である
- Debianはユーザーを守るために十分な努力を払っていない
Red HatによるSELinux採用とデフォルトポリシーの提供
- Red Hatはかなり前からSELinuxの利用を受け入れており、単にカーネルで機能を有効化するだけにとどまらなかった
- 彼らはディストリビューション向けのデフォルトSELinuxポリシーを作るという困難な作業を担った
- これらのポリシーはRHELでデフォルト有効として提供され、RHELで標準的に動作する各種デーモンやサーバーのうち、特によく使われるものを保護するのに役立っている
- Apache、nginx、MariaDB、PostgreSQL、OpenSSHなどは、いずれもRHELディストリビューションで提供されるSELinuxポリシーによって保護されている
コンテナへのSELinuxポリシー適用
- 保護はコンテナにまで拡張されている
- コンテナは、開発者がソフトウェアを配布するための手段として、ますます好まれる方法になっている
- コンテナで何かを実行すれば本質的に安全だというのは誤解である
- コンテナそのものはセキュリティ問題を解決するのではなく、ソフトウェア配布の問題を解決する
- Red Hat系ディストリビューションでは、デーモンなしでコンテナを実行でき、完全なrootless実行も可能という利点を持つDocker代替の
podmanを利用できる
- Red Hatはさらに一歩進めて、コンテナをホストOSや他のコンテナから分離する強力なデフォルトSELinuxポリシーを適用している
- SELinuxポリシーをコンテナに適用することで、未知の将来の脆弱性リスクを軽減する強化された安全装置が得られる
Red HatのデフォルトSELinuxポリシー提供への取り組み
- Red Hatは、こうしたデフォルトポリシーの整備を行わなければユーザーはその技術を受け入れず、何百万台ものサーバーが脆弱なまま残ることを理解していた
- SELinuxは難しく、ポリシー言語とツールは複雑でわかりにくく、税務申告書を書くのと同じくらい魅力に欠ける
- しかし、Red Hatが行った作業のおかげで、RHELにおけるSELinuxの利用は大半が透過的になり、ユーザーに実質的なセキュリティ上の利益をもたらしている
DebianのAppArmorアプローチ
- Debianは、安定性と広範なソフトウェアライブラリで知られる、オープンソースコミュニティの中核である
- しかし、そのデフォルトのセキュリティフレームワークには改善の余地が大きい
- Debian 10からデフォルトでAppArmorを有効化するという決定は、セキュリティ改善に向けた前向きな一歩ではあるが、システム全体では中途半端に実装されており不十分である
- DebianのAppArmor依存とデフォルト構成は、セキュリティへのアプローチに構造的な問題があることを示している
- AppArmorは適切に構成されれば強力なセキュリティを提供できるが、Debianのデフォルト設定はその潜在力を活かし切れていない
DebianのAppArmorの問題点
- 限定的なデフォルトプロファイル: Debianは最小限のAppArmorプロファイルしか同梱しておらず、多くの重要なサービスを保護していない
- 事後対応と事前予防の対比: Debianのセキュリティモデルは、より厳格なポリシーの実装をユーザーに委ねることが多く、デフォルトで安全な構成を提供していない
- 一貫性のない適用: Red HatシステムのSELinuxと異なり、DebianのAppArmorは部分的にしか適用されておらず、潜在的なセキュリティギャップを生んでいる
- リソース不足: コミュニティ主導のプロジェクトであるDebianには、Red Hatが提供するような包括的なセキュリティポリシーを開発・維持するためのリソースが不足している
DebianでDockerを通じてコンテナワークロードを実行する場合
- DebianでDockerを通じてコンテナワークロードを実行することは非常に一般的である
- Dockerは
docker-defaultというコンテナ向けのデフォルトAppArmorプロファイルを自動生成して読み込む
- 残念ながら、これはセキュリティ面で非常に強力なプロファイルではなく、過度に寛容である
- このプロファイルはある程度の保護を提供するものの、かなり大きな攻撃面を露出させている
AppArmorとSELinuxの根本的な違い
- AppArmorとSELinuxの根本的な違いは、強制アクセス制御（MAC）へのアプローチにある
- AppArmorはパスベースのモデルで動作する一方、SELinuxははるかに複雑なタイプ強制システムを用いる
- この違いは、コンテナ環境で特に際立つ
- SELinuxは、システム上のすべてのオブジェクト（ファイル、プロセス、ポートなど）にタイプを適用する
- SELinux対応のRHELシステムでコンテナを起動すると、即座に厳格なアクセス制御メカニズムである
container_tタイプが割り当てられる
container_tタイプはコンテナを効果的に封じ込め、コンテナ用途向けに明示的にラベル付けされていないオブジェクトと相互作用できないようにする- SELinuxはタイプ強制で終わらず、多カテゴリセキュリティ（MCS）ラベルを使ってコンテナ分離をさらに一段進めている
- これらのラベルは、同じタイプ（
container_t）のコンテナ同士の間でも分離を維持する追加の分離レイヤーとして機能する
- 各コンテナは固有のMCSラベルを受け取り、より広い
container_t環境の中にプライベートなサンドボックスを作る
AppArmorのアプローチ
- AppArmorはタイプやカテゴリには着目せず、事前定義されたプロファイルに基づいて特定プログラムの機能を制限することに重点を置く
- これらのプロファイルは、プログラムがアクセスできるファイルや実行できる操作を指定する
- このアプローチは実装や理解がより簡単である一方、SELinuxのタイプ強制ほど細かくなく、システム全体での一貫性にも欠ける
- 主流のLinuxディストリビューションは、一般的なネットワーク指向デーモンすべてに対する包括的なAppArmorプロファイルをデフォルトでは配布していない
実際の影響
- SELinux環境では、侵害されたコンテナがホストシステムや他のコンテナにアクセスしたり影響を与えたりするには、タイプ強制とMCSラベルという二重の障壁があるため、大きな障害に直面する
- SELinuxはより強力な分離を提供するが、その代償として複雑さの増大と潜在的な性能オーバーヘッドを伴う
- AppArmorは、適切に構成されていれば依然として非常に有効になり得る、より単純で近づきやすいセキュリティモデルを提供する
- Red Hatは、SELinuxとコンテナ利用を円滑で簡単なものにするために努力を重ねてきた
- 結局のところ、DebianとRed Hatのどちらを選ぶかは、単に企業の影響力とコミュニティ主導開発のどちらを選ぶかという話ではない
- それはまた、最善を前提とするシステムと最悪に備えるシステムのどちらを選ぶかでもある
- 今日の高度に接続された世界では、残念ながら悲観主義が不可欠である
GN⁺の見解
- Red HatのRHELソースコード配布方針の変更は物議を醸すものではあるが、セキュリティの観点では合理的な決定である可能性がある
- エンタープライズLinuxディストリビューションでは、SELinuxのような強力なセキュリティ機能の提供が不可欠である
- しかし、Red Hatの方針変更はオープンソース生態系に悪影響を及ぼす可能性があり、Debianのようなコミュニティベースのディストリビューションの役割はさらに重要になるだろう
- Debianはユーザーフレンドリーで柔軟なディストリビューションとして知られているが、デフォルトのセキュリティ機能の強化が必要である
- AppArmorはSELinuxほど強力ではないが、適切に構成すれば効果的なセキュリティソリューションになり得る
- 長期的には、SELinuxとAppArmorの利点を組み合わせた新しいセキュリティフレームワークの開発が必要になるかもしれない
- コンテナセキュリティはクラウドネイティブ時代において非常に重要な課題であり、すべてのディストリビューションがこの分野により多くの努力を注ぐ必要がある
2件のコメント
AppArmor が SELinux より厳格さに欠けるのは事実ですが、
だからといってセキュリティが脆弱だとは言いにくいです。
SELinux は厳しすぎるため、サーバーを設定するとほとんどの場合 SELinux を無効にしてしまいます。
そしてデスクトップでは、セキュリティは SELinux の主要な関心事ではありません。
UI やユーザー体験の面で必要な制限や適切な認証要求の手順などが必要で、これは SELinux のようなリソースに対する分離とは別の話です。
そのため、デスクトップのセキュリティは Red Hat 系であれ Debian 系であれ、どちらも freedesktop で標準化される polkit (PolicyKit) ベースで動いています。
Hacker Newsの意見