Bug 1328735

Summary: Weird sudo issue that seems to be selinux related
Product: [Fedora] Fedora Reporter: Robin Powell <rlpowell>
Component: sudoAssignee: Daniel Kopeček <dkopecek>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dkopecek, dominick.grift, dwalsh, kzak, lvrabec, mgrepl, plautrba, rsroka
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: sudo-1.8.16-3.fc25 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1335401 (view as bug list) Environment:
Last Closed: 2016-06-24 14:37:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1335401    
Attachments:
Description Flags
proposed patch
none
upstream patch
none
proposed patch none

Description Robin Powell 2016-04-20 08:02:52 UTC
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)

Comment 1 Robin Powell 2016-04-20 08:08:05 UTC
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.

Comment 2 Robin Powell 2016-04-20 08:17:34 UTC
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.

Comment 3 Daniel Walsh 2016-04-20 13:15:47 UTC
Any AVC's?

Any AVC's if you disable dontaudit rules?

Comment 4 Robin Powell 2016-04-20 17:50:15 UTC
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'

Comment 5 Robin Powell 2016-04-22 07:10:07 UTC
Is there any further debugging I can provide of any kind?  Having a basically unusable sudo is ... distressing.

Comment 6 Daniel Kopeček 2016-04-22 12:11:13 UTC
(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.

Comment 7 Robin Powell 2016-04-22 17:55:46 UTC
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

Comment 8 Daniel Walsh 2016-04-29 19:15:01 UTC
I am seeing the same issue on my Rawhide system. Was working fine on fedora 24.

Comment 9 Robin Powell 2016-05-06 00:48:43 UTC
Anything I can do to help debug this?  It's really pretty unpleasant.

Comment 10 Robin Powell 2016-05-11 15:40:11 UTC
*poke*

Comment 11 Daniel Kopeček 2016-05-11 19:08:25 UTC
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.

Comment 12 Daniel Kopeček 2016-05-11 19:09:06 UTC
Created attachment 1156256 [details]
proposed patch

Comment 13 Daniel Kopeček 2016-05-11 21:22:53 UTC
Fixed upstream:
https://www.sudo.ws/repos/sudo/rev/1246583c7c1f

Comment 14 Daniel Kopeček 2016-05-12 07:36:53 UTC
Created attachment 1156490 [details]
upstream patch

Comment 15 Robin Powell 2016-05-12 22:00:39 UTC
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.

Comment 16 Robin Powell 2016-05-12 22:01:42 UTC
That's all with:

Installed Packages
sudo.x86_64                                                                    1.8.16-2.fc24                                                                     @@commandline

Comment 17 Robin Powell 2016-05-12 22:07:24 UTC
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>

Comment 18 Daniel Kopeček 2016-05-13 07:59:07 UTC
(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.

Comment 19 Daniel Kopeček 2016-05-13 09:19:51 UTC
Created attachment 1157053 [details]
proposed patch

Comment 20 Daniel Kopeček 2016-05-13 12:47:35 UTC
Fixed upstream:
https://www.sudo.ws/repos/sudo/rev/f52403ef587a