Bug 1194575

Summary:	Add support for /etc/profile.d, /etc/security/limits.d, and /etc/sudoers.d directories when scanning a system
Product:	Red Hat Enterprise Linux 8	Reporter:	Jan Lieskovsky <jlieskov>
Component:	scap-security-guide	Assignee:	Watson Yuuma Sato <wsato>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	low	Docs Contact:
Priority:	medium
Version:	8.0	CC:	ddas, lcervako, matyc, mhaicman, mthacker, openscap-maint, pvrabec, wsato
Target Milestone:	rc
Target Release:	8.2
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-01 03:02:39 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:

Description Jan Lieskovsky 2015-02-20 09:13:47 UTC

Description of problem:

The current version of scap-security-guide performs multiple checks testing system properties configured via /etc/profile, /etc/sudoers, and /etc/security/limits.conf locations. Since the corresponding system properties can be configured also via the configuration files located under:
* /etc/profile.d,
* /etc/security/limits.d, and
* /etc/sudoers.d

paths, the existing checks should be enhanced to honour these locations when performing the system scan too.

Version-Release number of selected component (if applicable):
scap-security-guide-0.1.18-3.el6

How reproducible:
Always

Steps to Reproduce:
1. Place system configuration in some of /etc/profile.d, /etc/security/limits.d, and / or /etc/sudoers.d locations
2. Perform the system scan involving rule touching /etc/profile, /etc/security/limits.conf, and / or /etc/sudoers configuration.


Actual results:
System settings placed in /etc/security/limits.d, /etc/profile.d, and /etc/sudoers.d directories aren't honoured when inspecting the system settings / configuration to meet the security guidance requirements.

Expected results:
System settings placed also in /etc/security/limits.d, /etc/profile.d, and /etc/sudoers.d locations are taken into account when inspecting system configuration for compliance.

Comment 4 Shawn Wells 2018-03-26 17:56:39 UTC

Is there a reason why this BZ has been made private?

Comment 7 Marek Haicman 2019-03-12 16:12:46 UTC

This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. I am moving it to Red Hat Enterprise Linux 8, as there is valid risk of false negatives / positives.

Comment 8 Shawn Wells 2019-03-12 16:14:19 UTC

Given how this bug was opened in 2015-02-20, and already patched upstream, why will it not be included in RHEL 7.7?

It's absurd that four year old bugs remain unpatched in RHEL.

Comment 9 Shawn Wells 2019-03-12 16:15:26 UTC

Mark - Can you review for inclusion in RHEL 7.7? This is required for compliance with every single US Government baseline, as well as PCI-DSS, HIPAA, SOX, etc.

It's been patched upstream for several years.

Comment 10 Shawn Wells 2019-03-12 16:23:51 UTC

/etc/profile.d:
Added back in 2016 via https://github.com/ComplianceAsCode/content/commit/ebe0f88b90dcf97143244ebb60f883c803a879f1

/etc/security/limits.d:
Added back in 2016 via https://github.com/ComplianceAsCode/content/commit/1148ef47def068416797af8e81ce9fb8d445316d

and /etc/sudoers.d:
Added back in 2016 via https://github.com/ComplianceAsCode/content/commit/ec99dcb4555367787dbea8e856e0caf7a33e524f

At this point there is a need to perform some QE to ensure the "conf.d" style directories are checked in all the applicable rules. For example, ensuring sudoers.d for all rules under linux_os/guide/system/sudo/*. But that should be a matter of copy/pasting code into the appropriate rules.... not especially requiring net-new development.

Comment 11 Marek Haicman 2019-03-13 18:19:06 UTC

Yes, it is available for some of the rules already. Adding support is not about having particular rules use it, but to have a method to ensure there won't be other rules where the same should apply, which would check just one of the sources.

So even though I kind of agree with your assessment Shawn about four years old BZ not being fixed, I believe this issue is about systemic approach to the problem, and that will require new templates, or macros, and development time.

Of course the fixes you linked are shipped for a long time - last sync with the upstream has happened on version 0.1.40

Comment 13 Shawn Wells 2019-03-21 17:41:03 UTC

Marek, what is the status on this? Have you been able to patch the content yet? Has been several weeks.

Comment 14 Marek Haicman 2019-05-27 16:51:26 UTC

I am descoping this BZ (removing "feature" designation) - instead of systemic approach, let's just provide good enough content. We can iterate later on, if such a need arises.

Comment 15 Shawn Wells 2019-05-30 17:10:06 UTC

How many RFEs are needed for Red Hat Engineering to take action on this? The request is now several years old. It appears Red Hat Engineering has no intention of supporting or fixing known bugs.

Comment 21 RHEL Program Management 2020-11-01 03:02:39 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.