多くの人( Securing Debian Manual を含む)は、マウントを推奨しています/tmp
とともに noexec,nodev,nosuid
オプションのセット。これは一般に、「多層防御」戦略の1つの要素として提示されます。これは、誰かにファイルの書き込みを許可する攻撃のエスカレーション、または正当なアカウントを持つ他の書き込み可能なスペースを持たないユーザーによる攻撃を防ぐことによって行われます。
しかし、時間の経過とともに、noexec
はいくつかの潜在的な理由で役に立たない指標であるという議論に遭遇しました(主にDebian/Ubuntu開発者のColin Watsonによる)。
/lib/ld-linux.so <binary>
同じ効果を得ようとしています。これらの議論を踏まえると、より多くの構成が必要になる可能性(例:debconf
は実行可能一時ディレクトリが好き)と、利便性が失われる可能性がありますが、これは価値のあるセキュリティ対策ですか?迂回を可能にする他の穴を知っていますか?
これが私がこれまでに思い付いたユーティリティの議論です:
最新のカーネルは/lib/ld-linux.so
の穴を修正しているため、noexec
ファイルシステムから実行可能ページをマップできません。
通訳のポイントは確かに依然として懸念事項ですが、私は人々が主張するよりも1つ少ないと思います。私が思い付くことができる理由は、特定の不正なシステムコールを作成することに依存していた特権昇格の脆弱性が数多くあったためです。攻撃者がバイナリを提供しなければ、悪質なシステムコールを作成することははるかに困難になります。また、スクリプトインタープリターは特権を持たない必要があり(これは歴史的にはsuid Perlなどの場合には当てはまらないことを知っています)、攻撃に役立つためには独自の脆弱性が必要になります。どうやら 可能 少なくともPythonを使用してエクスプロイトを実行する。
多くの「缶詰」のエクスプロイトは/tmp
で実行可能ファイルを作成して実行しようとする可能性があるため、noexec
はスクリプトによる攻撃に陥る可能性を減らします(脆弱性の開示とパッチのインストールの間のウィンドウなど)。
したがって、noexec
を使用して/tmp
をマウントすることには、セキュリティ上の利点があります。
Debianのバグ追跡システム で説明されているように、APT::ExtractTemplates::TempDir
のapt.conf
をnoexec
ではなく、ルートからアクセスできるディレクトリに設定すると、debconfの問題を回避できます。
多くのDebianパッケージでは、パッケージをインストールするには、/ tmpが実行可能である必要があります。これらはしばしばバグとしてマークされます(「通常」/「ウィッシュリスト」の重大度):
https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp
今日、stableブランチに更新されたカーネルをインストールしているときに、このエラーを受け取りました。
したがって、Debian(および派生物?)は/ tmpをnoexecでマウントする準備ができていないようです...
以下を/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";};
実装することを選択できるほとんどの補足的なセキュリティ対策には回避策がありますが、最も簡単に回避できるセキュリティ対策(/ tmp noexecのマウントや代替ポートでのSSHの実行など)でも、デフォルトに依存する自動化またはスクリプト化された攻撃を阻止します機能する。断固とした知識のある攻撃者からあなたを守ることはできませんが、99%以上の確率で、断固とした知識のある攻撃者に対抗することはできません。代わりに、自動化された攻撃スクリプトから身を守ります。
最初:これは、多くの異なる攻撃ケースをカバーします。これを回避する方法はいくつか知られていたため(オフにすることもできる)奇妙です。攻撃者がコードを/ dev/shmまたは/ tmpにダウンロードすることは、一般的なことです。
多層防御とは、最も一般的なウェイポイントを保護することです。ウェイポイントを停止させることにより、システムがより存続しやすくなります。安心じゃない。しかし、チャンスもあります。彼らが二次ペイロードをフェッチできない場合、それはあなたが得るかなりのチャンスです。
重要なのは、簡単にできるだけ難しくして、攻撃の99%をカットすることです。
2番目:これは、悪い習慣(tempからの実行、ユーザーtmpdirの代わりに/ tmpを介した主要なアプリケーションのインストールの実行)を停止し、データを/ tmpに残します。通常、カスタムインストーラーTMPDIRを理解してくださいまた、そうでない場合でも、特定の時点のアクションとしてのインストール時間は、セキュリティの問題を無効にする正当な理由ではありません永久に。
番目:/tmpの匿名の名前空間(「機能」)を考えると、そこに何を入れてそこから実行するかを本当に制限したいとします。
Forth:利便性はこれに関連する要素ではありません。サーバーをお金のために、そして目的のために実行すると仮定します。これは私たちが担当します。 「ああ、私は/ tmpをロックダウンしませんでした。それは、来年ソフトウェアを更新するときに、さらに数分が必要だからです。」恐らく、これは恐喝されることと単に元気になることの間にある唯一のものではないでしょう。大きな理由は?私はそうは思いません。
これはどう:
「敵は予告なしに攻撃できることを知りました。彼らはまた、何百人ものスパイを使って食物を毒殺する可能性があります。したがって、兵士への銃の配りを止めました。」
待って、何?
システムを保護するためにより多くの労力、経験、幸運を必要とする他の方法があります。人々がお金や寿命が限られていること、また家族と一緒に過ごしたいことを知っている:スキップしないでください簡単なもの
インストールするために/ tmpが実行可能である必要があるアプリケーションがあります。以前のジョブでは、アクセスする前に管理者が/ tmp noexecを設定していましたが、db2パッケージがインストールされないことに気付きました。 db2パッケージを他の場所でuntarした場合でも、インストールプロシージャは一部のファイルを/ tmpにコピーし、それを実行できることを期待しますが、当然のことながらアクセスは拒否されました。ファイルシステムがnoexecでマウントされていることに気付いていない場合は、少し誤解を招く可能性があります。 noexecなしで/ tmpを再マウントした後でのみ、インストールを続行できました。
とにかく、要点は、少なくとも1つの商用製品が/ tmpをnoexecでマウントしないことを必要とし、他にも存在する可能性があることです。本当に説得力のある理由はわかりません。より良いセキュリティが必要な場合は、代わりにselinuxを使用します。