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.

https://lore.kernel.org/selinux/fd32479f-cce0-b39a-f708-b7e1a1b27fd7@tycho.nsa.gov/T/#t

(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