Bug 1553916

Summary: Packaging issues and possible STIG violations
Product: [Fedora] Fedora Reporter: Chris Williams <cww>
Component: distributionAssignee: Václav Pavlín <vpavlin>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: cdonnell, jcastran, kwalker, mattdm
Target Milestone: ---Keywords: Tracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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:

Description Chris Williams 2018-03-09 21:11:12 UTC
The issue is somewhat, though not entirely, related to the following entry in the DISA STIG implementation:

  CCE-27209-6 Verify and Correct File Permissions with RPM

The finding above is related to the mode for files in the RPM
database. This essentially boils down to the following command being
run on customer systems:

  #  rpm -Va | grep '^.M'


For most systems, this isn't a problem. However, it turns out that
with the RHEL 7 release, when we backported the Fedora 15 /run
non-persistent change [^1], it introduced a subtle packaging issue.
With /run and /var/run  being ephemeral, our packaging maintainers
should have introduced systemd-tmpfiles drop-in configuration files in
the event that the specfile includes files in either of these paths.
That effort looks to have been very hit-or-miss. An example of this
type of specific issue came up back in June and I opened the following
with a good outcome:

    Bug 1462802 – /var/run/resource-agents/ is created with the
incorrect mode https://bugzilla.redhat.com/show_bug.cgi?id=1462802


The issue in regards STIG is that you get the following permutations
for impacted packages.

  1 - Install the RPM
     - Scan the system - PASS


  2 - Restart the system - Service _not_ set to start on boot
     - Scan the system - PASS


  3 - Restart the system - Service _is_ set to start on boot
     - Scan the system - PASS/FAIL - Depending on the umask present
when the process starts vs the mode defined in the RPM spec


  3 - Start the application
     - Scan the sytsem - PASS/FAIL - Depending on the umask present
when the process starts vs the mode defined in the RPM spec


Fast forward to the end of this year, and we now have a RHEL customer that
isn't really concerned with any one particular RPM. They are concerned
that any package that isn't currently in compliance could cause a STIG
finding to be raised. The ask from them is that we start addressing
the issue via individual BZs for any package that has a file in these
paths and doesn't include a tmpfiles configuration.

Comment 1 Matthew Miller 2018-03-20 22:22:26 UTC
This is set as a tracking bug, but isn't made public. Could we change this to being a public tracker? Or, could we make one which could be public?