Hello folks,
in relation with applying sshd remediations, wondering if the fix should enforce restart of sshd (include command ensuring it).
From my point of view it should (the configuration till not reloaded
is still unsafe, even when configured safely), but since this touches area of runtime state again, rather checking with you first (prior proposing enhancement).
Justification: -------------- Absence of service restart past modification of its configuration file can be misleading, since though service configuration is safe already (and the subsequent check passes), it isn't really safe till not reloaded (which might happen in timeframe of months from the time point service configuration got changed).
On the other hand, should the service configuration file remediation / fix cause any issues, preventing the service from start (unlikely, but let's consider such a case might happen), in my opinion it's more straightforward the service to stop working immediately rather than in timeframe (possibly of months) making it subsequent debugging / identifying the reasons why it stopped to work more difficult.
Thoughts appreciated.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
On Tuesday, December 17, 2013 05:33:29 AM Jan Lieskovsky wrote:
in relation with applying sshd remediations, wondering if the fix should enforce restart of sshd (include command ensuring it).
No. The update itself takes care of what is sane to do. If you force a restart, you can kill rsync or an admin session at a really bad point in time.
There can be a check that shows unrestarted daemons if that is desirable. The sectool content used to do that. So, its possible to script. But I'd leave the decision about when to restart to the local admins.
-Steve
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. 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'. -Rob
________________________________________ From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Steve Grubb [sgrubb@redhat.com] Sent: Tuesday, December 17, 2013 9:51 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: Should the remediation enforce the restart of service configuration of which it's changing?
On Tuesday, December 17, 2013 05:33:29 AM Jan Lieskovsky wrote:
in relation with applying sshd remediations, wondering if the fix should enforce restart of sshd (include command ensuring it).
No. The update itself takes care of what is sane to do. If you force a restart, you can kill rsync or an admin session at a really bad point in time.
There can be a check that shows unrestarted daemons if that is desirable. The sectool content used to do that. So, its possible to script. But I'd leave the decision about when to restart to the local admins.
-Steve _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
----- Original Message -----
From: "Robert Sanders" rsanders@TrustedCS.com To: scap-security-guide@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/0...
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
-Rob
From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Steve Grubb [sgrubb@redhat.com] Sent: Tuesday, December 17, 2013 9:51 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: Should the remediation enforce the restart of service configuration of which it's changing?
On Tuesday, December 17, 2013 05:33:29 AM Jan Lieskovsky wrote:
in relation with applying sshd remediations, wondering if the fix should enforce restart of sshd (include command ensuring it).
No. The update itself takes care of what is sane to do. If you force a restart, you can kill rsync or an admin session at a really bad point in time.
There can be a check that shows unrestarted daemons if that is desirable. The sectool content used to do that. So, its possible to script. But I'd leave the decision about when to restart to the local admins.
-Steve _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/17/2013 08:57 AM, Jan Lieskovsky wrote:
----- Original Message -----
From: "Robert Sanders" rsanders@TrustedCS.com To: scap-security-guide@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/0...
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.
- -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
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@TrustedCS.com To: scap-security-guide@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/0...
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
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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@TrustedCS.com To: scap-security-guide@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/0...
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.
scap-security-guide@lists.fedorahosted.org