Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1335401 - Weird sudo issue that seems to be selinux related
Summary: Weird sudo issue that seems to be selinux related
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: 24
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Daniel Kopeček
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1328735
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-12 07:48 UTC by Daniel Kopeček
Modified: 2016-05-16 16:18 UTC (History)
10 users (show)

Fixed In Version: sudo-1.8.16-3.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of: 1328735
Environment:
Last Closed: 2016-05-16 16:18:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
upstream patch (1.60 KB, patch)
2016-05-12 07:49 UTC, Daniel Kopeček
no flags Details | Diff
proposed patch (1.60 KB, patch)
2016-05-13 09:31 UTC, Daniel Kopeček
no flags Details | Diff

Description Daniel Kopeček 2016-05-12 07:48:48 UTC
+++ 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 ---

Comment 1 Daniel Kopeček 2016-05-12 07:49:27 UTC
Created attachment 1156492 [details]
upstream patch

Comment 2 Fedora Update System 2016-05-12 08:10:54 UTC
sudo-1.8.16-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a04f1b9b97

Comment 3 Fedora Update System 2016-05-12 22:27:11 UTC
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

Comment 4 Daniel Kopeček 2016-05-13 09:31:52 UTC
Created attachment 1157055 [details]
proposed patch

Comment 5 Fedora Update System 2016-05-13 11:34:31 UTC
sudo-1.8.16-3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5680e43366

Comment 6 Fedora Update System 2016-05-15 06:57:00 UTC
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

Comment 7 Fedora Update System 2016-05-16 16:18:39 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.