MACタイプのシステムの普及を妨げているものは何ですか？
全体的な質問
企業およびデスクトップコンピューティング環境で、SELinux/AppArmorなどのMACシステムの取り込みを妨げているものは何ですか？
まだ普及していないと思いませんか？
「オペレーティングシステムで利用可能」を「広範囲」としてカウントしません。 Windowsには実際にはネイティブのPOSIXエミュレーションレイヤーがありますが、インストールされて実行されているWindowsシステムはほとんどありません。多くのLinuxディストリビューションにはAppArmorとSELinuxのパッケージがありますが、私の知る限り、Fedoraとそれに続くRHELのみがこれらを有効にして出荷されます。デフォルトの動作はシステムサービスの制約のみです。たとえば、Fedoraは_unconfined_t_をサポートしています。それがすること.
さらに、Linux製品の多くの商用ベンダーは「SELinuxをサポートしていない」と言っており、私はStack Overflowの前の日にフォーラムで頻繁に参照し、実際にSELinuxの「修正」には基本的にオフにすることを示唆する多くのブログ投稿を目にしました。
背景
私はアクセス制御を2つのタイプに分類します。
- DACやRBACなどのユーザーのみのアクセス制御システム。これらのモデルでは、各ユーザーに一連の特権があり、これらはそのユーザーが実行しているソフトウェアまたはアプリケーションに継承されます。
- 必須アクセス制御（MAC）システム。各アプリケーションには、必要に応じてユーザーレベルの特権と組み合わせることができる、または組み合わせない独自の特権のセットがあります。
私が尋ねる理由はこれです。最初のモデルでシステムを危険にさらしたい場合、それはほとんど2段階のプロセスです。最初に、任意のコードを実行できる脆弱なエントリポイントを見つけます。2つ目は、その開始ポイントから脆弱な特権プロセスを見つけて、特権をエスカレートできるようにします。脆弱なエントリポイントにも特権が付与されている場合は、はるかに優れています。
しかし、これは疑問を投げかけます。なぜこれらのアプリケーションは、ユーザーがアクセスできるすべてのものにアクセスする必要があるのですか？ Firefoxを例にとります。いくつかの共有ライブラリ（またはWindowsの場合はDLL）があり、ロードする必要があり、プロファイル情報とプラグインをロードできる必要がありますが、なぜ_/usr_ツリー全体を読み取ることができるのでしょうか、またはユーザーが現在実行しているすべてのプロセスを列挙しますか？ _/home/ninefingers/Downloads_への書き込みアクセスが必要な場合もありますが、たとえば、_/home/ninefingers/Banking_へのアクセスは必要ありません。さらに言えば、破損した入力で特権プロセスの新しいインスタンスを開始したり、ローカルソケット経由でsetguidプロセスにメッセージを送信したりする必要はありません。
さて、ある程度までは解決策があります。 Linuxでは、多くのシステムデーモン（サービス）が実際に特権を削除し、対話的にログインできない個別のユーザーとして実行されます（シェルを使用-_/bin/false_またはシェルとして_/sbin/nologin_を使用）。すべてのファイルは、所有者、グループ、およびその他の権限（Windowsとは異なります）しか持つことができません。
また、現在のX11セキュリティモデルを含め、MACにはいくつかの技術的な課題があることも理解しています。多くのLinuxディストリビューションは、SELinuxまたはAppArmor構成と制約付きデーモンを提供していますが、デスクトップへの推進力はあまりないようです。 Windows Vistaは整合性レベルをサポートしていますが、これらは特に細かいレベルではありません。
私はドメイン内の特権レベルの考え方にはそれほど関心がありません-参照 この質問 このようなテクニックと戦略の実用的な使用を求めるだけでなく、アプリケーションはユーザーと同じように、最小特権の原則。 Invisible Things Labブログの投稿 "MS-DOSセキュリティモデル" は、特にデスクトップのセキュリティに関して、私が関心を持つ点の多くを示しています。
また、各アプリケーションにMACルールを同梱することで、より良いソフトウェア開発が促進されると思います。テスト駆動開発と同様に、予期しないルールがトリガーされた場合、バグがある可能性がある（またはルールが間違っている）ことがわかります。
全体的な質問への回答に役立つ可能性のある潜在的なサブ質問
- 企業環境で必須アクセス制御/ appsecを実装しようとしたことがありますか？それは議論されて放棄されたことがありますか？私が探しているのは、それが考慮された場合、「あなたがそれを使うのを止めた理由」です。
- 私は正しいですか？説明したMACシステムはマルウェアの侵入からエントリポイントを保護するのに役立つと思いますが、問題に対する他の解決策や、現在のシステムが実際に十分に機能していることについては、議論の余地があります。
- ユーザビリティへの影響は何ですか（明らかにいくつかあります）、それらは軽減できますか？
- デスクトップ統合のハードルを克服できますか？
- 私が見落とした可能性のある他のミドルグラウンドシステムはありますか？
- この方法または別の方法でappsecのセキュリティ状況を改善するための業界全体の協調的な努力がないのはなぜですか？
残念ながら、「SELinuxの修正には基本的にオフにすることが含まれます」というコメントですでに質問に回答したと思います。大変な仕事です。
理想的な世界では、アクセスなどの特定の要件が詳細に示され、MACまたはその他の制御パラダイムを実施するようにアプリケーションがコーディングされますが、実際には次の問題が発生します。
- 新機能を迅速にリリースするための要件
- 限られた予算
- プロジェクトリーダーまたはボードレベルでのセキュリティ要件の理解不足
- セキュリティポリシーが大きく異なる企業の買収
その他多数。
セキュリティは、多くの場合、費用を節約し、長期的にリスクを軽減するのが一般的ですが、短期的にはコストがかかります。ビジネス要件を満たすためには（多くの場合、短期的であり、プロジェクトまたは一定期間の株主還元に焦点を当てています）、必要最低限以下で実行します。
MACを正しく実装することは、かなり集中的でオーバーヘッドの高い要件であり、急激な変化に直面してもMACを維持することは大変な作業です。
攻撃の種類のホスト全体を削減または削除するため、組織が正しくそれを実行した場合、私はそれを気に入っていますが、私は息を止めていません。
Casey Schaufler（SMACK作成者）を引用したい：
1980年代の半ばから世紀の変わり目まで、強制アクセス制御（MAC）はBell＆LaPadulaセキュリティモデルと密接に関連していました。これは、米国国防総省のポリシーの数学的説明です紙文書のマーキング用。この形式のMACは、キャピタルベルトウェイとスカンジナビアのスーパーコンピュータセンターで好評を博しましたが、一般的なニーズに対応できなかったためにサイトに配置されることがよくありました。
世紀の変わり目頃、ドメインタイプエンフォースメント（DTE）が普及しました。このスキームは、ユーザー、プログラム、およびデータを、互いに保護されたドメインに編成します。このスキームは、一般的なLinuxディストリビューションのコンポーネントとして広く導入されています。 このスキームを維持するために必要な管理オーバーヘッドと、安全なドメインマッピングを提供するために必要なシステム全体の詳細な理解により、ほとんどの場合、スキームが無効になるか、限られた方法で使用されます。
Smackは、前任者の落とし穴を回避しながら、有用なMACを提供するように設計された必須アクセス制御メカニズムです。 Bell＆LaPadulaの制限は、要件に従ってアクセスを制御できるスキームを提供することで対処されます。システムとその目的は、難解な政府の政策によって課されたものではありません。ドメインタイプの強制の複雑さと、すでに使用されているアクセスモードの観点からアクセス制御を定義することによって回避されます。
したがって、基本的にselinuxは一般的な使用のために設計されていません。そして、一般的に、現在のMACシステムは、一般的なUNIXの権限よりも一般の人にとって理解するのが無理です。そして最も重要なことは、私が思うに、それらはincompleteであり、policy（UNIX DACモデルでフォローしているように）従うことができます。たとえば、通常、ホームディレクトリにはuser.groupの所有権があり、/tmpにはそのような権限があり、/bin/ファイルにはそのようなファイルがあります。これらはすべてすでに発明されています。しかし、MACについては、科学者のように、その科学を学んでいないことを除いて、通常、ポリシーを自分で開発する必要があります。どのような基準と方法論によって、セキュリティ以外の人物がそれを開発する必要がありますか？
/usr/bin/dateなどを制限するために自動生成されたポリシーはおかしいですが、なぜそれらを保護するのですか？誰が/usr/bin/dateをハッキングしますか？したがって、別の重要理由は、保護したい正確な理由であり、その理由は何ですか？ POSIXパーマでは不十分な場合どんな種類の攻撃に対して？そのような攻撃の一般的なモデルはありません。理解も目標も意味もありません。
@ Rory-Alsopは正解です。堅牢で効果的なセキュリティには非常に高いコストがかかります。
企業およびデスクトップコンピューティング環境で、SELinux/AppArmorなどのMACシステムの取り込みを妨げているものは何ですか。
答えはコストだと思います。システムの他の側面と同様に、セキュリティにはコストがかかります。意識しているかどうかに関係なく、ITの購入責任者（ホームユーザーであろうとCIOであろうと）は、現在、セキュリティに多くを費やす気はないと判断しています。問題を注意深く検討しなかったとして、私たちはそれらを却下するかもしれませんが、私が彼らに間違って欲しいのと同じくらい、彼らは正しいかもしれません。
編集：D.W.に感謝コメントと私のあいまいな記憶
Unix ThompsonとRitchieを設計する前は、Multicsと呼ばれるオペレーティングシステムに携わっていました。 Multicsは、セキュリティを重視したオペレーティングシステムであり、広範なエラー処理を試みました。 Unixは、広範なエラー処理をやめることに決め、多大な労力を節約しました。 Tom Van Vleckが語ったように 「私が[Van Vleck]がMulticsで書いたコードの半分はエラー回復コードでした。彼[Dennis Ritchie]は、「私たちはそれらすべてを省略しました」と述べました。
広範なエラー回復には、いくつかのエラーを処理する場合の約2倍の設計とコーディングが必要ですが、すべてのエラーを処理する必要はありません。
まだ普及していないと思いませんか？
MACがなくても多くのセキュリティ問題を処理できるため、MACは非常に高価です。 MACは、ポリシーを実装するためのメカニズムです。 MACを使用するには、システムをモデル化してポリシーを設計し、必要な制御を提供する必要があります。そして、あなたの方針は最初は完全ではないでしょう。既存のシステムはセキュリティがDiscressionaryタイプであるという想定の下に構築されているため、MACは既存のシステムに大きな負担をかけます。つまり、概念的なレベルでは、重要なプロトコルは重要なシステムリソースにアクセスできると想定されています。
なぜこれらのアプリケーションは、ユーザーがアクセスできるすべてのものにアクセスする必要があるのですか？
彼らはしません。ただし、ユーザーのように振る舞えば、多くのアプリケーションを実装する方が簡単です。ユーザーは主に理解されているシステムです。アプリケーションの動作をユーザーと異なるようにするには、多くの考えと設計が必要です。開発者にとって多くのコスト（およびシステムまたはソフトウェアの小売価格が高い）とセキュリティのバランスが取れていないため、マネージャーは通常、セキュリティをあまり選択しません。ああ、私たちはセキュリティの問題を抱えています、そのためのパッチがあります...
アプリケーションは、ユーザーと同様に、最小特権の原則に従う必要があります
通常は例外です。はい、一部のITシステムと一部の環境ではそうですが、多くのデータベース管理者は、それなしで生活できる機能にアクセスでき、ネットワーク管理者は、サーバーアドレスやプロトコルオプションよりもはるかに多くの機能を変更できるアカウントを持っています。 、およびほぼすべてを変更できるシステム管理者。
Joanna Rutkowskaを尊重して、最新のオペレーティングシステムはMS-DOSと同じセキュリティモデルを使用していません。 MS-DOSセキュリティモデルには、マルチプロセッシング、同時ユーザー、ネットワーク通信、またはマルチプロセッサはありませんでした。
MS-DOSセキュリティモデルから：Linuxデスクトップが異なるユーザーアカウントを作成する機能を提供する理由を誰かが知っていますか？
はい、LinuxがUnixをエミュレートして同等の機能を提供しようとするので、 Unixは基本的に多くのユーザーとの共有システムであるため、Linuxは複数のユーザーを許可する機能を提供します。サービスにユーザースタイルのアカウントが与えられ、サービスをユーザーにすることはセキュリティを向上させるための弱い試みでしたが、マルチユーザー機能の元々の理由ではありませんでした。
ユーザビリティへの影響は何ですか（明らかにいくつかあります）、それらは軽減できますか？
それらは巨大であり、いくつかは軽減することができますが、更新スクリプトが機能しなくなったときにデータベース管理者を落ち着かせることはしたくありません。そして、内部NTP=サーバーが動作しなくなった理由を知りたいネットワークエンジニア...
Re： "ただし、私の知る限りでは、Fedoraと、それに続くRHELのみがこれらを有効にして出荷されます"
Ubuntuは8.04（2008）以降出荷されました デフォルトでAppArmorが有効になっています 、そしてSUSEはリリース10以降にそれを持っていると聞いています。システムで何が行われているかはSudo apparmor_statusで確認できます
私の現在の比較的バニラUbuntuデスクトップシステムの1つでは、pdfビューア（evince）とdhclient3（DHCP）、libvirtd（仮想化デーモン）、cupsd（印刷）などのいくつかのデーモンを含む12のプロファイルが有効になっています。保護されたサーバーサービスの例には、MySQL、namedsmbd、ntpdが含まれます。Apache2には、デフォルトで無効になっているプロファイルがあります。詳細は SecurityTeam/KnowledgeBase/AppArmorProfiles-Ubuntu Wiki を参照してください
そして、google-chromeブラウザーは独自のサンドボックス化を行っていますが、これにはいくつかの同様の利点があると思います。
AppArmorは、2010年10月の2.6.36以降、メインラインLinuxカーネルに入っています。うまくいけば、より多くのアプリがサポートを統合することがより魅力的になるでしょう。
SELinuxはすでにかなりの展開を達成しています。たとえば、Fedora Linuxのインストールでは、デフォルトで有効になっています。
SELinuxのより広範な展開を妨げている主な原因は、システム管理への影響だと思います。何かが動作を停止するのは珍しいことではありません。システム管理者が何故機能しないのかを解明するために何時間も費やし、SELinuxのあいまいな拒否に遭遇したことを発見するだけです。このような状況では、sysadminがSELinuxをシャットダウンするか、将来のシステムでSELinuxを無効にし始めるかは理解できます。一般に、SELinuxはシステムを理解し、障害のトラブルシューティングを困難にする可能性のある複雑さを追加します。これは、システムがオフになる（またはインストールされない）主な理由だと思います。
フォーカスと理解
開発者/アーキテクトには、やるべき仕事があります。
彼らは、オペレーティングシステム全体と、ソフトウェアを上に置いてオペレーティングシステムを実行する方法を理解する必要があります。それらは精神的な帯域幅をあまり持っておらず、機能的な側面に重点が置かれています。
彼らはそれをすべて理解するためにhaveをしませんが、もし理解しなければ、結果/バグがあります。
問題空間を理解することは、MACなどの他のレイヤーを追加せずに、そのままでは十分に難しい作業です。そのため、彼らの観点からは、アプリケーションがランダムになり、一貫性がなくなり、一部の機能が完全に理解されないと機能しなくなる可能性があります。
他のほとんどの機能には、セキュリティ機能にも直接的な利点があり、MACの利点は明白ではないか、直接適用できません。
リスクのある特定のアプリケーションを作成するためにRed HatがSELinuxで行った作業は素晴らしいものです。これは、特定のクラスのアプリケーションでは深刻なレベルを引き上げることがあるためです。
MACがデスクトップで機能することは決してありません。ユーザーに課す深刻なGUI切断が原因です。 1つの限定的な使用例は、銀行などの特別な目的のブラウザーである可能性がありますが、ファイルのコピーおよびゾーン/ラベル間のコピー/貼り付けには制限があります。ハイパーバイザーは、一部のデスクトップの場合に役立つ制限された分離を提供できるため、ハイパーバイザーレベルにも注目してください。
さらにいくつかのポイント：
- 企業にMACのほとんどの利点を提供するために、デスクトップ仮想化を検討してください。
- アプリケーションを異なるサイロに分離することで、MACのコストなしで同様のセキュリティ上の利点も提供されます（3層アーキテクチャ、サービス指向アーキテクチャ、キューイングインフラストラクチャを参照）。テスト可能で検証可能であり、優れた価値を提供します。