Bug 1335401

+++ 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 ---