+++ This bug was initially created as a clone of Bug #2215507 +++ Description of problem: With MLS policy and running in staff_r role, listing /var with details (ls -l /var) leads to missing permissions printing on some directories /var/account, /var/crash and /var/yp: --- [root@rhel88mls ~]# id -Z root:staff_r:staff_t:s0-s15:c0.c1023 [root@rhel88mls ~]# ls -l /var ls: cannot access '/var/yp': Permission denied ls: cannot access '/var/crash': Permission denied ls: cannot access '/var/account': Permission denied total 12 d?????????? ? ? ? ? ? account drwxr-xr-x. 2 root root 6 Jun 21 2021 adm drwxr-xr-x. 17 root root 4096 Jun 16 09:34 cache d?????????? ? ? ? ? ? crash drwxr-xr-x. 3 root root 18 Jun 16 09:32 db drwxr-xr-x. 3 root root 18 Jun 16 09:33 empty drwxr-xr-x. 2 root root 6 Jun 21 2021 ftp drwxr-xr-x. 2 root root 6 Jun 21 2021 games drwxr-xr-x. 2 root root 6 Jun 21 2021 gopher drwxr-xr-x. 3 root root 18 Jun 16 09:31 kerberos drwxr-xr-x. 44 root root 4096 Jun 16 09:39 lib drwxr-xr-x. 2 root root 6 Jun 21 2021 local lrwxrwxrwx. 1 root root 11 Jun 16 09:30 lock -> ../run/lock drwxr-xr-x. 12 root root 4096 Jun 16 09:41 log lrwxrwxrwx. 1 root root 10 Jun 21 2021 mail -> spool/mail drwxr-xr-x. 2 root root 6 Jun 21 2021 nis drwxr-xr-x. 2 root root 6 Jun 21 2021 opt drwxr-xr-x. 2 root root 6 Jun 21 2021 preserve lrwxrwxrwx. 1 root root 6 Jun 16 09:30 run -> ../run drwxr-xr-x. 11 root root 125 Jun 16 09:33 spool drwxrwxrwt. 4 root root 97 Jun 20 05:59 tmp d?????????? ? ? ? ? ? yp [root@rhel88mls ~]# --- - if we disable the dontaudit rules, we can see the AVC: --- type=AVC msg=audit(1687255689.872:732): avc: denied { getattr } for pid=3319 comm="ls" path="/var/yp" dev="dm-0" ino=33577240 scontext=root:staff_r:staff_t:s0-s15:c0.c1023 tcontext=system_u:object_r:var_yp_t:s0 tclass=dir permissive=1 type=SYSCALL msg=audit(1687255689.872:732): arch=c000003e syscall=332 success=yes exit=0 a0=ffffff9c a1=7ffc77ec0cb0 a2=900 a3=25e items=0 ppid=2097 pid=3319 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="ls" exe="/usr/bin/ls" subj=root:staff_r:staff_t:s0-s15:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=statx AUID="root" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1687255689.872:732): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F766172 type=AVC msg=audit(1687255689.872:733): avc: denied { getattr } for pid=3319 comm="ls" path="/var/crash" dev="dm-0" ino=34330039 scontext=root:staff_r:staff_t:s0-s15:c0.c1023 tcontext=system_u:object_r:kdump_crash_t:s0 tclass=dir permissive=1 type=SYSCALL msg=audit(1687255689.872:733): arch=c000003e syscall=332 success=yes exit=0 a0=ffffff9c a1=7ffc77ec0ca0 a2=900 a3=25e items=0 ppid=2097 pid=3319 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="ls" exe="/usr/bin/ls" subj=root:staff_r:staff_t:s0-s15:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=statx AUID="root" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1687255689.872:733): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F766172 type=AVC msg=audit(1687255689.872:734): avc: denied { getattr } for pid=3319 comm="ls" path="/var/account" dev="dm-0" ino=34558426 scontext=root:staff_r:staff_t:s0-s15:c0.c1023 tcontext=system_u:object_r:acct_data_t:s0 tclass=dir permissive=1 type=SYSCALL msg=audit(1687255689.872:734): arch=c000003e syscall=332 success=yes exit=0 a0=ffffff9c a1=7ffc77ec0ca0 a2=900 a3=25e items=0 ppid=2097 pid=3319 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="ls" exe="/usr/bin/ls" subj=root:staff_r:staff_t:s0-s15:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=statx AUID="root" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=PROCTITLE msg=audit(1687255689.872:734): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F766172 --- - From the policy, staff_t is not allowed to getattr for these dir: --- $ sesearch -A -s staff_t -p getattr -c dir -t acct_data_t <...> $ sesearch -A -s staff_t -p getattr -c dir -t httpd_sys_content_t <...> $ sesearch -A -s staff_t -p getattr -c dir -t kdump_crash_t <...> $ sesearch -A -s staff_t -p getattr -c dir -t var_yp_t allow nsswitch_domain var_yp_t:dir { getattr ioctl lock open read search }; [ nis_enabled ]:True --- - Is there a reason to have this deny for staff_r ? Version-Release number of selected component (if applicable): selinux-policy-mls-3.14.3-117.el8.noarch RHEL8 How reproducible: always Steps to Reproduce: 1. enable MLS 2. ls -l /var 3. Actual results: Directory attributes are not printed. Expected results: Details on directories Additional info:
Hi Benoit, You are right confined users are not allowed to get attributes of all files and directories. They are given permissions to files with the base_file_type and similar attributes, and the to parent directories types when rules for particular objects are in place, for example systemd_read_unit_files(user_t) expands to (among other rules) allow user_t systemd_unit_file_type:dir list_dir_perms; allow user_t systemd_unit_file_type:file read_file_perms Do you think there is a problem with that? By the way, it does not apply only in mls, but also in targeted.
Hi Zdenek, happy to see you here :D The only issue here, and for customer, is that they can't see directly see the permissions of directories in /var with staff_t, and for them it appears to be an "uneccessary restriction". Effectively, is there a security reason to avoid access to staff_t user to getattr such dir ? Thanks! Benoit
By default, unprivileged users are allowed get only file attributes of directories with the type which is in the base_file_type SELinux attribute. My concern was there potentially could be an information leak when the mls policy is actually used, but it turned out not to be the case.