☰

root以外のユーザーとしてsetuidバイナリをデバッグする

tag-icon • tag-icon setuid gdb
root以外のユーザーとしてsetuidバイナリをデバッグする

CentOS 7システムがあります。すでに実行されているアプリケーションにGDBを接続する必要があります（明らかに一般的な）「ptrace：Operation not allowed」というメッセージが表示されます。間違い。 GDBをrootとして実行すると、このエラーを回避できますが、それに依存したくありません。

この質問を調べた結果、/proc/sys/kernel/yama/ptrace_scope値を変更し0たりファイルを永久に回復したりすることができるといういくつかの答えが見つかりました/etc/sysctl.d/10-ptrace.conf。

まあ、明らかに誰もがあなたがYAMAを使用していると思いますが、ここではそうではありません。しかし、私は私の状況について何をすべきかを見つけることができませんでした。

確認してみると、私のシステムはSELinuxで設定されているようですが、アクティブではありませんでした。私のカーネルブート設定にはフラグselinux=0とコマンドが含まれています。

grep CONFIG_SECURITY /boot/config-`uname -r`

読む

# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_SECURELEVEL=y
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set

ついにgetsebool deny_ptrace帰ってきたgetsebool: SELinux is disabled。

私が理解しているように、LSMは現在私のシステムではアクティブではありませんが、まだptraceによって制限されています。ここで次にどこに行くべきか、さらにこの時点でptraceが制限される原因が何なのかもしれません。

私の実行可能ファイルに設定されたsetuidビットがこの問題を引き起こす可能性はありますか？ gdbとアプリケーション自体は、特別に追加されたスーパーユーザー権限なしで同じユーザーを使用して起動されます。ps -eouid,commまた、どちらも同じuidを持っていることを示しています。アプリケーションのみ setuid ビットで実行され、ファイルは root:root に属します。

ベストアンサー1

特権を持つプログラムをデバッグすると、実際にデバッガに同じ特権が与えられます。したがって、セキュリティ設定に関係なく追加の権限を持つプログラムをデバッグするには、デバッガに少なくともその権限が必要です。たとえば、setuidプログラムには元のユーザーとターゲットユーザーの両方に対する権限があるため、デバッガーには両方のユーザーに対する権限が必要です。実際、これはデバッガがルートでなければならないことを意味します。 Linuxでは、デバッガにこの機能を提供するだけで十分です。CAP_SYS_PTRACEこれは、デバッガの有効な権限を低下させませんが、デバッガが誤って他のユーザーのファイルを上書きできないことを意味します。

追加の権限なしでプログラムの実行中にデバッグする方が便利です。これに応じてファイル権限、パスなどを調整してください。特権デバッガを実際に使用する必要がある場合は、デバッガを root として実行する必要があります。 Linuxでは、関連する両方のユーザーが含まれているユーザーの名前空間のルートである可能性があります。

おすすめ記事