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

Nunez, Luis K lnunez at mitre.org
Wed Dec 18 14:42:27 UTC 2013


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.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBAgAGBQJSsJBrAAoJEBYNRVNeJnmTrOEP/0lSQ03pocXYU5Ln4FPXIkSD
C2vzzayNP9YuSh3IUN2/Q2uABW7cPLnCbTH3Ixu7Eu2xQlgM4Fpye+G+lvijUJ2+
+A+A0CZhonmJqpJvF9x+Nod1CdvxQCqIvOTwzSXbts+21OMxWMYkJ4ImJojPk323
pH7tudQtXO6uIS2Ew46bGgpM5i+aopG1DrjEvbyZk1AY6wFcLILbiMV1Ps9qZ7DT
3AjJWFZLDoj6RgSJeh8FlxDoAw+BdzoFLMy1sPeMN66F4VrpvEkVAIJaQEqEalOX
Azc7e5Ipq0BWQVZO67vuiA1cjivJuvhtnf9ntI/0Zi0WrNvnkWBhk7ne2uaStVTw
973KkuxPpfZYrALoXQCCotYy/PSf6C6opU6QDhpCgJiWochzIhtUtNq3iLAtOzSt
QI7TL+u4Gkw+ePV+cXxWrNHNj+a5PtV2nogLtfVxZSDJnnS+junfhuTbgTnRus7C
NTpJQNJZVb+lpUFXPmR9NcGYNFPfp/wzzwsZTpCmRGncR6O6N4OPkjKyGE1v3hbJ
9BpVkXtzfF0HN124/FoejCfJD+4w+7+0zZMRDHYik370FJA6s3xJCll4oj03pbv+
qAkVSBHfYqPgpX6JjnAyvRNI7p+m1Y8ng/Uc3NQYgiewY+oUjfe8NeSK9dsXZ7mh
jI4BHvXjxZxX3uPwdv/H
=QQkJ
-----END PGP SIGNATURE-----
_______________________________________________
scap-security-guide mailing list
scap-security-guide at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7057 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20131218/31da9bc1/attachment-0001.p7s>


More information about the scap-security-guide mailing list