Description of problem:

There are multiple issues happening when a confined user to "staff_u" tries to edit the cron of another user through some sudo rule.

1. "sudo -u USER crontab -l" fails

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023

$ sudo -u <USER> crontab -l
'/var/spool/cron' is not a directory, bailing out.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This happens because /var/spool/cron is not readable by staff_sudo_t, the context used when executing "crontab -l" because of the absence of transition to "crontab_t" due to using "sudo crontab" command.
Strace shows:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
4434 [staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023] 10:30:21.103895 execve("/bin/crontab" [system_u:object_r:crontab_exec_t:s0], ["crontab", "-l"] ...
[...]
4434 [staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023] 10:30:21.134230 stat("/var/spool/cron" [system_u:object_r:user_cron_spool_t:s0], 0x7ffc16aac270) = -1 EACCES (Permission denied)
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This is a bug, IMHO there should be the transition to crontab_t when executing the command, it should not execute as "staff_sudo_t" at all.

2. "sudo -u USER -i crontab -l" fails silently and produces AVCs

This happens when `Defaults use_pty` is used in the sudo configuration.

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023

$ sudo -u <USER> -i crontab -l
$
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

AVC:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
type=PROCTITLE msg=audit(07/17/2023 10:38:01.277:528) : proctitle=crontab -l
type=EXECVE msg=audit(07/17/2023 10:38:01.277:528) : argc=2 a0=crontab a1=-l
type=SYSCALL msg=audit(07/17/2023 10:38:01.277:528) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x561829ebdd40 a1=0x561829ea0cd0 a2=0x561829ebf400 a3=0x8 items=0 ppid=4553 pid=4554 auid=staff uid=USER gid=USER euid=root suid=root fsuid=root egid=USER sgid=USER fsgid=USER tty=(none) ses=13 comm=crontab exe=/usr/bin/crontab subj=staff_u:staff_r:crontab_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(07/17/2023 10:38:01.277:528) : avc: denied

{ read write } for pid=4554 comm=crontab path=/dev/pts/3 dev="devpts" ino=6 scontext=staff_u:staff_r:crontab_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:devpts_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(07/17/2023 10:38:01.277:528) : avc: denied { read write }

for pid=4554 comm=crontab path=/dev/pts/3 dev="devpts" ino=6 scontext=staff_u:staff_r:crontab_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:devpts_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(07/17/2023 10:38:01.277:528) : avc: denied

{ read write } for pid=4554 comm=crontab path=/dev/pts/3 dev="devpts" ino=6 scontext=staff_u:staff_r:crontab_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:devpts_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(07/17/2023 10:38:01.277:528) : avc: denied { read write }

for pid=4554 comm=crontab path=/dev/pts/3 dev="devpts" ino=6 scontext=staff_u:staff_r:crontab_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:devpts_t:s0 tclass=chr_file permissive=0
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Due to using "sudo -i", the transition to "crontab_t" happens when executing the command.
Unfortunately "crontab_t" cannot read/write on the pseudo tty allocated by sudo.

3. "sudo -u <USER> -i" then "crontab -e" fails silently after some timeout and produces AVCs

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023

$ sudo -u USER -i
$ crontab -e
<long delay then exits silently>
$
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

AVC:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
type=PROCTITLE msg=audit(07/17/2023 10:42:32.287:551) : proctitle=vim /tmp/crontab.wTBQAP
type=SYSCALL msg=audit(07/17/2023 10:42:32.287:551) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x55a601568060 a2=O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW a3=0x180 items=0 ppid=4805 pid=4807 auid=staff uid=USER gid=USER euid=USER suid=USER fsuid=USER egid=USER sgid=USER fsgid=USER tty=(none) ses=13 comm=vim exe=/usr/bin/vim subj=staff_u:staff_r:crontab_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(07/17/2023 10:42:32.287:551) : avc: denied

{ write }

for pid=4807 comm=vim name=USER dev="dm-0" ino=16967532 scontext=staff_u:staff_r:crontab_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir permissive=0
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This happens when vim, executing as "crontab_t" and used as default editor for "crontab -e" tries to write its /home/USER/.viminfo file.
Due to not being able to read the user's home directory. This is NOT related to "use_pty".

Version-Release number of selected component (if applicable):
selinux-policy-38.1.33-1.el9.noarch
selinux-policy-targeted-38.1.33-1.el9.noarch

How reproducible:

Always

Steps to Reproduce:
1. Add "Defaults use_pty" to /etc/sudoers
2. Let a user mapped to "staff_u" sudo to the target user "USER"

1. cat /etc/sudoers.d/staff
   staff ALL = (USER) NOPASSWD: ALL

3. Execute various scenarios above

Actual results:

Failures

Expected results:

No failures