+++ This bug was initially created as a clone of Bug #1328735 +++ I just upgraded to rawhide on a machine with unconfined disabled: rlpowell@vrici> sudo ls foo rlpowell@vrici> sudo ls . sudo: unable to execute /bin/ls: Bad address rlpowell@vrici> sudo ls /bin/ sudo: unable to execute /bin/ls: Bad address rlpowell@vrici> Now, here's the thing. When it's doing this, we have: root@vrici# cat /etc/sudoers.d/rlpowell rlpowell ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r ALL rlpowell ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r NOPASSWD: /usr/sbin/service rlpowell ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r NOPASSWD: /usr/bin/docker If I change it to: root@vrici# cat /etc/sudoers.d/rlpowell rlpowell ALL=(ALL) TYPE=unconfined_t ALL rlpowell ALL=(ALL) TYPE=unconfined_t NOPASSWD: /usr/sbin/service rlpowell ALL=(ALL) TYPE=unconfined_t NOPASSWD: /usr/bin/docker , then sudo works fine: rlpowell@vrici> sudo ls /tmp/crap foo except that it doesn't appear to, you know, actually elevate my permissions in any way: rlpowell@vrici> sudo ls -l /var/log/httpd/ ls: cannot access '/var/log/httpd/': Permission denied Presumably because: rlpowell@vrici> sudo id -a uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023 It is, however, not a *simple* selinux problem, if it's an selinux problem at all (I just figured here was a good place to start) because: rlpowell@vrici> getenforce Permissive rlpowell@vrici> sudo id -a sudo: unable to execute /bin/id: Bad address The bad call in strace: [pid 8540] execve("/usr/libexec/sudo/sesh", ["sesh", "/bin/ls", "/bin/", 0x6574616572637965, 0x6d65747379733a00, 0x31, "\260\310\4\23,V", "\260\310\4\23,V"], [/* 20 vars */]) = -1 EFAULT (Bad address) --- Additional comment from Robin Powell on 2016-04-20 04:08:05 EDT --- The error occurs even with: root@vrici# cat /etc/sudoers.d/rlpowell rlpowell ALL=(ALL) TYPE=staff_t ROLE=staff_r ALL even though: rlpowell@vrici> id -a uid=1000(rlpowell) gid=1000(rlpowell) groups=1000(rlpowell),10000(users) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023 So apparently the error is "sudo with ROLE= explodes", which is seeming less and less like an SELinux issue as such. --- Additional comment from Robin Powell on 2016-04-20 04:17:34 EDT --- Erm, sorry, apparently the error is "sudo with ROLE= explodes, but only if there are arguments given to the command". 0.o "sudo ls" works; "sudo -i" works. Bizarre stuff. --- Additional comment from Daniel Walsh on 2016-04-20 09:15:47 EDT --- Any AVC's? Any AVC's if you disable dontaudit rules? --- Additional comment from Robin Powell on 2016-04-20 13:50:15 EDT --- Here's everything from my (somewhat noisy) audit log during a failed sudo run, with "dontaudit off" and "setenforce 0": type=AVC msg=audit(1461174570.403:6245): avc: denied { rlimitinh } for pid=3450 comm="sudo" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tclass=process permissive=1 type=AVC msg=audit(1461174570.403:6246): avc: denied { siginh } for pid=3450 comm="sudo" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tclass=process permissive=1 type=USER_CMD msg=audit(1461174570.417:6247): pid=3450 uid=1000 auid=1000 ses=19 subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 msg='cwd="/tmp/crap" cmd=6C73202F746D702F63726170 terminal=pts/9 res=success' type=CRED_REFR msg=audit(1461174570.417:6248): pid=3450 uid=0 auid=1000 ses=19 subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/9 res=success' type=USER_START msg=audit(1461174570.424:6249): pid=3450 uid=0 auid=1000 ses=19 subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/9 res=success' type=USER_ROLE_CHANGE msg=audit(1461174570.425:6250): pid=3451 uid=0 auid=1000 ses=19 subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 msg='newrole: old-context=staff_u:staff_r:staff_t:s0-s0:c0.c1023 new-context=staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/9 res=success' type=USER_END msg=audit(1461174572.426:6251): pid=3450 uid=0 auid=1000 ses=19 subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/9 res=success' type=CRED_DISP msg=audit(1461174572.426:6252): pid=3450 uid=0 auid=1000 ses=19 subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/9 res=success' --- Additional comment from Robin Powell on 2016-04-22 03:10:07 EDT --- Is there any further debugging I can provide of any kind? Having a basically unusable sudo is ... distressing. --- Additional comment from Daniel Kopeček on 2016-04-22 08:11:13 EDT --- (In reply to Robin Powell from comment #5) > Is there any further debugging I can provide of any kind? Having a > basically unusable sudo is ... distressing. Hello, I would say this is a bug in sudo, not in the policy. However, I don't have a solid proof that yet. I'll try to replicate the issue and debug it from there. Have you used this setup with previous versions of sudo? Could this be a regression? Is so, that would help with hunting down the root cause of this. --- Additional comment from Robin Powell on 2016-04-22 13:55:46 EDT --- At this point I would also say that it also feels like a bug in sudo, because Permissive doesn't fix it, and it only happens when the command has an argument. My sudo config did not change at all; the only thing that changed was going from F23 to Rawhide (rawhide as of a few days ago). Here's a minimal test: Defaults env_reset root ALL=(ALL) NOPASSWD: ALL rlpowell ALL=(ALL) NOPASSWD: ALL ^^ that's my entire sudoers. rlpowell@vrici> sudo ls /tmp/ | wc -l 152 rlpowell@vrici> sudo -r sysadm_r ls | wc -l 152 rlpowell@vrici> sudo -r sysadm_r ls /tmp/ sudo: unable to execute /bin/ls: Bad address --- Additional comment from Daniel Walsh on 2016-04-29 15:15:01 EDT --- I am seeing the same issue on my Rawhide system. Was working fine on fedora 24. --- Additional comment from Robin Powell on 2016-05-05 20:48:43 EDT --- Anything I can do to help debug this? It's really pretty unpleasant. --- Additional comment from Robin Powell on 2016-05-11 11:40:11 EDT --- *poke* --- Additional comment from Daniel Kopeček on 2016-05-11 15:08:25 EDT --- Hello, (In reply to Robin Powell from comment #10) > *poke* I've found the bug that is causing this issue and reported upstream. If you'd like, you can test this package with the proposed patch: https://fedorapeople.org/~dkopecek/sudo/sudo-1.8.16-2.fc22.src.rpm Anyway, once some variation of the fix is pushed upstream, I'll make an update in Fedora. --- Additional comment from Daniel Kopeček on 2016-05-11 15:09 EDT --- --- Additional comment from Daniel Kopeček on 2016-05-11 17:22:53 EDT --- Fixed upstream: https://www.sudo.ws/repos/sudo/rev/1246583c7c1f --- Additional comment from Daniel Kopeček on 2016-05-12 03:36 EDT ---
Created attachment 1156492 [details] upstream patch
sudo-1.8.16-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a04f1b9b97
sudo-1.8.16-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-a04f1b9b97
Created attachment 1157055 [details] proposed patch
sudo-1.8.16-3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5680e43366
sudo-1.8.16-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5680e43366
sudo-1.8.16-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.