IMO, there are two diffent issues:
(1) appending a acceptable parameter to a match block will limit the scope of
the parameter; eg:
Match User nox
X11Forwarding no
PermitRootLogin no
This will effectively be ignored.
(2) appending a non-acceptable parameter will result in a configuration error,
eg:
Match User nox
X11Forwarding no
ClientAliveInterval 900
This will cause the sshd to fail at startup (or restart, if you're lucky).
Bottom line, remediation should check for Match blocks and append any changes
in the preceding lines, not at end of file.
Regards
--
Rui Pedro Bernardino
CTE2/Tecnologias e Desenvolvimento
PT Inovação
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Jan
Lieskovsky
Sent: terça-feira, 17 de Dezembro de 2013 16:20
To: [email protected]
Subject: OpenSSH Match blocks / keywords handling [was Re: [PATCH] [RHEL6] Move
the closing quote in sshd disable root login remediation script at the end]
Thank you for opening this topic, Rui.
----- Original Message -----
> From: "Rui Pedro Bernardino" <[email protected]>
> To: [email protected]
> Sent: Tuesday, December 17, 2013 4:24:39 PM
> Subject: RE: [PATCH] [RHEL6] Move the closing quote in sshd disable root
> login remediation script at the end
>
>
>
> Hi all,
>
>
>
> Just to remind that sshd_config may have ‘Match’ blocks at the end of file.
> From the manual page:
>
> Match Introduces a conditional block. If all of the criteria on the
>
> Match line are satisfied, the keywords on the following lines
>
> override those set in the global section of the config file,
>
> until either another Match line or the end of the file.
>
> Any fixes/checks should have this into consideration… just appending
> won’t work in all cases.
While this is true (current implementation doesn't take these into
account) I am not sure about the SSG upstream opinion on this (if we should
check / fix just global options or also settings included in the Match blocks).
The purpose of Match blocks / keywords in OpenSSH is to allow / have some way
how to handle different configuration requirement (in comparison to the global
one) in certain circumstances (require keys by default, but allow login via
password from some concrete IP for example). Wondering if enforcing change on
configuration values also in Match blocks could "break the settings" from the
administrator's point of view.
On other hand while not changing them, might still allow selected use-cases to
be less safe than prescribed by the policy, it wouldn't touch the customs
administrators got accustomed to.
Wider opinion on this area appreciated.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
>
>
> Regards
>
>
>
>
> --
>
> Rui Pedro Bernardino
>
> CTE2/Tecnologias e Desenvolvimento
>
> PT Inovação
>
>
>
>
>
> From: [email protected]
> [mailto:[email protected]] On Behalf
> Of David Smith
> Sent: terça-feira, 17 de Dezembro de 2013 15:20
> To: [email protected]
> Subject: Re: [PATCH] [RHEL6] Move the closing quote in sshd disable
> root login remediation script at the end
>
>
>
>
>
> Your change makes total sense to me -- please push!
>
> On 12/17/2013 05:08 AM, Jan Lieskovsky wrote:
>
>
>
> When checking SSH remediation / fixes prior including them into
> Fedora, noticed there's a slight typo in
> RHEL6/input/fixes/bash/sshd_disable_root_login.sh:
> ..
> echo "PermitRootLogin "no >> /etc/ssh/sshd_config ..
> This by itself wouldn't cause the remediation to fail, but it to be
> more consistent with form of other fixes, moved the closing quote at
> the end (as assuming that's what was originally intended).
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
>
>
>
>
> _______________________________________________
> 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
>
_______________________________________________
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
