SELinuxとテキスト再配置の悪用
私は、GNU/Linuxファーム用の特定のバックアップソフトウェアソリューションを採用および実装するタスクを割り当てられました。
私の部門で定義された要件に従って、このソリューションはSELinux対応システムが有効であることをサポートする必要があります。徹底的ではない調査の結果、この製品は SELinuxをサポートしていなかった 、または一部のライブラリが必要だったため、システム管理者にSELinuxポリシーの パンチ穴 を要求したことが明らかでした テキストの再配置 を実行するには（知識ベースで提案されているコマンドの正確さ-またはその欠如は言うまでもありません）。
SELinuxが バグを公開する であることが証明されたのは新しいことではありませんが、ここでの私の懸念は、管理者にどの程度まで説明できるかということでした テキストの再配置の拒否は主要なセキュリティ機能です 。
テキストの再配置を実行する必要性に関連して、この特定の製品に対してCVEが公開されていないと主張する私の推論に反論します。
テキストの再配置を実行する必要性は、CVEの有効な脆弱性を表すのに十分に悪用可能ですか？
重要な点が2つあります。 1つ目は、SELinuxポリシーの主な強みはnknown脆弱性の悪用を防ぐことです。それらが不明であることを考えると、CVEは存在しません。
2つ目は、テキストの再配置を許可すると、実行したいコードを記述して実行したり、メモリ内の既存のコードを変更したりできるようになることです。ウルリッヒの「問題の修正」の記事も含まれているウルリッヒの短い宣伝文を参照しています。どちらも優れており、問題を説明しています。
「テキストの再配置を実行する必要性」自体は脆弱性ではありません。プログラムまたはライブラリの一部の脆弱性が悪用されやすくなるだけです。
CVEが存在しないことは、セキュリティ対策を実装しないことの恐ろしい正当化です。このゲームの要点は、攻撃者よりも先を行くことであり、仮説的な攻撃者が広く普及しているパブリック脆弱性のみを使用している場合、実際には攻撃者は何をするのが得意ではありません。
テキストの再配置は、自己変異コードの特殊なケースであるため、「悪い」ものです。つまり、攻撃者はプログラムにテキストを変更させる可能性があります。再配置が必要な場合は、プログラム.text（コード）に書き込むことができることを意味します。
攻撃者がテキストの再配置プロセスを操作したり、直接.textに書き込んだりすることができる実際の脆弱性がなければ、これは完全に問題ではありません。再配置が必要な場合は、基本的に、ロード可能なモジュールを追加できるようにするか、攻撃を受けているシステム上の任意のファイルを変更する必要があります。どちらの場合も、はるかに大きな問題があります。攻撃者として.textに任意のものを書き込むことができるケースは、それ自体がかなり大きなセキュリティバグです。
基本的に、これを許可すると、W ^ X保護のメリットが失われます。それが大きな問題です。
もちろん、攻撃者がこれらのことを実行することを可能にする脆弱性がないことは知っているではありません。この権限をアプリケーションに付与できなかった場合はより安全になりますが、機能が正直にそれを必要とする場合は、ソフトウェアベンダーに大声で叫んでいる間だけ許可する必要があります。