web-dev-qa-db-ja.com

sudoでfindを安全に使用する

Linuxサーバーでは、ユーザーのグループからroot権限を削除する必要があります。ただし、これらのユーザーには、「検索」ユーティリティを使用して、ファイル名、変更日、その他のメタデータに基づいてファイルを検索できる正当な理由があります。

サーバーでは、ファイル名は機密ではありませんが、ファイルの内容は機密である可能性があります。

Sudoを使用して、ユーザーがサーバー上の任意の場所にあるファイルを検索できるようにしたいと考えています。 「検索」ユーティリティは素晴らしいですが、「-exec」を使用して任意のコマンドを生成するなど、あらゆる種類の副作用を許可します。

findを私の制限で動作させることはできますか？

linuxsudofind
10
Troels Arvin

locate はどうですか？

locateは、updatedb（8）によって準備された1つ以上のデータベースを読み取り、少なくとも1つのPATTERNに一致するファイル名を1行に1つずつ標準出力に書き込みます。 --regexが指定されていない場合、PATTERNにはグロビング文字を含めることができます。 PATTERNにグロビング文字が含まれていない場合、locateは、パターンが[〜＃〜] pattern [〜＃〜]であるかのように動作します。

デフォルトでは、locateはデータベースで見つかったファイルがまだ存在するかどうかをチェックしません。 Locateは、関連するデータベースの最新の更新後に作成されたファイルを報告することはできません。

あるいは多分 slocate ：

Secure Locateは、システム上のファイルにインデックスを付けてすばやく検索するための安全な方法を提供します。 GNU Locateのようにインクリメンタルエンコーディングを使用して、データベースを圧縮して検索を高速化しますが、ファイルのアクセス許可と所有権も保存するので、アクセスできないファイルがユーザーに表示されることはありません。

このマニュアルページには、GNU slocateのバージョンが記載されています。slocateシステムユーザーがファイルシステム全体を無許可のファイルを表示せずに検索できるようにします。

19
Lenniey

man 7 capabilitiesによると

   CAP_DAC_READ_SEARCH
          * Bypass file read permission checks and directory read and execute permission checks;
          * Invoke open_by_handle_at(2).

これでうまくいきました。 （ '＃'で始まる行はroot、 '$'の行は非rootです）この場合、非rootユーザーはwheelグループに属しています。

# cp /usr/bin/find /usr/bin/sudofind
# chmod 710 /usr/bin/sudofind
# chown root:wheel /usr/bin/sudofind
# setcap cap_dac_read_search+ep /usr/bin/sudofind
# exit
$ find /root 
find: ‘/root’: Permission denied
$ sudofind /root
/root /root 
/root/Testbed 
...
... 
$ sudofind /root -exec cat {} \;
cat: /root: Permission denied 
cat: /root/Testbed: Permission denied
$ sudofind /root -printf "%u %g %m %c %p\n"
root root 644 Mon Apr 20 09:20:48.0457518493 2015 /root
root root 755 Fri Dec  4 02:34:03.0016294644 2015 /root/Testbed
...
...
$ # Capability inheritance test..
$ sudofind /root -exec /bin/sleep 10 \; &
[1] 17017
$ getpcaps $(pgrep find)
Capabilities for `17017': = cap_dac_read_search+ep
$ getpcaps $(pgrep sleep)
Capabilities for `17019': =

機能が付与するものを考えると、それはまさにあなたが望むものに適合します。 findにファイル内のバイトを読み取ることができる機能があるかどうかを徹底的にチェックしていませんが、LD_PRELOADのような明らかなものやライブラリシム攻撃は、setuidチェックの性質上機能しないはずですLinuxでは、機能ビットも子プロセスに継承されません（生のsetuidとは異なります）。これは別のボーナスです。

あなたがしたいことは一時的なファイルの作成やアクセスに関してプライバシーの問題を引き起こす可能性があることを覚えておいてください、そしてプログラムは競合状態/特権エスカレーションの試み（有名なファイル名を作成するプログラムに対して）の基礎として使用できますただし、正しいセキュリティチェックは行わないでください）。

また、一部の不適切に記述されたアプリケーションは、意味を伝えたりデータを非表示にする方法として、ファイルメタデータまたはツリー構造に依存している場合があります。これにより、制限された情報がリリースされたり、他の方法では知られていない特権ドキュメントが公開されたりすることがあります（あいにく、セキュリティは不明ですが、これは特にクローズドソースベンダーが行いたいことです）。

したがって、注意してそれを行うことに注意し、明白なことがうまくいかなくても、これに関連するリスクがあることを理解してください。

ああ、私は、誰かがこのメカニズムをコメントの特権昇格の基礎として使用する概念実証攻撃を持っているかどうかに興味があります！

21
Matthew Ife

ユーザーに適切な権限を与えます。

デフォルトでは、umaskが022の場合、ディレクトリが作成されるので、誰もがその中のファイルをリストして統計をとることができます。そうでない場合は、ディレクトリの権限をビット単位または古い権限と0555に手動で変更できます。

chmod +0555 foo

また、それらのユーザーがそのディレクトリのすべての親（たとえば、別のユーザーのホームディレクトリ）に対する実行権限を持っていない場合、おそらく最初のディレクトリを別の場所に置く必要があります。

一部のユーザーのみにそのディレクトリの読み取りと実行を許可する場合は、そのモードを0750に変更し、それらのユーザーをグループに入れ、ディレクトリのグループ所有者をそのグループに変更します。

groupadd can_read_foo
chmod 0750 foo
chgrp can_read_foo foo
gpasswd -a alice can_read_foo
gpasswd -a bob can_read_foo
2
yt7b97q-