Bug 1553916 - Packaging issues and possible STIG violations
Summary: Packaging issues and possible STIG violations
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Václav Pavlín
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-09 21:11 UTC by Chris Williams
Modified: 2022-03-13 14:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

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?


Note You need to log in before you can comment on or make changes to this bug.