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 1328735 - Weird sudo issue that seems to be selinux related
Summary: Weird sudo issue that seems to be selinux related
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daniel Kopeček
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1335401
TreeView+ depends on / blocked
 
Reported: 2016-04-20 08:02 UTC by Robin Powell
Modified: 2016-06-24 14:37 UTC (History)
8 users (show)

Fixed In Version: sudo-1.8.16-3.fc25
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1335401 (view as bug list)
Environment:
Last Closed: 2016-06-24 14:37:04 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
proposed patch (1.52 KB, patch)
2016-05-11 19:09 UTC, Daniel Kopeček 		no flags Details | Diff
upstream patch (1.60 KB, patch)
2016-05-12 07:36 UTC, Daniel Kopeček 		no flags Details | Diff
proposed patch (1.60 KB, patch)
2016-05-13 09:19 UTC, Daniel Kopeček 		no flags Details | Diff
Show Obsolete (2) View All

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
Note You need to log in before you can comment on or make changes to this bug.