Gentoo Hardenedと他のディストリビューション
Gentooの強化されたプロファイルが、他のどのディストリビューション（Debian、RHEL、Archなど）よりも本当に安全かどうか疑問に思いました。知らない人のために、Gentoo hardenedは、特定の強化GCCオプション（pie、ssp、relroなど）と他のいくつかのこと（grsec/selinux ...）を使用してシステム全体を構築できるようにします。
たとえば、Arch LinuxがGCC強化フラグを使用してすべてのバイナリをビルドするわけではないことを知っているので、セキュリティに関する何らかの懸念を示唆していますか？
OpenVPNはPIEとパーシャルrelroなしで構築されていることを知っています。これは、OpenVPNに対するエクスプロイトが見つかった場合、ArchのインストールはGentooのものよりも安全性が低い可能性があることを意味しますか？
TL; DR：バイナリのセキュリティの点で、他のディストリビューションよりもGentoo Hardenedを使用することの利点はありますか？
そのすべてがソースにあります！ Gentoo hardenedはセキュリティ主導のディストリビューションであり、hardenedプロファイルは本当にそれを本当に安全にするために多くのことを詰め込んでいます。
しかし、コンパイルする価値はありますか？ Linuxフォーラムでの大きな質問。
セキュリティの観点からGentoo強化プロファイルを見てみましょう。
ある程度のセキュリティが追加されますが、ほとんどの場合は価値がありません。誰もが同じバイナリを使用しており、攻撃者は特定のコードがどこに読み込まれるかを推測する必要がないため、バイナリディストリビューションのセキュリティが向上しますが、ソースディストリビューションを実行することにより、アドレススペースはすでにかなり一意です。セキュリティを提供する唯一のケースは、攻撃者がエクスプロイトのアドレスを推測しようとしている場合です。間違った推測を行うと、プロセスがクラッシュし、新しいアドレスに再ロードされます。攻撃者が手間をかけて手に入れるのに十分な貴重なデータはありますか？そうする場合は、強化されたプロファイルを使用する必要がありますが、物理的なセキュリティとディスク暗号化の方が重要です。それだけの価値がある場合は、強奪するほうが簡単だからです。
強化されたデスクトッププロファイルはないので、デスクトップで使用することを計画している場合、それだけでは多少難しくなります。
もう1つの理由は、アクセス制御について非常にきめ細かい制御ができるSELinux（強化されたプロファイルを必要としない）のようなものを使用したいが、それも非常に制限的な場合です。多くのユーザーがいて、機密データへのアクセスレベルが異なる大規模なネットワークの場合にだけ価値があると思います。
私はいくつかのSELinux機能を必要としていましたが、SELinuxはあまりにも面倒なので、異常な方法でAppArmorを使用して解決しました。 AppArmorが実際に行うことは、プロセスの分離またはサンドボックス化を提供することだけです。攻撃者がエクスプロイトを通じてアクセス権を取得した場合、攻撃者は、悪用されたサービスがアクセスできるファイルにのみアクセスできます。私はそれをすべての書き込み可能およびホームディレクトリからの実行を防止するcatch allプロファイルで使用し、ssh/pgpキー、キーリングなどへのアクセスを許可します。これはサーバーおよびデスクトップに適切に機能し、あまり制限的ではありません。また、開発のためにホームディレクトリからコードを実行する必要がある場合は、Sudoを介して無制限のシェルを起動できます。ウォレットを開いたままラップトップのロックを解除したままにすることができます（kwallet pamモジュールを使用します）。sshキーやパスワードなどを入手するのは非常に困難です（kwalletのパッチもあるので、保存されたパスワードを表示するにはパスワードが必要です） ）、しかしそれらを必要とするプログラムはそれらにアクセスできます。
しかし、何がそれを強化するのでしょうか？それらの項目のいくつかも見てみましょう：
- PaXは、スタックやヒープオーバーフローから私たちを守るカーネルパッチです。 PaXは、メモリ内のランダムなメモリ位置を使用するASLR（アドレス空間レイアウトのランダム化）を使用してこれを行います。各シェルコードはコードを実行するために、その中に埋め込まれたアドレスにジャンプするためにアドレスを使用する必要があります。メモリ内のバッファーのアドレスはランダム化されているため、これを達成するのははるかに困難です。 PaXは、プログラムが使用するデータを実行不可能なメモリ領域に保持することにより、保護の層を追加します。つまり、攻撃者は、メモリに書き込むために管理したコードを実行できなくなります。 PaXを使用するには、hardened-sourcesなどのPaX対応カーネルを使用する必要があります。
- PIE/PIC（位置に依存しないコード）：通常、実行可能ファイルには、それらが読み込まれる固定ベースアドレスがあります。これは、実行可能ファイル内の関数のアドレスを計算するためにRVAに追加されるアドレスでもあります。実行可能ファイルがPIEサポート付きでコンパイルされている場合、メモリ内の任意の場所にロードできますが、PIEサポートなしでコンパイルされている場合は、固定アドレスでロードする必要があります。 ASLRを利用するためにPaXを使用する場合は、PIEを有効にする必要があります。
- RELRO（再配置読み取り専用）：実行可能ファイルを実行するとき、ロードされたプログラムは、アプリケーションの起動後に書き込み可能としてマークする必要がないいくつかのセクションに書き込む必要があります。そのようなセクションは、.ctors、.dtors、.jcr、.dynamic、および.gotです[4]。これらのセクションを読み取り専用としてマークすると、攻撃者は、GOTテーブルのエントリの上書きなど、コード実行を試みるときに使用される可能性のある特定の攻撃を使用できなくなります。
- SSP（スタックスマッシングプロテクター）はユーザーモードで使用されます。スタックにカナリアを配置することで、スタックオーバーフローから保護します。攻撃者がスタック上の戻りEIPアドレスをオーバーフローしたい場合、ランダムに選択されたカナリアもオーバーフローする必要があります。その場合、システムはカナリアが上書きされたことを検出できます。その場合、アプリケーションは終了し、攻撃者がメモリ内の任意の場所にジャンプしてそこからコードを実行することを許可しません。
- RBAC（役割ベースのアクセス制御）：RBACは、後で説明するRSBACと同じではないことに注意してください。 RBACは、SELinux、Grsecurityなどで使用できるアクセス制御です。デフォルトでは、ファイルの作成者はファイルを完全に制御できますが、RBACは、誰が作成したかに関係なく、rootユーザーにファイルの制御を強制します。それ。したがって、システム上のすべてのユーザーは、システムの管理者が設定したRBACルールに従う必要があります。
さらに、プロセスとオブジェクト間のアクセスを制御するために使用される次のアクセス制御システムも使用できます。一度に使用できるアクセス制御システムは1つだけなので、通常、以下に概説するシステムの1つを選択する必要があります。アクセス制御システムには次のものがあります。
- SELinux（セキュリティが強化されたLinux）
- AppArmor（アプリケーションアーマー）
- システム全体のセキュリティを向上させるためにカーネルに適用できるさまざまなパッチを含むGrsecurity。カーネルでGrsecurityを有効にする場合は、ソースが強化されたGrsecurity対応のカーネルを使用する必要があります。
- RSBAC（ルールセットベースのアクセス制御）：rsbac-sourcesカーネルを使用して、rsbacをサポートするカーネルを構築する必要があります。
それはすべて、前述のように大きな問題に帰着しますか？コンパイルする価値はありますか？本当にどのように、または何を確保しているかにかかっており、その努力は価値がありますか？それとも、覗き見したくないものを本当に確保できるでしょうか？