Should the remediation enforce the restart of service configuration of which it's changing?

Shawn Wells shawn at redhat.com
Wed Dec 18 20:49:19 UTC 2013


On 12/18/13, 9:42 AM, Nunez, Luis K wrote:
> Inline below
>
> -----Original Message-----
> From:scap-security-guide-bounces at lists.fedorahosted.org  
> [mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of Kurt
> Seifried
> Sent: Tuesday, December 17, 2013 12:57 PM
> To:scap-security-guide at 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 at TrustedCS.com>  To:
>>> >>scap-security-guide at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20131218/863f44ed/attachment-0001.html>


More information about the scap-security-guide mailing list