pam_exec.soがsuではなくsudoで動作するのはなぜですか?

pam_exec.soがsuではなくsudoで動作するのはなぜですか?

su私は、特別なプログラムの正常な実行に基づいて通常のユーザーシェルからrootアクセスを許可したいと思います。両方を持ち、sudo新しいPAM構成に応答するという目標があります。特別プログラムが承認のための唯一の基準です。

Debian 9 で試した /etc/pam.d/common-auth の設定は次のとおりです。

auth  [success=done default=die]  pam_exec.so seteuid /usr/bin/whoami

...whoami特別プログラムのプレースホルダで成功ステータスを返すプログラムはどこにありますか?共通認証ファイルの残りの部分はコメントアウトされています。

/etc/pam.d/su ファイルには以下が含まれます。

auth       sufficient pam_rootok.so
session       required   pam_env.so readenv=1
session       required   pam_env.so readenv=1 envfile=/etc/default/locale
session    optional   pam_mail.so nopen
session    required   pam_limits.so
@include common-auth
@include common-account
@include common-session

その結果、承認されsudoますが、以下はsu承認されません。

$ su
su: Permission denied

(システム認証ファイルを使用すると、Fedora 25でも同じ結果が得られます。sudoは機能しますがsuは機能しません。)

supam_execとの作業を拒否しているようです。私はこの時点で迷っていて、これを見つけるためにいくつかの手がかりを使うことができます。


/var/log/messages を見てみると、su次のことが記録されます。

Mar 18 08:46:39 localhost kernel: [   61.622184] audit: type=1100 audit(1489841199.166:114): pid=1107 uid=1000 auid=1000 ses=1 msg='op=PAM:authentication acct="root" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/0 res=success'
Mar 18 08:46:39 localhost kernel: [   61.622480] audit: type=1101 audit(1489841199.166:115): pid=1107 uid=1000 auid=1000 ses=1 msg='op=PAM:accounting acct="root" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/0 res=success'
Mar 18 08:46:39 localhost kernel: [   61.623224] audit: type=1103 audit(1489841199.167:116): pid=1107 uid=1000 auid=1000 ses=1 msg='op=PAM:setcred acct="root" exe="/bin/su" hostname=? addr=? terminal=/dev/pts/0 res=failed'

比較のために、次のことが起こりますsudo

Mar 18 08:47:00 localhost kernel: [   82.750720] audit: type=1123 audit(1489841220.294:117): pid=1110 uid=1000 auid=1000 ses=1 msg='cwd="/home/user" cmd=67726570202D69206175646974202F7661722F6C6F672F6D65737361676573 terminal=pts/0 res=success'
Mar 18 08:47:00 localhost kernel: [   82.751369] audit: type=1110 audit(1489841220.295:118): pid=1110 uid=0 auid=1000 ses=1 msg='op=PAM:setcred acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=failed'
Mar 18 08:47:00 localhost kernel: [   82.751814] audit: type=1105 audit(1489841220.295:119): pid=1110 uid=0 auid=1000 ses=1 msg='op=PAM:session_open acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'


修正する

私はDebianがこの問題をどのように扱うかを反映する解決策を見つけました。まず、Debianのデフォルトのcommon-auth関連行を示します。

auth  [success=1 default=ignore]  pam_unix.so nullok_secure
auth  requisite  pam_deny.so
auth  required   pam_permit.so

これはQubes認証プロンプトを使用する代替方法です。

auth  [success=1 default=ignore]  pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /bin/grep -q ^1$
auth  requisite  pam_deny.so
auth  required   pam_permit.so

この「1つのスキップ」は成功した場合にのみ許可され、それ以外の場合は拒否されます。

@hildredはpam_permit行を使用してスタックを「起動」することを提案しました。今後pam_exec行(決定が下される場所)は表現力が少なくても有効で、明確な解決策を見つけることができます。

ベストアンサー1

私がすぐに見ることができる2つの問題(ただ1つのサービスではなく、一般的に実験的なpamを設定しようとすることに加えて)suは常にrootとして認証しますが、sudoは通常ユーザーとして認証し、suには十分な認証ラインがあるため角かっこ表記法を使用できるということです。公開ファイルから。角カッコ表記が必ずしも成功状態を設定するわけではありません。これは、execの前にauth require allowed行を追加したり、ユースケースで不要な角かっこ表記を削除したり、root ok行に角括弧表記を使用して十分なテストに合格しなくても、否定的な成功が確立されないようにすることで解決できます。

おすすめ記事