sudoでfindを安全に使用する


10

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

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

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

find制限を使用して作業できますか?


14
通常、ファイル名パターンの検索結果に、実際にアクセスできないファイルが含まれること望ましくありません。その点であなたの要件は少し奇妙です。
HBruijn

2
誰もあなたに質問に参加することを強制しません。Server Faultの目的の1つは、奇妙な状況のフォーラムとして機能することです。
Troels Arvin 2017

2
Server Faultはフォーラムではなく、逆心理学の試みはHBruijnの観察の有効性を変更しません(確かに、あなたを助けるための試みで提起されたと思います)。
オービットのライトネスレース2017年

回答:


19

何を見つけますか

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

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

または多分移動します:

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

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


良いアイデア。なぜこれを考えなかったのか分かりません。しかし、sudoルールでユーザーが「locate」コマンドを実行できる場合、「-d」パラメーターを使用して任意のファイルを読み取ることができると思いますか?
Troels Arvin 2017

2
@TroelsArvin:locate必要ありませんsudo。そのupdatedb仕事だけが特別な特権を必要とします。したがって、ユーザーが実行したり実行したりすることはできませんsudo locate
jwodder 2017年

1
@jwodder:RHEL 7サーバーの場合:ユーザーuが/ data / fooにアクセスできないとします。/ data / fooには、「somefile.csv」というファイルがあります。ここで、uが「locate somefile.csv」を実行すると、ユーザーuがsudoを介して「locate」を実行しない限り、「locate」からの出力には/data/foo/somefile.csvが含まれません。(「--nofollow」引数を使用しても効果はありません。)
Troels Arvin

1
@TroelsArvinですが、-dフラグはデータベースパスのみを設定しますか?多分私はあなたを誤解しました。
Lenniey

21

による 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、Linuxのsetuidチェックの性質上、ライブラリシム攻撃などの明らかなものは機能せず、機能ビットが取得されません(生のsetuidとは異なり)いずれかの子プロセスによって継承されるので、これもまたボーナスです。

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

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

したがって、注意を払い、それを行う場合は注意してください。明らかなことがうまくいかなくても、これに伴うリスクがあることを理解してください。

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


5
これは確かに非常に興味深いですね。
スヴェン

このような?まあ、PoCはありませんが、それでも興味深いものです。forums.grsecurity.net
Lenniey

このアイデアは気に入っていますが、重大な欠点があります。sudofindは、システム上のソフトウェア(RPMなど)パッケージの一部ではないバイナリになりました。したがって、ディストリビューションが「find」のパッチを送信した場合、sudofindは更新されません。
Troels Arvin 2017

2
@TroelsArvinそれは必ずしも悪いことではありません。これらの機能用に設計されていない既存のユーティリティにsetuidのような機能を追加する場合、更新されたユーティリティが非標準で安全に使用できることを確認する前に、基になるユーティリティを更新しないでください。機能。この場合、更新によって、findユーザーが提供するコードを直接実行する機能が提供される場合と同じように想像awkできます。
Andrew Henle

4
これで私が目にすることができる最大の問題は、検索不可能なディレクトリの下にある世界中の書き込み可能なディレクトリが突然書き込まれることです。
Tavian Barnes

2

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

デフォルトでは022、umaskがの場合、ディレクトリが作成されるので、誰もがその中のファイルをリストおよび統計できます。そうでない場合は、ディレクトリのアクセス許可を手動でビット単位または古いアクセス許可に変更できます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
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.