web-dev-qa-db-ja.com

pam_exec.soがsuではなくSudoで機能するのはなぜですか？

特別なプログラムの正常な実行に基づいて、通常のユーザーShellからのrootアクセスを許可しようとしています。目標は、suとSudoの両方が新しいPAM構成に応答するようにすることです。特別プログラムは、認可の唯一の基準です。

/etc/pam.d/common-authのDebian9で試している設定は次のとおりです。

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

...ここで、whoamiは、特別なプログラムのプレースホルダーとして成功ステータスを返すプログラムです。 common-authファイルの残りの部分はコメントアウトされています。

/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

（system-authファイルを使用したFedora 25でも同じ結果：Sudoは機能し、suは機能しません。）

suが単にpam_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'

更新

@hildredが指摘したように、さまざまなコンテキストで認証されるさまざまなコマンドにもかかわらず、成功または失敗の確実な判断を得ている、この問題を処理する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行を使用してスタックを「プライム」する提案before pam_exec行（決定が行われる場所）は表現力が劣りますが、機能し、私を見つける道に導きます。明確な解決策。

debianfedorapamsu
5
tasket

私がすぐに目にする2つの問題があります（1つのサービスではなく共通で実験的なpam構成を試す以外）、suは常にrootとして認証されますが、Sudoは通常ユーザーとして認証され、suには十分な認証行があり、共通ファイルのブラケット表記。角かっこ表記は、必ずしも成功状態を設定するとは限りません。これは、execの前にauth require permit行を追加するか、ユースケースの場合は角かっこ表記を削除するか、十分なテストに失敗しても否定的な成功が設定されないようにrootok行に角かっこ表記を使用することで修正できます。 。

0
hildred