+1 for leaving this service enabled On Jun 2, 2014 1:42 PM, "Shawn Wells" <[email protected]> wrote:
> > On 6/2/14, 2:01 PM, Rui Pedro Bernardino wrote: > >> This patch proposes to fix the missing oval check for 'disable_anacron' >> rule. >> >> Signed-off-by: Rui Bernardino <[email protected]> >> --- >> .../6/input/checks/templates/services_disabled.csv | 1 + >> RHEL/6/input/services/cron.xml | 1 + >> 2 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/RHEL/6/input/checks/templates/services_disabled.csv >> b/RHEL/6/input/checks/templates/services_disabled.csv >> index 7045072..c819e51 100644 >> --- a/RHEL/6/input/checks/templates/services_disabled.csv >> +++ b/RHEL/6/input/checks/templates/services_disabled.csv >> @@ -1,5 +1,6 @@ >> abrtd,abrt >> acpid, >> +anacron, >> autofs, >> certmonger, >> cgred, >> diff --git a/RHEL/6/input/services/cron.xml b/RHEL/6/input/services/cron.xml >> index 983d9ed..4f57af6 100644 >> --- a/RHEL/6/input/services/cron.xml >> +++ b/RHEL/6/input/services/cron.xml >> @@ -37,6 +37,7 @@ additional functionality, <tt>anacron</tt> could >> needlessly increase the possibl attack surface for an >> intruder.</description> <ref nist="CM-7" /> <ident cce="27158-5" /> >> +<oval id="service_anacron_disabled" /> >> </Rule> >> >> -- >> Rui Pedro Bernardino >> CTE2 >> Aveiro >> PT Inovação e Sistemas >> >> > I think, long ago, this was mapped to NIST 800-53 CM7 and just keeps > getting inherited. > > Yes, there is something to say about disabling non-essential services, but > really, anacron? IIRC it was either Spencer or Trevor who called out that > in the era of modern computing, not all systems are left up 24/7 (and thus > Anacron provides a valuable service). > > This is no longer included in the STIG, was inherited from RHEL5 USGCB > into the draft RHEL6 USGCB (which drove inclusion into the evolving FISMA > and NIST profiles). CS2 also calls it, but I believe that's from > inheritance too. > > Objections to dropping this rule from everything but CIS/C2S (where it's > still called out, but we're not the upstream of their policy yet)? > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
