Loading article…
Exec Shieldは、Linuxシステムに対するワームやその他の自動化されたリモート攻撃のリスクを軽減することを目的として、2002年後半にRed Hat社で開始されたプロジェクトです。このプロジェクトの最初の成果は、ハードウェアにネイティブなNX実装がないx86 CPU上でNXビットをエミュレートするLinuxカーネル用のセキュリティパッチでした。Exec Shieldプロジェクトには他にも多くのコンポーネントがありますが、この最初のパッチをExec Shieldと呼ぶ人もいます。
Exec Shieldの最初のパッチは、データメモリを実行不可、プログラムメモリを書き込み不可としてフラグ付けすることを目的としています。これにより、バッファオーバーフローや、データの上書きとコードの挿入に依存するその他の手法に起因する多くのセキュリティ脆弱性が抑制されます。Exec Shieldはまた、 mmap ()とヒープベースに対してアドレス空間レイアウトのランダム化も提供します。
このパッチは、シェルコードの挿入と実行の難易度をさらに高め、ほとんどのエクスプロイトを無効化します。exec-shieldを完全に利用するためにアプリケーションの再コンパイルは必要ありませんが、一部のアプリケーション（Mono、Wine、XEmacs、Mplayer）は完全な互換性がありません。
Exec Shieldプロジェクトから生まれたその他の機能としては、位置独立実行可能ファイル（PIE）、Linuxカーネルのアドレス空間ランダム化パッチ、ヒープやフォーマット文字列の悪用をほぼ不可能にするglibcの内部セキュリティチェックの広範なセット、GCCのFortify Source機能、そしてGCCスタックプロテクター機能の移植と統合などがある。
Exec Shield は、コードセグメント制限を利用するすべての x86 CPU で動作します。Exec Shield の動作方法により、非常に軽量ですが、任意の仮想メモリレイアウトを完全に保護するわけではありません。たとえば、mprotect() を呼び出してより高いメモリを実行可能にするなどして CS 制限が引き上げられると、その制限より下の保護は失われます。Ingo Molnar は電子メールでのやり取りでこの点を指摘しています。ほとんどのアプリケーションはこの点に関してかなり賢明です。スタック (重要な部分) は少なくともマップされたライブラリよりも上に位置するため、アプリケーションによる明示的な呼び出しがない限り実行可能になりません。
2004年8月現在、Exec Shieldプロジェクトでは、どのアーキテクチャにおいてもmprotect ()を制限することでメモリ保護を強制しようとする試みは一切行われていません。メモリは最初は実行可能でなくても、後で実行可能になる可能性があるため、カーネルはアプリケーションがメモリページを書き込み可能かつ実行可能としてマークすることを許可します。しかし、Security-Enhanced Linuxプロジェクト（SELinux）との連携により、 Fedora Coreディストリビューションの標準ポリシーでは、互換性上の理由によるいくつかの例外を除き、ほとんどの実行可能ファイルに対してこの動作を禁止しています。
Exec Shield は Red Hat のさまざまな人々によって開発されました。最初のパッチはRed Hat のIngo Molnarによってリリースされ、2003 年 5 月に初めてリリースされました。これは Fedora Core 1 から 6 および Red Hat Enterprise Linux バージョン 3 以降に含まれています。[ 1 ] [ 2 ]その他に関わっている人物には、Jakub Jelínek、Ulrich Drepper、Richard Henderson、Arjan van de Ven などがいます。
モルナーは2007年にLWN.netで「[exec-shield]の一部は上流に送られたが、かなりの部分は送られなかった」とコメントした。[ 3 ]