Bug 2122838
| Summary: | SELinux prevents confined users (staff_u, sysadm_u) from successfully running vlock | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Daniel Reynolds <dareynol> | |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> | |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> | |
| Severity: | medium | Docs Contact: | Petr Hybl <phybl> | |
| Priority: | medium | |||
| Version: | 8.6 | CC: | jafiala, lvrabec, mmalik, phybl, zpytela | |
| Target Milestone: | rc | Keywords: | AutoVerified, Triaged | |
| Target Release: | 8.8 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | Unspecified | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | selinux-policy-3.14.3-110.el8 | Doc Type: | Bug Fix | |
| Doc Text: |
.`vlock` now works properly for confined users
Previously, the confined user could not use `vlock` due to SELinux policy.
Consequently, the `vlock` command did not work properly for confined users.
With this update, the SELinux policy has been updated with new rules for confined users.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2123260 (view as bug list) | Environment: | ||
| Last Closed: | 2023-05-16 09:03:52 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
# rpm -qa kbd selinux\* | sort kbd-2.0.4-10.el8.x86_64 selinux-policy-3.14.3-107.el8.noarch selinux-policy-devel-3.14.3-107.el8.noarch selinux-policy-doc-3.14.3-107.el8.noarch selinux-policy-minimum-3.14.3-107.el8.noarch selinux-policy-mls-3.14.3-107.el8.noarch selinux-policy-sandbox-3.14.3-107.el8.noarch selinux-policy-targeted-3.14.3-107.el8.noarch # ausearch -m avc -m user_avc -m selinux_err -i -ts today | audit2allow allow vlock_t apm_bios_t:chr_file getattr; allow vlock_t autofs_device_t:chr_file getattr; allow vlock_t cachefiles_device_t:chr_file getattr; allow vlock_t clock_device_t:chr_file getattr; allow vlock_t event_device_t:chr_file getattr; allow vlock_t fixed_disk_device_t:blk_file getattr; allow vlock_t framebuf_device_t:chr_file getattr; allow vlock_t fuse_device_t:chr_file getattr; allow vlock_t gpmctl_t:sock_file getattr; allow vlock_t initctl_t:fifo_file getattr; allow vlock_t kmsg_device_t:chr_file getattr; allow vlock_t kvm_device_t:chr_file getattr; allow vlock_t loop_control_device_t:chr_file getattr; allow vlock_t memory_device_t:chr_file getattr; allow vlock_t netcontrol_device_t:chr_file getattr; allow vlock_t nvram_device_t:chr_file getattr; allow vlock_t ppp_device_t:chr_file getattr; allow vlock_t printer_device_t:chr_file getattr; allow vlock_t proc_kcore_t:file getattr; allow vlock_t ptmx_t:chr_file getattr; allow vlock_t tty_device_t:chr_file getattr; allow vlock_t uhid_device_t:chr_file getattr; allow vlock_t usbmon_device_t:chr_file getattr; allow vlock_t vhost_device_t:chr_file getattr; allow vlock_t virtio_device_t:chr_file getattr; allow vlock_t watchdog_device_t:chr_file getattr; allow vlock_t wireless_device_t:chr_file getattr; allow vlock_t xserver_misc_device_t:chr_file getattr; # The removal of dontaudit rules revealed the real culprit:
----
type=PROCTITLE msg=audit(08/31/2022 09:28:27.751:867) : proctitle=vlock
type=PATH msg=audit(08/31/2022 09:28:27.751:867) : item=0 name=/dev/pts/1 nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(08/31/2022 09:28:27.751:867) : cwd=/home/sysadm-user
type=SYSCALL msg=audit(08/31/2022 09:28:27.751:867) : arch=x86_64 syscall=stat success=no exit=EACCES(Permission denied) a0=0x55b5ce6f0b60 a1=0x7ffdd6518320 a2=0x7ffdd6518320 a3=0x0 items=1 ppid=9040 pid=12550 auid=sysadm-user uid=sysadm-user gid=sysadm-user euid=sysadm-user suid=sysadm-user fsuid=sysadm-user egid=sysadm-user sgid=sysadm-user fsgid=sysadm-user tty=pts1 ses=17 comm=vlock exe=/usr/bin/vlock subj=sysadm_u:sysadm_r:vlock_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(08/31/2022 09:28:27.751:867) : avc: denied { search } for pid=12550 comm=vlock name=/ dev="devpts" ino=1 scontext=sysadm_u:sysadm_r:vlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:devpts_t:s0 tclass=dir permissive=0
----
type=PROCTITLE msg=audit(08/31/2022 09:28:27.756:868) : proctitle=vlock
type=PATH msg=audit(08/31/2022 09:28:27.756:868) : item=0 name=/dev/pts inode=1 dev=00:17 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:devpts_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(08/31/2022 09:28:27.756:868) : cwd=/home/sysadm-user
type=SYSCALL msg=audit(08/31/2022 09:28:27.756:868) : arch=x86_64 syscall=stat success=no exit=EACCES(Permission denied) a0=0x7f6b486eed93 a1=0x7ffdd6518320 a2=0x7ffdd6518320 a3=0x0 items=1 ppid=9040 pid=12550 auid=sysadm-user uid=sysadm-user gid=sysadm-user euid=sysadm-user suid=sysadm-user fsuid=sysadm-user egid=sysadm-user sgid=sysadm-user fsgid=sysadm-user tty=pts1 ses=17 comm=vlock exe=/usr/bin/vlock subj=sysadm_u:sysadm_r:vlock_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(08/31/2022 09:28:27.756:868) : avc: denied { getattr } for pid=12550 comm=vlock path=/dev/pts dev="devpts" ino=1 scontext=sysadm_u:sysadm_r:vlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:devpts_t:s0 tclass=dir permissive=0
----
The following policy module fixed the problem on my VM:
# cat mypolicy.cil
( allow vlock_t devpts_t ( dir ( getattr search )))
# semodule -i mypolicy.cil
#
[staff-user@localhost ~]$ id
uid=1001(staff-user) gid=1001(staff-user) groups=1001(staff-user),957(wireshark) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
[staff-user@localhost ~]$ vlock
This tty (pts/0) is not a virtual console.
The pts/0 is now locked by staff-user.
Password:
[staff-user@localhost ~]$ echo $?
0
[staff-user@localhost ~]$
[sysadm-user@localhost ~]$ id
uid=1005(sysadm-user) gid=1005(sysadm-user) groups=1005(sysadm-user) context=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
[sysadm-user@localhost ~]$ vlock
This tty (pts/0) is not a virtual console.
The pts/0 is now locked by sysadm-user.
Password:
[sysadm-user@localhost ~]$ echo $?
0
[sysadm-user@localhost ~]$
Above-mentioned { getattr } SELinux denials on various chr_file objects still appear, but additional policy rules does NOT seem to be needed for the scenario to work.
Should be sufficient because:
# sesearch -A -s vlock_t -t device_node -c chr_file -p getattr
...
allow domain devtty_t:chr_file { append getattr ioctl lock open read write };
allow syslog_client_type console_device_t:chr_file { append getattr ioctl lock open write };
allow vlock_t user_devpts_t:chr_file { append getattr ioctl lock read write };
allow vlock_t user_tty_device_t:chr_file { append getattr ioctl lock read write };
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:2965 |
Description of problem: SELinux confined users staff_u, sysadm_u cannot run vlock successfully. Version-Release number of selected component (if applicable): - selinux-policy-3.14.3-95 - kbd-2.0.4-10 How reproducible: Always Steps to Reproduce: 1. Configure sudo to run in sysadm_r Edit /etc/sudoers ~~~ %wheel ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t NOPASSWD: ALL ~~~ 2. Create a SELinux confined user. ~~~ useradd -C 'Test confined user' --selinux-user test-staff passwd test-staff XXXXXX ~~~ 3. Log into test-staff 4a. Run vlock as test-staff, OR ~~~ $ vlock ~~~ 4b. Run vlock via sudo ~~~ $ sudo vlock ~~` Actual results: ~~~ [test-staff@rhel8-minimal ~]$ vlock vlock: stdin is not a tty[test-staff@rhel8-minimal ~] ~~~ OR ~~~ [test-staff@rhel8-minimal ~]$ sudo vlock vlock: stdin is not a tty[test-staff@rhel8-minimal ~]$ ~~~ Expected results: ~~~ [dareynol@rhel8-minimal ~]$ vlock This tty (pts/0) is not a virtual console. The pts/0 is now locked by dareynol. Password: ~~~ OR ~~~ [dareynol@rhel8-minimal ~]$ sudo vlock This tty (pts/0) is not a virtual console. The pts/0 is now locked by root. Password: ~~~