/tmp に対して – トニー・フィンチ

ロブスターについてコメントしたのは、 /tmp それは通常悪い考えです、これはちょっとした驚きを引き起こしました。たぶん /tmp 私が Unix を学んでいた 1990 年代にはセキュリティ バグはよくありましたが、現在ではかなりまれになっているため、白髪の多いハッカーがこの問題に精通していない理由もわかります。

これはある種の成功だと思いますが、残念ながら、根本的な問題に対処していないため、修正によって多くの傷跡が残りました。 /tmp 存在してはなりません。

これはセキュリティの境界を越えて共有されるグローバルな可変状態であるため、これは悪い考えです。 UNIX のあらゆるレベル (ファイルシステム、カーネル API、libc、シェル、管理スクリプト) には非常に複雑な要素があり、これらは、作成によって引き起こされる危険性の回避策としてのみ存在します。 /tmp 共有されました。

最も早くて最低レベルの回避策はスティッキービットだと思います。

スティッキー ビットはモード ビット 01000 です。 unix ファイルのアクセス許可。として印刷されます t の代わりに x で rwt。

    drwxrwxrwt  5 root  wheel  160 Oct 22 10:22 /tmp/

もともと 1970 年代に、スティッキー ビットは、シェルなどの頻繁に使用されるプログラムを高速化するために発明されました。スティッキー ビットは、実行可能ファイルがコアに留まるべきであることをカーネルに示しました。この機能は、1980 年代にファイルシステムのページ キャッシュによって廃止されました。

スティッキー ビットは、セキュリティ上の問題を解決するために、ディレクトリ上の別の意味で再利用されました。 /tmp。

UNIX では、ファイルを削除する権限は、ファイル自体の権限とは関係なく、ファイルを含むディレクトリへの書き込みアクセスによって決まります。

したがって、ディレクトリ（たとえば、 /tmp) は誰でも書き込み可能で、その中のファイルは誰でも削除できます。

これはつまり /tmp ユーザーがお互いのファイルを削除することによって引き起こされる、あらゆる種類の偶発的または悪意のあるトラブルに対して脆弱でした。

これを修正するには、 スティッキー ディレクトリ内のファイルは、ユーザーがディレクトリに対する書き込み権限を持ち、ファイルの所有者、ディレクトリの所有者、またはスーパーユーザーである場合にのみ、ユーザーによって削除または名前変更できます。。

POSIX は以前、一時ファイルを作成する 5 つの方法を提供していましたが、そのうちの 3 つ (ほとんど!) は決して使用してはならず、その後非推奨になりました – 使用禁止のフットガンを除く tmpnam
これはまだ C 標準の一部です。その後、より複雑な状況をサポートするために、さらに 2 つの安全な機能が追加されました。

これらの関数には危険な API 設計上の問題がたくさんあります。重要な点は話し合うことでカバーできるので、詳しく焙煎することに時間を費やすつもりはありません。

これらすべての関数の目的は、他の同時アクティビティと衝突しない一時ファイル (またはディレクトリ) を作成することです。

ファイルを作成しているとき /tmp 危険なのは、別の悪意のあるユーザーが、その管理下にあるファイルを開かせる可能性があることです。この脆弱性を回避するには、(あるいはむしろ) mkstemp） しなければならない：

• を生成します 予測不可能な ファイル名。

  ファイル名は一意であるだけでは十分ではなく、十分な内容が含まれている必要があります。 安全な 敵がレースに勝てず、干渉できないというランダム性。

• ファイルを開く O_CREAT | O_EXCL。

  これにより、ファイルが別の悪意のあるプロセスによって作成されていないことが保証され、チェック時間や使用時間の脆弱性が発生しません。また、そのファイルが、攻撃者が誤って破損させようとする場所を指すシンボリックリンクではないことを保証します。

• オープンに失敗した場合は再試行してください EEXIST。

  名前のランダム性と合わせて、これによりサービス拒否の脆弱性が回避されます。

