RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2122838 - SELinux prevents confined users (staff_u, sysadm_u) from successfully running vlock
Summary: SELinux prevents confined users (staff_u, sysadm_u) from successfully running...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.6
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: 8.8
Assignee: Zdenek Pytela
QA Contact: Milos Malik
Petr Hybl
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-08-30 23:33 UTC by Daniel Reynolds
Modified: 2023-05-16 11:01 UTC (History)
5 users (show)

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.
Clone Of:
: 2123260 (view as bug list)
Environment:
Last Closed: 2023-05-16 09:03:52 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 1437 0 None open Allow vlock search the contents of the /dev/pts directory 2022-10-10 14:49:17 UTC
Red Hat Issue Tracker RHELPLAN-132775 0 None None None 2022-08-30 23:35:51 UTC
Red Hat Product Errata RHBA-2023:2965 0 None None None 2023-05-16 09:04:05 UTC

Description Daniel Reynolds 2022-08-30 23:33:32 UTC 
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:
    ~~~
Comment 1 Milos Malik 2022-08-31 07:16:46 UTC 
# 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;
#
Comment 2 Milos Malik 2022-08-31 07:41:54 UTC 
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 
----
Comment 3 Milos Malik 2022-08-31 07:49:49 UTC 
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.
Comment 4 Zdenek Pytela 2022-08-31 09:00:25 UTC 
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 };
Comment 19 errata-xmlrpc 2023-05-16 09:03:52 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.