☰

/dev/fd sudoでシェルスクリプトを安全に実行するには？

tag-icon • tag-icon shell-script security sudo root setuid
/dev/fd sudoでシェルスクリプトを安全に実行するには？

マニュアルページの最後にsudo次の注意事項があります。

   Running shell scripts via sudo can expose the same kernel bugs that
   make setuid shell scripts unsafe on some operating systems (if your OS
   has a /dev/fd/ directory, setuid shell scripts are generally safe).

その詩のほとんどすべてが私にとってはあいまいです。特にこの暗示が/dev/fd何であるか知りたいです。私はこの情報を見つけることができるいくつかのマニュアルページを推測しようとしましたが、手ぶらで出てきました。

どんな提案がありますか？

（最終的に可能であれば、cronを介してsudoでいくつかのスクリプトを実行したいのですが、もちろん、これらの管理されていない配列で発生する可能性があるセキュリティの脆弱性が心配されます。）

ベストアンサー1

これがどのように適用されるかわかりませんsudo。

setuidスクリプトの場合、アイデアは次のとおりです。

/usr/local/bin/myscriptsetuidルートがあるとします#! /bin/sh。誰も/usr/local/bin書き込み権限を持っていませんが、myscript誰でも次のことができます。

ln -s /usr/local/bin/myscript /tmp/-i

また、/tmp/-iまだ書き込みアクセス権がありませんが/tmp。

setuid スクリプトが setuid を介して実行されないシステムでは、setuid ビットは次の/dev/fd実行時に root として実行されることを意味します。cd /tmp && -i/bin/sh -i

  1. プロセスはeuidをファイル所有者に変更します。
  2. システム解析 shebang
  3. システム実行（継続ルートとして）、/bin/sh -i

この特別なケースに対する簡単な修正は、shebangを推奨事項に従って書くことです。#! /bin/sh -しかし、それにもかかわらず、まだ競争条件があります。これで、次のようになります。

  1. プロセスはeuidをファイル所有者に変更します。
  2. システム解析 shebang
  3. システム実行（継続ルートとして）、/bin/sh - -i
  4. 「sh」は現在ディレクトリにある「-i」ファイルを開きます（大丈夫だと思います）。

しかし、上記の3と4の間には、「-i」または（ここでは他の攻撃ベクトルなので、「すべてのファイル」）を何かに変更するのに十分です。邪悪なたとえば、「-i」ファイルには「sh」のみが含まれ、ルートシェル（setuidルートスクリプト用）を取得します。

以前のバージョンでは、kshこれを行う必要はありません。 4では、kshが最初に「-i」を探す$PATHので、変更するのに十分です。邪悪な"-i" $PATH（ksh代わりにそのファイルを開きます/tmp）。

これらの攻撃ベクトルはすべて、次の場合に固定されます。cd /tmp; -iシステムは次のことを行います（まだexecveシステム呼び出し中）。

  1. アトミック：ファイルがsetuidであることを確認し、xプロセスのファイル記述子の1つでファイルを開きます。
  2. ファイル所有者euidの変更を処理します。
  3. 走る/bin/sh /dev/fd/x
  4. sh/dev/fd/xdを参照するファイルのみ開くことができますexecve。

鍵は、ファイルがexecveの一部として開かれたことです。したがって、変更された権限として解釈される信頼できるコンテンツを含むコードであることがわかります。

今sudo戦略sudoはpath。

sudoルールによれば、/usr/local/bin/myscriptをrootとして実行できるとしたら、次のことができます。

sudo /usr/local/bin/myscript

ただし、次の場合は次のことはできません。

sudo /tmp/any-file

「すべてのファイル」はAFAICTとしては使用されません/usr/local/bin/myscript。sudo/dev/fd

おすすめ記事