-
Bug
-
Resolution: Done
-
Undefined
-
rhel-8.9.0, rhel-9.4
-
None
-
Yes
-
Moderate
-
rhel-security-special-projects
-
ssg_security
-
None
-
False
-
False
-
-
No
-
Red Hat Enterprise Linux
-
None
-
None
-
None
-
Release Note Not Required
-
-
All
-
None
This is a follow-up of RHEL-36427.
What were you trying to do that didn't work?
After sudo'ing (through adding a rule in the policy to workaround above JIRA), confined commands such as ifconfig -a provide no output:
[sysadm@vm-rhel9 ~]$ sudo -i [root@vm-rhel9 ~]# tty /dev/pts/2 [root@vm-rhel9 ~]# ls -Z $(tty) sysadm_u:object_r:devpts_t:s0 /dev/pts/2 [root@vm-rhel9 ~]# ifconfig -a --> no output [root@vm-rhel9 ~]#
The root cause for this is the TTY /dev/pts/2 isn't labeled with user_devpts_t, but with devpts_t.
This occurs because no relabeling of the TTY happens.
Checking the source code, we can see that get_pty() function is not SELinux aware, causing the TTY to get the default (unexpected) label:
138 static bool 139 pty_setup(struct command_details *details, const char *tty) 140 { : 150 if (!get_pty(&io_fds[SFD_LEADER], &io_fds[SFD_FOLLOWER], 151 ptyname, sizeof(ptyname), details->cred.euid)) 152 sudo_fatal("%s", U_("unable to allocate pty")); : 53 #if defined(HAVE_OPENPTY) 54 bool 55 get_pty(int *leader, int *follower, char *name, size_t namesz, uid_t ttyuid) 56 { : 65 if (openpty(leader, follower, name, NULL, NULL) == 0) { 66 if (chown(name, ttyuid, ttygid) == 0) 67 ret = true; 68 } 69 70 debug_return_bool(ret); 71 }
From above, we can see no SELinux aware code executes to relabel the tty.
Such relabeling function exists in the code base already, but is limited to SELinux execs:
158 /* 159 * This function attempts to relabel the tty. If this function fails, then 160 * the contexts are free'd and -1 is returned. On success, 0 is returned 161 * and tty_con_raw and new_tty_con_raw are set. 162 * 163 * This function will not fail if it can not relabel the tty when selinux is 164 * in permissive mode. 165 */ 166 static int 167 relabel_tty(const char *ttyn, int ptyfd) 168 { : 387 int 388 selinux_setup(const char *role, const char *type, const char *ttyn, 389 int ptyfd, bool label_tty) 390 { : 418 if (label_tty && relabel_tty(ttyn, ptyfd) == -1) { 419 sudo_warn(U_("unable to set tty context to %s"), se_state.new_context); 420 goto done; 421 } :
Please provide the package NVR for which bug is seen:
sudo-1.9.5p2-1.el8_9.x86_64
sudo-1.9.5p2-10.el9_3.x86_64
How reproducible:
Always
Steps to reproduce
- Create a user mapped to sysadm_u
# useradd -G wheel -Z sysadm_u sysadm
- Configure sudo to log input and/or output
Defaults log_input,log_output Defaults logfile=/var/log/sudo.log
- Setup workaround for RHEL-36427
# echo "(allow sysadm_sudo_t var_t (dir (read)))" > sudo_sysadm.cil # semodule -i sudo_sysadm.cil
- Login as the confined user and sudo interactively
$ sudo -i # ls -Z $(tty) sysadm_u:object_r:devpts_t:s0 /dev/pts/2 # ifconfig -a
Expected results
TTY labeled with sysadm_u:object_r:user_devpts_t:s0
+ output for ifconfig command
Actual results
No output but some AVC (when "dontaudit" is turned off):
type=AVC msg=audit(05/15/2024 10:05:20.194:166) : avc: denied { read write } for pid=1829 comm=ifconfig path=/dev/pts/2 dev="devpts" ino=5 scontext=sysadm_u:sysadm_r:ifconfig_t:s0-s0:c0.c1023 tcontext=sysadm_u:object_r:devpts_t:s0 tclass=chr_file permissive=0
- is related to
-
RHEL-36427 sudo cannot write to its logfile hence fails when enabling log_input or log_output
-
- Closed
-