On 08/01/2013 05:09 AM, Shawn Wells wrote:
On 7/31/13 2:24 PM, Brian Peake wrote:
On 7/31/13 1:36 PM, "Shawn Wells" shawn@redhat.com wrote:
On 7/31/13 11:31 AM, Stuart Green wrote:
Ah-ha!! Thanks, I was looking for the buglist actually and couldn't find it!
Glad to be aboard :)
Hm. Perhaps this whole thing can be simplified.
Right now we have two checks: - package_telnet-server_removed.xml - service_telnetd_disabled.xml
They seem redundant, and I'm failing to find reasons against just deleting service_telnetd_disabled. There's no way telnet can be enabled if the package isn't installed, right?
Is there a reason to continue maintaining both checks?
Shawn, I don't think so. I believe there are other checks that have the same redundancy also
Everything in the 'Obsolete Services' can trivially be migrated away to a 'uninstall' rule: http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide...
These would be: - xinetd - telnet-server - rsh-server - ypserv - tftp-server
I'd wager much of the 'Base Services' fall under this too: http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-guide... - abrt - acpid - certmonger - cgconfig - cgred - cpuspeed - haldaemon - irqbalance - kdump - mdmonitor - messagebus - netconsole - ntpdate - oddjobd - portreserve - psacct - quota_nld - rdisc - rhnsd - rhsmcertd - saslauthd - smartd - sysstat
Can anyone think of why we'd want to have checks for*both* uninstall and disabled?
I can think of a case why you may want to have both checks (although I am not sure If the reason will be appealing enough for you).
The SSG is the most comprehensive and mature source of SCAP guidance for Linux. As such, SSG might be often taken as a starting point to build a guidance in an organization (ACME Corp).
There will never be policy which fits them all. And some of the organizations will need to amend SSG here-and-there.
OpenSCAP recently introduced tailoring feature, which allows you to have Profile element outside the Benchmark. That way you can have stock (signed) guidance (SSG presumably) and keep your own modification separated. This also allows for easier rebases (update of the SSG rpm).
And here is my take: There might be organization which will need to have a package (like acpid) installed (for some inevitable monthly use-case) but they would agree that it should not be run by deafult. Such organization could easily use tailoring feature to turn-off the `uninstall` check.