On 9/27/19 9:49 AM, Dominick Grift wrote:
On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
On 9/27/19 9:08 AM, Dominick Grift wrote:
On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
On 9/27/19 3:55 AM, Dominick Grift wrote:
sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
[1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
[2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
Are you sure sudo is calling selinux_restore_tty()?
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
Ok, so you entered and exited selinux_restore_tty() without error. No
warning messages of any kind in any of the sudo logs? Not sure where
sudo_warn() and sudo_warnx() messages go.
No warnings or any other clues. I guess it must be this then:
if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
goto skip_relabel;
That should only occur if there was no tty or security_compute_relabel()
didn't provide a new context to set in the first place. Not if it
actually relabeled the tty earlier.
Does newrole work correctly with your policy?
selinux_restore_tty() does a goto skip_relabel in multiple cases:
- if there was no tty (ttyfd == -1),
- if we didn't set a new tty context (new_tty_context),
- if the context on the tty was changed from the value set by sudo
(strcmp...) e.g. some other process changed it in the interim, but this
should have logged a warning,
