私は関数LD_PRELOAD
をオーバーライドするために使用しましたread
。最小のテストアプリの場合はうまく機能しますが、より大きなアプリでテストしても動作しなくなります。また、LD_DEBUG=all
何も表示しません。
LD_DEBUG=all LD_PRELOAD=./lib.so ./big_app
これは単に実行され、./big_app
何LD_PRELOAD
の効果もありません。これをデバッグする方法はありますか?
ベストアンサー1
この回答はGNU / Linux環境でのみ有効です。
コメントによると、OPのバイナリは特権機能、つまり機能を追加します。これはld.so(8)
次のように切り替わります。安全実行モードどの基本的にLD_PRELOAD
とを含むほとんどの動的リンカー固有の環境変数を無効にしますLD_DEBUG
。
セキュリティ上の理由から、動的リンカーがバイナリを次の場所で実行する必要があると判断した場合:安全な実行モード、一部の環境変数の影響が無効化または変更されます。[...]
[...]に以下が含まれている場合、バイナリはセーフモードで実行されます。
プロセスの実ユーザー ID と実効ユーザー ID が異なっているか、実グループ ID と実効グループ ID が異なります。 [...]
root以外のユーザーIDを持つプロセスが機能バイナリを実行しました。このプロセスで。
[...]
しかし根次の前提条件を満たすように構成できるシステムにアクセスします。安全実行モードroot以外のユーザーとして実行している場合、これら2つのパラメータはまだ説明通りです。ld.so(8)
:
[...]
セーフランモードで、スラッシュを含むプリロードパス名は無視されます。また、共有オブジェクトは、標準の検索ディレクトリからのみプリロードされます。そしてユーザーIDモードビットを設定できる場合のみ(通常の場合ではありません)
標準検索ディレクトリとは何ですか?彼らは出力を提供しますld.so --help
。たとえば、Debian amd64/x86_64 の場合:
$ ld.so --help
[...]
Shared library search path:
(libraries located via /etc/ld.so.cache)
/lib/x86_64-linux-gnu (system search path)
/usr/lib/x86_64-linux-gnu (system search path)
/lib (system search path)
/usr/lib (system search path)
[...]
最後に、共有オブジェクトファイルは次のいずれかの場所になければなりません。テストでは:
u+s
モードを設定する限り、ルートが所有する必要はありません。u+s
シンボリックリンクが正しい場所にある限り、これはどこでも実際のファイルへのシンボリックリンクになります。- にはパスがあってはならず、場所で
LD_PRELOAD
はなく(a)ファイル名のみが必要です。/
- バイナリの機能がファイルを読み取るためのランダムアクセスを許可しない場合、共有オブジェクトは単一のユーザーまたはグループのみを許可するようにモードを設定できます(
chmod o-rwx
通常は正しい所有権を適用して設定し、復元する必要がu+s
あります)。 setuid-rootまたはCAP_DAC_OVERRIDE
/の場合、CAP_DAC_READ_SEARCH
これらの特権バイナリを実行しているユーザーがライブラリを使用するのを防ぐことはできません。
[...]glibc 2.3.4以降、
LD_DEBUG
/etc/suid-debug
ファイルが存在しない限り、セーフモードでは無視されます。(ファイル内容は関係ありません。)
ユーザーまたはグループに限定する方法が見つかりませんでした。
はい(rootアクセスを使用sudo
):
$ sudo touch /etc/suid-debug
$ sudo cp -aiL ./lib.so /usr/lib/lib.so
$ sudo chmod u+s /usr/lib/lib.so
では、通常のユーザーとして実行を許可し、2つの変数を考えてみましょう。
LD_DEBUG=all LD_PRELOAD=lib.so ./big_app