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-3.14.3-117.el8_8.2.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"

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

3. Execute various scenarios above

Actual results:

Failures

Expected results:

No failures