On 12/18/13, 9:42 AM, Nunez, Luis K wrote:
Inline below
-----Original Message-----
From:scap-security-guide-bounces@lists.fedorahosted.org
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Kurt
Seifried
Sent: Tuesday, December 17, 2013 12:57 PM
To:scap-security-guide@lists.fedorahosted.org
Subject: Re: Should the remediation enforce the restart of service
configuration of which it's changing?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/17/2013 08:57 AM, Jan Lieskovsky wrote:
> >----- Original Message -----
>> >>From: "Robert Sanders"<rsanders(a)TrustedCS.com> To:
>> >>scap-security-guide(a)lists.fedorahosted.org Sent: Tuesday,
>> >>December 17, 2013 4:24:22 PM Subject: RE: Should the remediation
>> >>enforce the restart of service configuration of which it's
>> >>changing?
>> >>
>> >>As you expand from must the local machine to an Enterprise
>> >>environment, this can be even more important. Suppose an
>> >>over-eager admin decides to remediate (via SCAP or some other
>> >>process) an entire Enterprise installation. If boxes are
>> >>rebooted automagically after the remediation you can
>> >>unintentionally take out the entire installation. Factor in
>> >>cases where there is a required start order (which I bet we've
>> >>all seen), and you've got the makings of a first class mess, with
>> >>really upset users/higher-ups.
> >
> >Thank you, Robert.
> >
> >Agree, that in the light of the above not enforcing the restart
> >makes more sense.
> >
>> >>I'd submit that having the option of a reboot is worthwhile, but
>> >>it needs to be wrapped in a couple layers of 'mother-may-I'.
> >
> >But to follow-up on Luis' post yet (to continue on their
> >proposal):
>
>https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-December/004712.html
> >
> > If there's some 'disruption' or 'reboot' attribute present
in the
> >XCCDF rule definition, should SSG be able to handle these in
> >automated way (IOW be able to add certain explanatory messages for
> >each of them automagically)?
> >
> >Or would we (for cases when it's clear) want to mention service
> >restart / reload is necessary for the configuration change to take
> >affect?
> >
> >Something like "2.7.4.n. Make the auditd Configuration Immutable"
> >rule has now .. "With this setting, a reboot will be required to
> >change any audit rules." ..
> >
> >which reflected into case of sshd could read as
> >
> >"With this setting the sshd service needs to be restarted for the
> >change to take effect."
> >
> >Should we manually go through the content we already have and
> >manually add those where appropriate?
> >
> >Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat
> >Security Technologies Team
> >
Would it be possible to have it default to no restart but have an
optional switch to do a restart? In general it's not safe to restart
by default, but it would be a nice option to offer.
[lnunez] I think this starts to become more of a tool implementation and task
management issue. We could start from XCCDF having the reboot=true to
indicate that a reboot/restart is in order and let the tool separate, manage,
authorize and perform the reboot function. The tool should be able to
separate the fixes that require reboot/restarts into a separate script. I
would also think leveraging the disruption attribute could also help in
managing and categorizing fixes.
Exactly. With the proper use of the reboot and disruption attributes,
this becomes a /tools/ conversation, not necessarily SSG /content/.
It would be interesting to see oscap be able to accept a
"--disruption-level" type flag, whereas oscap would only remediate for
settings equal to or lower than the value given.
And perhaps a "--reboot" option, which would drop an `init 6` as the
last line of the remediation script output.