解決策 1:
私がこれまでに思いついたユーティリティの引数は次のとおりです:
最新のカーネルは /lib/ld-linux.so を修正します noexec から実行可能ページをマップできないようにします。 ファイルシステム。
通訳者の指摘は確かに依然として懸念事項ですが、人々が主張するほどではないと思います。私が思いつく推論は、特定の不正なシステム コールの作成に依存する権限昇格の脆弱性が数多く存在するということです。攻撃者がバイナリを提供しなければ、悪意のあるシステムコールを行うことははるかに困難になります。また、スクリプト インタープリターは特権を持たない必要があります (これは歴史的に、suid perl のようにそうでない場合があることを私は知っています)。どうやら、少なくとも Python を使用してエクスプロイトを実行することは可能です。
/tmp で、多くの「既成の」エクスプロイトが実行可能ファイルを作成して実行しようとする可能性があります 、など noexec スクリプト化された攻撃に陥る可能性を減らします (たとえば、脆弱性の開示とパッチのインストールの間のウィンドウで)。
したがって、/tmp をマウントすることには、依然としてセキュリティ上の利点があります。 noexec で .
Debian のバグトラッカーで説明されているように、APT::ExtractTemplates::TempDir を設定すると apt.conf で noexec 以外のディレクトリへ root からアクセスできるようにすれば、debconf の問題が回避されます。
解決策 2:
多くの Debian パッケージでは、パッケージをインストールするために /tmp が実行可能である必要があります。これらは多くの場合、バグとしてマークされます (「通常」/「ウィッシュリスト」の重大度):
https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp
今日、更新されたカーネルを安定版ブランチにインストールしているときに、まさにこのエラーを受け取りました。
Debian (およびその派生物?) は、/tmp を noexec にマウントする準備ができていないようです...
解決策 3:
以下を /etc/apt.conf に追加するか、/etc/apt/apt.conf.d/50remount
DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};
解決策 4:
実装を選択する可能性のあるほとんどの補足的なセキュリティ対策には回避策がありますが、最も簡単に回避できるセキュリティ対策 (/tmp noexec のマウントや代替ポートでの SSH の実行など) でさえ、デフォルトに依存する自動化またはスクリプト化された攻撃を阻止します。機能する。断固たる知識のある攻撃者からは保護されませんが、99% 以上の確率で、断固たる知識のある攻撃者に対抗することはできません。代わりに、自動化された攻撃スクリプトから身を守ることになります。
解決策 5:
最初: 多くの異なる攻撃ケースをカバーしています。それを回避するいくつかの既知の方法があったため（そのうちのいくつかは修正されました）、それをオフにするのは奇妙です。 /dev/shm にコードをダウンロードする攻撃者 または /tmp
多層防御とは、最も一般的なウェイポイントを確保することであり、それぞれがそれらを停止することで、システムの存続可能性が高まります。安全ではありません。しかし、チャンスもあります。 . 2 番目のペイロードを取得できない場合は、取得できる可能性が非常に高くなります。
- iptables のユーザー制限によって停止される場合もあります。
- SELinux によって停止される場合もあります。
- そうでない場合もあります 簡単にアクセスできる他のエクスプロイトが原因で阻止される。
ポイントは、簡単と同じくらい難しくすることです でき、攻撃の 99% をカットします。
2番目: 悪い習慣を止めます (temp から何かを実行し、/tmp を介して主要なアプリケーションをインストールします) ユーザー tmpdir の代わりに)、/tmp にデータを残します .カスタム インストーラーは通常、TMPDIR を理解しています。 また、そうでない場合でも:インストール時は、特定の時点のアクションとして、セキュリティの問題を永久に無効にする正当な理由にはなりません。 .
3番目: /tmp での匿名名前空間の検討 (「機能」)、そこに置かれ、そこから実行されるものを本当に制限したい.
4番目: 利便性はこれに関連する要因ではありません。私たちがサーバーをお金のために、そして目的のために運営していると仮定すると、私たちはこのことに対して責任があります。 「ああ、私は /tmp をロックしませんでした。 なぜなら、来年ソフトウェアを更新するときは、あと数分かかるからです。".確かに、脅迫されていることと単に元気であることが分かれているのは、この 1 つのことだけではありません.大きな理由? 私はそうは思いません.
これはどうですか:
<ブロック引用>「敵は予告なしに攻撃できることを学びました。敵は何百人ものスパイを使って食べ物に毒を盛ることもできました。そのため、兵士にアウトガンを渡すのをやめました。」
待って、なに？
システムを確保するには、さらに多くの努力、経験、運が必要な対策が他にもあります。人々はお金や寿命が限られていることを知っており、家族との時間を過ごしたいと考えています。簡単なことをスキップしないでください。エム>