pam_exec.so가 su가 아닌 sudo에서는 작동하는 이유는 무엇입니까?

pam_exec.so가 su가 아닌 sudo에서는 작동하는 이유는 무엇입니까?

su저는 특별한 프로그램의 성공적인 실행을 기반으로 일반 사용자 셸에서 루트 액세스를 허용하려고 합니다. 두 가지를 모두 갖고 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'


고쳐 쓰다

나는 데비안이 이 문제를 처리하는 방식을 반영하는 솔루션을 찾았으며 @hildred가 지적했듯이 다양한 명령이 다른 컨텍스트에서 인증됨에도 불구하고 여전히 성공 또는 실패를 결정할 수 있습니다. 먼저 데비안의 기본 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

이 "하나 건너뛰기"는 성공한 경우에만 허용되고, 그렇지 않으면 거부됩니다.

@hildred는 pam_permit 라인을 사용하여 스택을 "시작"할 것을 제안했습니다.앞으로pam_exec 줄(결정이 내려지는 곳)은 표현력이 덜하지만 유효하며 이를 통해 명확한 해결책을 찾을 수 있습니다.

답변1

내가 즉시 볼 수 있는 두 가지 문제(단지 하나의 서비스가 아닌 일반에서 실험적인 pam 구성을 시도하는 것 외에) su는 항상 루트로 인증하는 반면 sudo는 일반적으로 사용자로 인증하고 su에는 충분한 인증 라인이 있으므로 대괄호 표기법을 사용할 수 있다는 것입니다. 공개 파일에서. 대괄호 표기법이 항상 성공 상태를 설정하는 것은 아닙니다. 이는 exec 전에 auth require allowed 라인을 추가하거나 사용 사례에서 필요하지 않은 대괄호 표기법을 제거하거나 루트 ok 라인에 대괄호 표기법을 사용하여 충분한 테스트를 통과하지 못해도 부정적인 성공이 설정되지 않도록 하여 해결할 수 있습니다.

관련 정보