Hide Forgot
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)
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.
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.
Any AVC's? Any AVC's if you disable dontaudit rules?
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'
Is there any further debugging I can provide of any kind? Having a basically unusable sudo is ... distressing.
(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.
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
I am seeing the same issue on my Rawhide system. Was working fine on fedora 24.
Anything I can do to help debug this? It's really pretty unpleasant.
*poke*
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.
Created attachment 1156256 [details] proposed patch
Fixed upstream: https://www.sudo.ws/repos/sudo/rev/1246583c7c1f
Created attachment 1156490 [details] upstream patch
So thank you so much for working on this! But. It appears to work by ignoring all arguments: rlpowell@vrici> ls /tmp/ | wc -l ls: cannot access '/tmp/lojbo-corpus-update.lock': Permission denied ls: cannot access '/tmp/corpus.txt': Permission denied ls: cannot access '/tmp/corpus.txt.bz2': Permission denied 194 rlpowell@vrici> sudo ls /tmp/ | wc -l [sudo] password for rlpowell: 57 rlpowell@vrici> sudo ls /tmp/ bin dev home-OLD lost+found opt run s0:c161,c882 s0:c21,c728 s0:c266,c348 s0:c341,c403 s0:c376,c712 s0:c447,c825 s0:c477,c934 s0:c54,c240 s0:c623,c775 s0:c782,c872 s0:c878,c908 selinux tmp boot etc lib media proc s0:c1011,c1020 s0:c180,c298 s0:c248,c789 s0:c3,c919 s0:c346,c659 s0:c437,c438 s0:c450,c468 s0:c484,c934 s0:c540,c823 s0:c73,c420 s0:c792,c849 s0:c910,c947 srv usr core.24989 home lib64 mnt root s0:c142,c457 s0:c190,c688 s0:c251,c570 s0:c316,c943 s0:c374,c980 s0:c439,c944 s0:c460,c645 s0:c494,c620 s0:c552,c701 s0:c732,c950 s0:c87,c91 sbin sys var That's clearly not /tmp/. Also, what are those dev files? Let me get rid of them while I'm in there... rlpowell@vrici> sudo rm s0:c1011,c1020 s0:c142,c457 s0:c161,c882 s0:c180,c298 s0:c190,c688 s0:c21,c728 s0:c248,c789 s0:c251,c570 s0:c266,c348 s0:c3,c919 s0:c316,c943 s0:c341, c403 s0:c346,c659 s0:c374,c980 s0:c376,c712 s0:c437,c438 s0:c439,c944 s0:c447,c825 s0:c450,c468 s0:c460,c645 s0:c477,c934 s0:c484,c934 s0:c494,c620 s0:c54,c240 s0:c540,c823 s 0:c552,c701 s0:c623,c775 s0:c73,c420 s0:c732,c950 s0:c782,c872 s0:c792,c849 s0:c87,c91 s0:c878,c908 s0:c910,c947 /bin/rm: missing operand Try '/bin/rm --help' for more information. Yeaaah. That's not so good.
That's all with: Installed Packages sudo.x86_64 1.8.16-2.fc24 @@commandline
Noticed the bad version, upgraded to sudo-1.8.16-2.fc25.x86_64, same behaviour: rlpowell@vrici> sudo ls /tmp/ [sudo] password for rlpowell: Dropbox dead.letter index.html.2 index.html.5 joshua output_with_switch.csv.csv ps scratch utils bin echo index.html.3 index.html.6 llg_backups output_without_switch.csv.csv public_html selinux www config foo.pdf index.html.4 infocmp lojban programming rpmbuild src rlpowell@vrici> cd / rlpowell@vrici> sudo ls /tmp/ bin boot dev etc home home-OLD lib lib64 lost+found media mnt opt proc root run sbin selinux srv sys tmp usr var rlpowell@vrici>
(In reply to Robin Powell from comment #15) > So thank you so much for working on this! > > But. > > It appears to work by ignoring all arguments: > > rlpowell@vrici> ls /tmp/ | wc -l > ls: cannot access '/tmp/lojbo-corpus-update.lock': Permission denied > ls: cannot access '/tmp/corpus.txt': Permission denied > ls: cannot access '/tmp/corpus.txt.bz2': Permission denied > 194 > rlpowell@vrici> sudo ls /tmp/ | wc -l > [sudo] password for rlpowell: > 57 > rlpowell@vrici> sudo ls /tmp/ > bin dev home-OLD lost+found opt run s0:c161,c882 > s0:c21,c728 s0:c266,c348 s0:c341,c403 s0:c376,c712 s0:c447,c825 > s0:c477,c934 s0:c54,c240 > s0:c623,c775 s0:c782,c872 s0:c878,c908 selinux tmp > boot etc lib media proc s0:c1011,c1020 s0:c180,c298 > s0:c248,c789 s0:c3,c919 s0:c346,c659 s0:c437,c438 s0:c450,c468 > s0:c484,c934 s0:c540,c823 > s0:c73,c420 s0:c792,c849 s0:c910,c947 srv usr > core.24989 home lib64 mnt root s0:c142,c457 s0:c190,c688 > s0:c251,c570 s0:c316,c943 s0:c374,c980 s0:c439,c944 s0:c460,c645 > s0:c494,c620 s0:c552,c701 > s0:c732,c950 s0:c87,c91 sbin sys var > > That's clearly not /tmp/. Also, what are those dev files? Let me get rid > of them while I'm in there... > > rlpowell@vrici> sudo rm s0:c1011,c1020 s0:c142,c457 s0:c161,c882 > s0:c180,c298 s0:c190,c688 s0:c21,c728 s0:c248,c789 s0:c251,c570 s0:c266,c348 > s0:c3,c919 s0:c316,c943 s0:c341, > c403 s0:c346,c659 s0:c374,c980 s0:c376,c712 s0:c437,c438 s0:c439,c944 > s0:c447,c825 s0:c450,c468 s0:c460,c645 s0:c477,c934 s0:c484,c934 > s0:c494,c620 s0:c54,c240 s0:c540,c823 s > 0:c552,c701 s0:c623,c775 s0:c73,c420 s0:c732,c950 s0:c782,c872 s0:c792,c849 > s0:c87,c91 s0:c878,c908 s0:c910,c947 > /bin/rm: missing operand > Try '/bin/rm --help' for more information. > > Yeaaah. That's not so good. Ok, sorry for that. I think I see the problem. The upstream patch doesn't for some reason fix the second argument in the memcpy as does my proposed patch: upstream: + memcpy(&nargv[nargc], &argv[argc], argc * sizeof(char *)); /* copies NULL */ proposed: + memcpy(&nargv[nargc + 1], &argv[1], argc * sizeof(char *)); /* copies NULL */ I'll do a new build with the first proposed patch.
Created attachment 1157053 [details] proposed patch
Fixed upstream: https://www.sudo.ws/repos/sudo/rev/f52403ef587a