Compliance Finding: Non-RPM Managed/Conflicting File Ownership/Permissions - Documented Issues

Posted on

I am interested in an official set of Red Hat Knowledgebase (KB) Solutions or other Entries we can present to the US and other Governments and Public Entities.
In their absence, I'll begin with my current set of Documented Issues.

--- BEGIN ---

There are several types of issues with RHEL file ownership/permissions not matching RPM file ownership/permissions, especially when vendor nominal or even required for execution, on run-time systems.

To start, there are least four (4) documented issues include, but are not limited to, the following …

1) Permissions - Default Umask: A classic issue stems from the origins of Fedora (2003) of which all RHEL releases since 4 are based on, and all versions have been impacted since 2008 (RHEL5+). By default, the default umask during installation is 0002 (resulting file/dir mode 0664/0775), while the default for users, including the superuser (root), may be umask 0022 (mode 0644/0755). [bz#83006]

  • E.g., /var/log/dmesg (packge: initscripts) installed with permissions 0000 (purposely useless), but default umask results in the files being re-created (which happens on every boot) as 0644 or similar.

2) Permissions – DISA STIG Umask: The DISA STIG further impacts RPM defaults as any files created, deleted, modified, etc… are subject to a modified default for users, including the superuser (root), should be umask 0077 (mode 0600/0700). This results in an actually more secure configuration, even if does not break software, but does cause a finding as a result of no longer being the RPM fle mode/permission default. [V-38647]

  • E.g., /boot/initramfs-*.img (package: kernel) installed with permissions 0644, but STIG umask results in the files being re-created, with system-specific kernel modules (drivers) for startup, 0600.

3) Ownership/Permissions – Post-RPM install/update: As noted in even the prior Fedora issue, RPM installation scripts (e.g,. %post or %triggerin) in a RPM package run outside of the RPM file management. So they may change and even differ from RPM managed file ownership/permissions. A common issue is when adding an user, who will own a file, after installing the files in a RPM as root. Red Hat’s own packaging Guidelines do not cover this scenario, and different, resulting implementations exist, even in its core software like systemd. [RHEL7rpm]

  • E.g., /var/log/journal (package: systemd) installed with ownership/permissions 0755 root.root, but run-time ownership/permissions needing to be 2755+ root.systemd-journal (+ Access Control Lists, ACLs).

4) Ownership/Permissions – Latent installation/setup: Some software installed on the system by RPM is not installed/configured until desired, and then the run-time is changed by on-system, run-time software, such as Red Hat’s site-local Python framework for managing many enterprise solutions. Until that time, the software is installed with useless (and broken) ownership/permissions such as 0600 root.root or 0644 root.root or similar, when the software does not execute as root. [xxxxx097]

  • E.g., /etc/dirsrv, /var/lib/dirsrv, etc… for 389/IPA Services, /var/named/dyndb-ldap/ipa, /var/run/opendnssec for IPA/DNS Services, owned by root (superuser), until setup and used by dirsrv/named (unprivileged) service accounts

--- REFERENCES ---

[bz#83006] Red Hat Bugzilla #83006 (2003-Jan, closed 2008-Jan): ‘Red Hat rpm installs sometimes done using root’s umask’
- https://bugzilla.redhat.com/show_bug.cgi?id=83006

2003-Jan: What I'd expect to happen is that rpm would insure that a proper umask is used when any installation scripts run, just as it insures all files are installed with the proper permissions regardless of root's umask. My problem was by rpm leaving a file too secure, and the system was in an unusable state. Someone else who happens to have root's umask as 000 when they run rpm may leave critical system files world writeable and open to easy attack.
…
2008-Jan: rpm 4.4.2.3-0.1.rc1 in rawhide sets umask to 0002 always so this should be fixed (finally)

[V-38647] DISA STIG Finding V-38647 (RHEL7): ‘The system default umask in /etc/profile must be 077’
- https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/2017-05-19/finding/V-38647

To ensure the default umask controlled by "/etc/profile" is set properly, add or correct the "umask" setting in "/etc/profile" to read as follows:

  umask 077

[RHEL7rpm] Red Hat Enterprise Linux 7 – RPM Packaging Guide
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/rpm_packaging_guide/index

[xxxxx097] Red Hat Case xxxxx097 - IPA Permissions for select dirsrv, named directories, differ from RPM defaults
- https://access.redhat.com/support/cases/#/case/xxxxx097
NOTE: Customer-specific, Customer has requested Red Hat release a public article for general use

1) Looking at the permissions and ownership of my RHEL 7 IPA setup, the results match the modified (and not the initial rpm) settings. Comparisons are in-line:

      RPM:       drwxr-xr-x    2 root    root      0 Oct 29 19:52 /etc/dirsrv
      sys:       drwxrwxr-x.   6 root    dirsrv  103 Oct 29 19:52 /etc/dirsrv
      RPM:       drwxr-xr-x    2 root    root      0 Oct 29 19:52 /var/lib/dirsrv
      sys:       drwxrwxr-x.   4 root    dirsrv   52 Oct 29 19:52 /var/lib/dirsrv
      RPM:       drwxr-xr-x    2 root    root      0 Oct 29 19:52 /var/lock/dirsrv
      sys:       drwxrwx---.   3 dirsrv  dirsrv   60 Dec 13 22:56 /var/lock/dirsrv
      RPM:       drwxr-xr-x    2 root    root      0 Oct 29 19:52 /var/lock/dirsrv
      sys:       drwxrwx---.   3 named   named    20 Sep 21  2017 /var/named/dyndb-ldap/ipa
      RPM:       drwxrwx---    2 root    ods       0 Apr 12  2017 /var/run/opendnssec
      sys:       drwx------.   2 ods     ods      40 Dec 13 22:56 /var/run/opendnssec
           …

2) Searching for occurrences of "chown" in the IPA packages source code that is stored in /usr/lib/python2.7/site-packages:

      # grep -ir -c chown /usr/lib/python2.7/site-packages

We see a few results indicating that some installer scripts indeed modify ownership of files and directories to the "ods" and "named" users and groups:

      /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py:79:        os.chown(paths.BIND_LDAP_DNS_IPA_WORKDIR, self.named_uid,
      /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py:177:            # chown ods:named
      /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py:178:            os.chown(paths.IPA_DNSSEC_DIR, self.ods_uid, self.named_gid)
      /usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py:223:        # chown to ods:named
           …

3) When IPA packages are are first installed, rpm sets an initial set of ownership and permissions.
But as you suspected, during the setup and configuration of IPA, service accounts like "dirsrv", "named" and "ods" are created, and files/directories are handed over to them:

      # egrep "dirsrv|ods|named" /etc/{passwd,group}
      /etc/passwd:named:x:25:25:Named:/var/named:/sbin/nologin
      /etc/passwd:ods:x:996:993:softhsm private keys owner:/var/lib/softhsm:/sbin/nologin
      /etc/passwd:dirsrv:x:389:389:user for 389-ds-base:/usr/share/dirsrv:/sbin/nologin
      /etc/group:named:x:25:
      /etc/group:ods:x:993:
      /etc/group:dirsrv:x:389:

The final file and directory permissions and ownership you are seeing are correct and part of a regular IPA setup.

--- END ---

Bryan Smith's picture

Responses