Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 2216151

Summary: Listing /var with details (ls -l /var) leads to missing permissions printing on some directories
Product: Red Hat Enterprise Linux 8 Reporter: Welterlen Benoit <bwelterl>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: low Docs Contact:
Priority: low    
Version: 8.6CC: apeetham, daniel.j.arevalo.civ, lvrabec, mmalik, qe-baseos-security, zpytela
Target Milestone: rcKeywords: Triaged
Target Release: 8.9Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.14.3-125.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: 2215507 Environment:
Last Closed: 2023-11-14 15:47: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:
Bug Depends On: 2215507    
Bug Blocks:    
Deadline: 2023-08-08   

Description Welterlen Benoit 2023-06-20 10:11:31 UTC 
+++ 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:
Comment 1 Zdenek Pytela 2023-06-23 10:41:29 UTC 
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.
Comment 2 Welterlen Benoit 2023-06-24 09:08:06 UTC 
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
Comment 3 Zdenek Pytela 2023-08-02 15:24:26 UTC 
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.
Comment 11 errata-xmlrpc 2023-11-14 15:47: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:7091