これは複雑で、完全に明白ではありません。一時ファイルを安全に作成できなかったこれまでの関数の試行がすべて失敗したことからもわかります。

の mktemp(1) コマンドは mkstemp(3) のラッパーです。 (少し紛らわしいのですが、安全ではないため、これは mktemp(3) のラッパーではありません。) OpenBSD によって導入され、まだ POSIX には含まれていませんが、広くサポートされています。そのマニュアルページには素晴らしい理論的根拠が含まれています。

の mktemp シェルスクリプトが一時ファイルを安全に使用できるようにするユーティリティが提供されています。従来、多くのシェル スクリプトは、接尾辞として pid を付けたプログラム名を取得し、それを一時ファイル名として使用します。この種の命名スキームは予測可能であり、それによって引き起こされる競合状態は攻撃者にとって勝利しやすいものです。より安全ではありますが、同じ命名スキームを使用して一時ディレクトリを作成する方法があります。これにより、一時ファイルが破壊されないことを保証できますが、それでも単純なサービス拒否攻撃が可能になります。これらの理由から、次のことが提案されています。
mktemp 代わりに使用されます。

シェル スクリプトは名前による一時ファイルの使用を避けることはできませんが、mktemp(1) はファイルを安全に作成し、それ以降は攻撃者がそのファイルに干渉できないため安全です。自分のものであることがわかっているファイルを再度開いても問題ありません。

私の後悔リストの最後の項目は「管理スクリプト」です。これは、 /tmp 掃除の仕事。

その性質上 /tmp ジャンクが蓄積する傾向があるため、古いファイルを削除する cron ジョブを使用するのが一般的でした。 (コンピューターがはるかに大型化した現在ではあまり一般的ではありません。)

これらのスクリプトには、チェック時間/使用時間の脆弱性、シンボリックリンクの不注意な処理、愚かにも使用された長時間実行プログラムの下からの敷物を引き出すなどの問題が発生する傾向がありました。 /tmp。 (これらのスクリプトが現在あまり一般的ではない理由は他にもたくさんあります!)

そこで、私は何十もの段落を費やして、以下に関連するバグと複雑さの概要を説明しました。 /tmp。もしそうならそれらはすべて避けられたかもしれない /tmp 存在しなかったので、結果としてすべてがより単純になったでしょう。

では、一時ファイルがそうでない場合、どこに行けばよいのでしょうか。 /tmp?

ユーザーごとに一時ディレクトリが必要です。実際、最新のシステムでは、 は ユーザーごとの一時ディレクトリ!しかし、この解決策は数十年遅すぎました。

ユーザーごとの場合 $TMPDIR その後、一時ファイル名は、mktemp(1) の理論的根拠で説明されている単純なメカニズム、または古い非推奨の C 関数で使用されるメカニズムを使用して安全に作成できます。攻撃を開始するための十分なアクセス権を持たない攻撃者に対して防御する必要はありません。誰でも書き込み可能なディレクトリがないため、スティッキー ディレクトリは必要ありません。

setuid プログラムは一時ファイルの作成方法についてより注意する必要があるという小さな問題がありますが、setuid プログラムはすべてについてより注意する必要があります。

では、なぜユーザーごとではなかったのか $TMPDIR 昔のこと？

おそらく主な理由はパス依存性でした。 /tmp 問題が明らかになる前に作成され、広く使用されていましたが、その時点では非推奨にすることが困難でした。

1990年っぽいのを望まなかったのには理由があります $TMPDIR ホームディレクトリに置くには:

修正は、はるか昔に、login(8) が特権を落とす前に適切な場所にユーザーごとの一時ディレクトリを作成し、 $TMPDIR これにより、ユーザーのシェルと子プロセスがそれを見つけることができます。

そうですね、安全でない一時ファイルの脆弱性が存在しなかったら、私たちが見逃していたであろうすべての興奮を考えてみてください。