web-dev-qa-db-ja.com

Linux機能（setcap）はLD_LIBRARY_PATHを無効にしているようです

私が使う LD_LIBRARY_PATHアプリケーションの特定のユーザーライブラリのパスを設定します。しかし、このアプリケーションに機能を設定すると

Sudo setcap CAP_NET_BIND_SERVICE=eip myapplication

次にLD_LIBRARY_PATH無視されているようです。プログラムを起動すると、Linuxは特定の共有ライブラリが見つからないと文句を言います。

拡張された権限を持つアプリケーションがハイジャックされるのを防ぐために、何らかの保護が開始されていると思います。回避策はありますか？

linuxshared-librarieslinux-capabilities
28
Lorenzo Pistone

はい、セキュリティ上の理由から無効になっています。

4
Lorenzo Pistone

他の回答ですでに述べたように、この動作は意図されたものです。アプリケーションを自分でコンパイル（または少なくともリンク）できる場合は、何らかの回避策があります。次に、-Wl,-rpath <yourDynamicLibraryPath>をgccに渡すか、-rpath <yourDynamicLibraryPath>をldに渡すことができ、実行時にLD_LIBRARY_PATHを指定する必要はまったくありません。

10
scai

manページ for Sudoの説明：

ほとんどのオペレーティングシステムのダイナミックリンカは、Sudoを含むsetuid実行可能ファイルの環境からダイナミックリンクを制御できる変数を削除することに注意してください。オペレーティングシステムによっては、これにはRLD *、DYLD*、LD _、LDR _、LIBPATH、SHLIB_PATHなど。これらのタイプの変数は、Sudoが実行を開始する前に環境から削除されるため、Sudoがそれらを保持することはできません。

このリンクで説明されています のように、これを行うための実際のメカニズムはglibcにあります。 UIDがEUIDと一致しない場合（これは、setuidを含むすべてのSudoプログラムの場合です）、すべての「安全でない環境変数」が削除されます。したがって、昇格された特権を持つプログラムは変更なしで実行されます。

8
chrisaycock

Linuxでのこの問題の解決策は次のとおりです。

ディレクトリに移動します$cd /etc/ld.so.conf.d/新しいファイルを作成します$ touchxyz.conf任意のエディターを使用してこのファイルを開きます$vi xyz.conf

このファイルにダイナミックライブラリパスを1行ずつ追加します。パスが次の場合：

/home/xyz/libs1:/home/xyz/libs2/:/home/xyz/libs3/この場合、このファイルには次の3つのエントリがあります。/home/xyz/libs1//home/xyz/libs2//home/xyz/libs3/

次に、このファイルを保存して、次のコマンドを実行します。$ldconfig

上記のすべての操作は、rootログインから実行する必要があります

5
user2706978

考慮すべき代替策は、rpathを設定するためにpatchelfを使用して、コンパイルが不十分なELF共有ライブラリおよび/または実行可能ファイルを「修正」することです。 https://nixos.org/patchelf.html

ld.so.confは必ずしも確実な賭けではありません。実行しているものが適切にコンパイルされていれば機能します。私の場合、特定の特別にパッケージ化されたベンダーのApache製品では、コンパイルが非常に不十分でした。一意の.soファイル名を使用していなかったため、非常に重要な一般的に使用されるライブラリを提供するベースRHELリポジトリのRPMからの.soファイル名と競合していました。 。したがって、これがそれらの使用方法を分離する唯一のオプションでした。ベンダーのlibパス内のこれらの共有オブジェクトに対してld.so.confを使用すると、yumを含む多くのものが吹き飛ばされ、システム全体でglibc共有ライブラリの障害が発生します。

1
Heather C