|
Bugzilla – Full Text Bug Listing |
| Summary: | selinux.c: selinux_restore_tty() seems to not work | ||
|---|---|---|---|
| Product: | Sudo | Reporter: | dac.override |
| Component: | Sudo | Assignee: | Todd C. Miller <Todd.Miller> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | low | ||
| Version: | 1.8.27 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: | sudo_debug.log | ||
|
Description
dac.override
2019-09-26 10:48:44 MDT
What Linux distro are you running? If RHEL or one of its derivatives, please confirm that you don't have the "cmnd_no_wait" option set in sudoers. It would also be helpful to know whether "use_pty", "log_input" or "log_output" are set in sudoers. I am seeing this on at least both Fedora (Rawhide) and Debian (Sid). None of the directives you mentioned are set in either. I can't read the c-code in selinux.c, so this is speculation but i do know a little bit about SELinux configuration: It is not a common scenario to associate roles with objects. Usually RBAC is only used for processes and objects automatically get associated a "object_r" role placeholder identifier. It *may* be that whatever determines "old_context" does not take into account the role (and possibly any other "customizable" identifiers) Roles associated with objects are important in my SELinux configuration as i impose separation based on this. Privileged roles and access to objects associated with privileged roles are exempt. In other words pty's becomes writable to unprivileged users with access to the tty group as soon as sudo is run to gain root using that pty running sudo with: Debug sudo /var/log/sudo_debug all@debug Debug sudoers.so /var/log/sudo_debug all@debug Yields: grep selinux /var/log/sudo_debug Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @ ../../../lib/util/key_val.c:61 := selinux_role=sysadm.role Sep 27 15:06:29 sudo[3417] 7: selinux_role=sysadm.role Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349 Sep 27 15:06:29 sudo[3447] -> get_exec_context @ ../../src/selinux.c:274 Sep 27 15:06:29 sudo[3447] <- get_exec_context @ ../../src/selinux.c:328 := 0x564eed3621b0 Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160 Sep 27 15:06:29 sudo[3447] <- relabel_tty @ ../../src/selinux.c:253 := 0 Sep 27 15:06:29 sudo[3447] -> audit_role_change @ ../../src/selinux.c:76 Sep 27 15:06:29 sudo[3447] <- audit_role_change @ ../../src/selinux.c:98 := 6 Sep 27 15:06:29 sudo[3447] <- selinux_setup @ ../../src/selinux.c:395 := 0 Sep 27 15:06:29 sudo[3447] -> selinux_execve @ ../../src/selinux.c:405 Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @ ../../src/selinux.c:114 Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @ ../../src/selinux.c:142 := 0 Thanks for the debug info, that tells me that fsetfilecon() is getting called with the old context and succeeds. I'm not sure what is going wrong. Can you verify that the file context on the tty gets restored properly when you use newrole instead of sudo? The code to set and restore the tty context is basically the same in sudo and newrole so I would expect the same behavior. (In reply to Todd C. Miller from comment #4) > Thanks for the debug info, that tells me that fsetfilecon() is > getting called with the old context and succeeds. I'm not sure what > is going wrong. > > Can you verify that the file context on the tty gets restored > properly when you use newrole instead of sudo? The code to set and > restore the tty context is basically the same in sudo and newrole so > I would expect the same behavior. Works with `newrole` Some more feedback from the selinux mail list: "I could be wrong since I am not especially familiar with sudo's internal structure, but I'm wondering if the call to selinux_setup() is occurring in a different process than the call to selinux_restore_tty(). If so, then the use of global state by those functions like the se_state would be broken. Ask the sudo maintainers. This probably wouldn't show up under Fedora's default policies since I don't think they bother with different types on ttys for the different user roles, so no relabeling is needed." Followup: "Actually, looking back at your debug logs, that is evident from the different PIDs reported for the calls to selinux_setup() vs selinux_restore_tty(). Originally these were probably both called from the parent process, then someone must have re-factored and moved the selinux_setup() to the child?" Steve has sharper eyes than I do, I totally missed that 3417 != 3447 in the debug logs. The problem is that the SELinux setup is done in the child prior to exec so there is no state to restore later. I'll get back to you with a patch to try later today. I believe this is fixed by the following two commits: https://www.sudo.ws/repos/sudo/rev/ed66480282c7 https://www.sudo.ws/repos/sudo/rev/eb3f547b08f8 There is a typo in the first one that causes labeling to fail which is corrected in the second. These changes are also present in ftp://ftp.sudo.ws/pub/millert/sudo-1.8.28rc2.tar.gz Can you build that (or do a source checkout from sudo.ws or github) and verify that it fixes the bug? If so, the fix will be included in sudo 1.8.28 which is due to be released soon. I added the two commits on top of 28-rc1, it seems to work: [kcinimod@agnus ~]$ id -Z wheel.id:wheel.role:wheel.subj:s0 [kcinimod@agnus ~]$ ls -alZ `tty` crw--w----. 1 kcinimod tty wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 0 Sep 28 2019 /dev/pts/0 [kcinimod@agnus ~]$ sudo ls -alZ `tty` crw--w----. 1 kcinimod tty wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 0 Sep 28 11:06 /dev/pts/0 [kcinimod@agnus ~]$ ls -alZ `tty` crw--w----. 1 kcinimod tty wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 0 Sep 28 11:06 /dev/pts/0 [kcinimod@agnus ~]$ grep selinux /var/log/sudo_debug grep: /var/log/sudo_debug: Permission denied [kcinimod@agnus ~]$ sudo grep selinux /var/log/sudo_debug Sep 28 11:06:16 sudo[81160] <- sudo_new_key_val_v1 @ ./key_val.c:63 := selinux_role=sysadm.role Sep 28 11:06:16 sudo[81160] 7: selinux_role=sysadm.role Sep 28 11:06:16 sudo[81160] -> selinux_setup @ ./selinux.c:369 Sep 28 11:06:16 sudo[81160] selinux_setup: old context wheel.id:wheel.role:wheel.subj:s0 Sep 28 11:06:16 sudo[81160] -> get_exec_context @ ./selinux.c:294 Sep 28 11:06:16 sudo[81160] <- get_exec_context @ ./selinux.c:347 := wheel.id:sysadm.role:sysadm.subj:s0 Sep 28 11:06:16 sudo[81160] selinux_setup: new context wheel.id:sysadm.role:sysadm.subj:s0 Sep 28 11:06:16 sudo[81160] -> relabel_tty @ ./selinux.c:174 Sep 28 11:06:16 sudo[81160] <- relabel_tty @ ./selinux.c:273 := 0 Sep 28 11:06:16 sudo[81160] -> audit_role_change @ ./selinux.c:78 Sep 28 11:06:16 sudo[81160] <- audit_role_change @ ./selinux.c:100 := 5 Sep 28 11:06:16 sudo[81160] <- selinux_setup @ ./selinux.c:408 := 0 Sep 28 11:06:16 sudo[81163] -> selinux_execve @ ./selinux.c:418 Sep 28 11:06:16 sudo[81160] -> selinux_restore_tty @ ./selinux.c:116 Sep 28 11:06:16 sudo[81160] selinux_restore_tty: wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 -> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 Sep 28 11:06:16 sudo[81160] selinux_restore_tty: successfully set tty label to wheel.id:wheel.role:users.terminals.pty.pty_file:s0 Sep 28 11:06:16 sudo[81160] <- selinux_restore_tty @ ./selinux.c:156 := 0 Sep 28 11:06:37 sudo[81208] sudo_putenv: SUDO_COMMAND=/usr/bin/grep selinux /var/log/sudo_debug Sep 28 11:06:37 sudo[81208] <- new_logline @ ./logging.c:1084 := TTY=pts/0 ; PWD=/home/kcinimod ; USER=root ; COMMAND=/usr/bin/grep selinux /var/log/sudo_debug Sep 28 11:06:37 sudo[81208] <- sudo_new_key_val_v1 @ ./key_val.c:63 := selinux_role=sysadm.role Sep 28 11:06:37 sudo[81208] 7: selinux_role=sysadm.role Sep 28 11:06:37 sudo[81208] -> selinux_setup @ ./selinux.c:369 Sep 28 11:06:37 sudo[81208] selinux_setup: old context wheel.id:wheel.role:wheel.subj:s0 Sep 28 11:06:37 sudo[81208] -> get_exec_context @ ./selinux.c:294 Sep 28 11:06:37 sudo[81208] <- get_exec_context @ ./selinux.c:347 := wheel.id:sysadm.role:sysadm.subj:s0 Sep 28 11:06:37 sudo[81208] selinux_setup: new context wheel.id:sysadm.role:sysadm.subj:s0 Sep 28 11:06:37 sudo[81208] -> relabel_tty @ ./selinux.c:174 Sep 28 11:06:37 sudo[81208] <- relabel_tty @ ./selinux.c:273 := 0 Sep 28 11:06:37 sudo[81208] -> audit_role_change @ ./selinux.c:78 Sep 28 11:06:37 sudo[81208] <- audit_role_change @ ./selinux.c:100 := 5 Sep 28 11:06:37 sudo[81208] <- selinux_setup @ ./selinux.c:408 := 0 Sep 28 11:06:37 sudo[81211] -> selinux_execve @ ./selinux.c:418 Sep 28 11:06:37 sudo[81211] exec /usr/libexec/sudo/sesh [sesh /usr/bin/grep selinux /var/log/sudo_debug] [HISTSIZE=1000 HOSTNAME=agnus SSH_AUTH_SOCK=/run/user/9999/gnupg/S.gpg-agent.ssh LANG=en_US.UTF-8 LS_COLORS=di=38;5;33:ln=38;5;14:pi=38;5;11;40:so=38;5;13:bd=38;5;11;48;5;232:cd=33;48;5;232:or=38;5;196;48;5;232:mi=1;5;37;41:su=38;5;231;48;5;196:sg=38;5;16;48;5;226:ca=38;5;226;48;5;196:tw=38;5;16;48;5;40:ow=38;5;21;48;5;40:st=38;5;231;48;5;21:ex=38;5;40:*.nuv=38;5;13:*.m4v=38;5;13:*.ogv=38;5;13:*.rpm=38;5;9:*.tz=38;5;9:*.pbm=38;5;13:*.rm=38;5;13:*.svg=38;5;13:*.tiff=38;5;13:*.xpm=38;5;13:*.m4a=38;5;45:*.cab=38;5;9:*.ogm=38;5;13:*.arj=38;5;9:*.mpg=38;5;13:*.ppm=38;5;13:*.zip=38;5;9:*.rz=38;5;9:*.ogx=38;5;13:*.fli=38;5;13:*.rar=38;5;9:*.pgm=38;5;13:*.deb=38;5;9:*.dwm=38;5;9:*.bz2=38;5;9:*.mid=38;5;45:*.alz=38;5;9:*.xspf=38;5;45:*.tgz=38;5;9:*.t7z=38;5;9:*.taz=38;5;9:*.zst=38;5;9:*.lz=38;5;9:*.avi=38;5;13:*.webm=38;5;13:*.au=38;5;45:*.bz=38;5;9:*.flac=38;5;45:*.lz4=38;5;9:*.tzo=38;5;9:*.ogg=38;5;45:*.yuv=38;5;13:*.lzo=38;5;9:*.xbm=38;5;13:*.mng=38;5;13:*.xcf=38;5;13:*.z=38;5;9:*.mjpeg=38;5;13:*.ace=38;5;9:*.midi=38;5;45:*.lha=38;5;9:*.war=38;5;9:*.mpeg=38;5;13:*.Z=38;5;9:*.dz=38;5;9:*.aac=38;5;45:*.mp4v=38;5;13:*.tif=38;5;13:*.wim=38;5;9:*.lzma=38;5;9:*.opus=38;5;45:*.oga=38;5;45:*.wav=38;5;45:*.tzst=38;5;9:*.arc=38;5;9:*.tlz=38;5;9:*.zoo=38;5;9:*.esd=38;5;9:*.rmvb=38;5;13:*.tar=38;5;9:*.mp4=38;5;13:*.mka=38;5;45:*.tga=38;5;13:*.spx=38;5;45:*.jar=38;5;9:*.7z=38;5;9:*.flc=38;5;13:*.sar=38;5;9:*.png=38;5;13:*.dl=38;5;13:*.gz=38;5;9:*.cpio=38;5;9:*.mjpg=38;5;13:*.gif=38;5;13:*.emf=38;5;13:*.asf=38;5;13:*.qt=38;5;13:*.xwd=38;5;13:*.mpc=38;5;45:*.lzh=38;5;9:*.ear=38;5;9:*.m2v=38;5;13:*.vob=38;5;13:*.flv=38;5;13:*.ra=38;5;45:*.mkv=38;5;13:*.svgz=38;5;13:*.mov=38;5;13:*.swm=38;5;9:*.txz=38;5;9:*.pcx=38;5;13:*.gl=38;5;13:*.lrz=38;5;9:*.wmv=38;5;13:*.bmp=38;5;13:*.cgm=38;5;13:*.tbz2=38;5;9:*.xz=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.mp3=38;5;45:*.tbz=38;5;9: TERM=xterm-256color PS1=[\u@\h \W$(__git_ps1 " (%s)")]\$ MAIL=/var/spool/mail/kcinimod PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LOGNAME=root USER=root HOME=/root SHELL=/bin/bash SUDO_COMMAND=/usr/bin/grep selinux /var/log/sudo_debug SUDO_USER=kcinimod SUDO_UID=9999 SUDO_GID=9999] Fixed in sudo 1.8.28 Thanks. Do you by chance have any idea why sudo 1.2.28p1 might work fine on Fedora but not on Debian? Looking at Debians they don't carry any significant patches. Although their config and PAM config seems to differ a bit. Here is what is being logged: kcinimod@seamus:~$ sudo -s sudo: unable to execute /bin/bash: No such file or directory <snip> Oct 24 16:21:23 sudo[11514] <- sudo_ev_free_v1 @ ../../../lib/util/event.c:321 Oct 24 16:21:23 sudo[11514] <- free_exec_closure_nopty @ ../../src/exec_nopty.c:341 Oct 24 16:21:23 sudo[11514] <- exec_nopty @ ../../src/exec_nopty.c:454 Oct 24 16:21:23 sudo[11514] <- sudo_execute @ ../../src/exec.c:440 := -1 Oct 24 16:21:23 sudo[11514] calling policy close with errno 2 Oct 24 16:21:23 sudo[11514] -> policy_close @ ../../src/sudo.c:1126 Oct 24 16:21:23 sudo[11514] -> sudoers_policy_close @ ../../../plugins/sudoers/policy.c:799 Oct 24 16:21:23 sudo[11514] unable to execute /bin/bash: No such file or directory @ sudoers_policy_close() ../../../plugins/sudoers/policy.c:804 Oct 24 16:21:23 sudo[11514] -> sudo_auth_end_session @ ../../../plugins/sudoers/auth/sudo_auth.c:416 Oct 24 16:21:23 sudo[11514] -> sudo_pam_end_session @ ../../../plugins/sudoers/auth/pam.c:525 Oct 24 16:21:23 sudo[11514] <- sudo_pam_end_session @ ../../../plugins/sudoers/auth/pam.c:565 := 0 Oct 24 16:21:23 sudo[11514] <- sudo_auth_end_session @ ../../../plugins/sudoers/auth/sudo_auth.c:427 := 1 Oct 24 16:21:23 sudo[11514] -> sudo_pw_delref @ ../../../plugins/sudoers/pwutil.c:181 Oct 24 16:21:23 sudo[11514] -> sudo_pw_delref_item @ ../../../plugins/sudoers/pwutil.c:170 Oct 24 16:21:23 sudo[11514] <- sudo_pw_delref_item @ ../../../plugins/sudoers/pwutil.c:175 Oct 24 16:21:23 sudo[11514] <- sudo_pw_delref @ ../../../plugins/sudoers/pwutil.c:183 Oct 24 16:21:23 sudo[11514] -> sudo_pw_delref @ ../../../plugins/sudoers/pwutil.c:181 Oct 24 16:21:23 sudo[11514] -> sudo_pw_delref_item @ ../../../plugins/sudoers/pwutil.c:170 Oct 24 16:21:23 sudo[11514] <- sudo_pw_delref_item @ ../../../plugins/sudoers/pwutil.c:175 Oct 24 16:21:23 sudo[11514] <- sudo_pw_delref @ ../../../plugins/sudoers/pwutil.c:183 Oct 24 16:21:23 sudo[11514] -> sudo_gidlist_delref @ ../../../plugins/sudoers/pwutil.c:749 Oct 24 16:21:23 sudo[11514] -> sudo_gidlist_delref_item @ ../../../plugins/sudoers/pwutil.c:738 Oct 24 16:21:23 sudo[11514] <- sudo_gidlist_delref_item @ ../../../plugins/sudoers/pwutil.c:743 Oct 24 16:21:23 sudo[11514] <- sudo_gidlist_delref @ ../../../plugins/sudoers/pwutil.c:751 Oct 24 16:21:23 sudo[11514] -> sudoers_debug_deregister @ ../../../plugins/sudoers/sudoers_debug.c:158 Oct 24 16:21:23 sudo[11514] <- sudoers_debug_deregister @ ../../../plugins/sudoers/sudoers_debug.c:160 Oct 24 16:21:23 sudo[11514] <- policy_close @ ../../src/sudo.c:1135 Oct 24 16:21:23 sudo[11514] <- run_command @ ../../src/sudo.c:1018 := 256 Oct 24 16:21:23 sudo[11514] <- main @ ../../src/sudo.c:327 := 1 (END) The relevant bits of the debug output are probably earlier, particularly in exec_cmnd(). You should also verify that /usr/lib/sudo/sesh is properly labeled. On Fedora this would be /usr/libexec/sudo/sesh but Debian doesn't seem to believe in /usr/libexec... Created attachment 531 [details]
sudo_debug.log
full sudo_debug.log attached
Yes debian installs it here:
ls -alZ /usr/lib/sudo/sesh
-rwxr-xr-x. 1 root root sys.id:sys.role:cmd.shell.cmd_file:s0 22520 Oct 23 00:13 /usr/lib/sudo/sesh
Been doing so though. Nothing seems to have changed in that regard.
hmm this i suppose (/usr/lib/sudo/sudo)? Did that change? I dont think debian changed anything in thatr regard? can "plugin_path" be overridden at runtime?
exec /usr/lib/sudo/sudo/sesh [sesh /bin/bash] [SHELL=/bin/bash LANGUAGE=en_US:en SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh LANG=en_US.UTF-8 LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36: TERM=xterm-256color PS1=\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin MAIL=/var/mail/root LOGNAME=root USER=root HOME=/root SUDO_COMMAND=/bin/bash SUDO_USER=kcinimod SUDO_UID=1000 SUDO_GID=1000]
Oct 24 16:39:38 sudo[17328] <- sudo_execve @ ../../src/exec_common.c:220 := -1
Oct 24 16:39:38 sudo[17328] <- selinux_execve @ ../../src/selinux.c:470
Right (i think) https://salsa.debian.org/debian/sudo/blob/master/debian/rules#L48 so its looking for sesh in /usr/lib/sudo/sudo There was a change in sudo 1.8.7 to make libexecdir handling more standard. There is a heuristic when loading the plugin to check the parent if libexecdir ends in /sudo which is why no one in Debian noticed. My own Debian packages are configured using --libexecdir=/usr/lib Would you mind filing a bug with Debian about this? I just have: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943413 thanks |