Jan;
Thanks for the detailed feedback. I understand the reasoning now. I also think that it is
always safest to go ahead and explicitly place those options in the configuration files
(in this case sshd_config). My concern, though, is that without having modified
sshd_config AT ALL every OVAL check passed. Typically, I run the SCAP tools once to give
me a starting point and begin fixing the Failed and Unchecked items from there. Had I not
had so much experience hardening RHEL systems I would have overlooked these sshd
configurations because they all reported as passed. I would submit that these tests should
all fail if the setting is not present and uncommented.
Also, on a more general note/question would it be possible to do a "match all"
type of scenario for configuration directives with many required options/arguments so that
it wasn't necessary to ensure that they match the exact order specified in the OVAL
check. For example, I was configuring auditd yesterday. I copied stig.rules from
/usr/share/doc/audit-<version> to /etc/audit/rules.d. Even though the items in
stig.rules meet all of the requirements outlined in the SSG many of the checks fail
because the options aren't listed in the same order as they are in the OVAL.
Here's a concrete example:
stig.rules contains:
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -F
exit=-EACCES -f auid>=500 -F auid!=4294967295 -k acess
The OVAL, in this case, checks for:
^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?\-S\s+creat\s+\-S\s+open\s+\-S\s+openat\s+\-S\s+truncate\s+\-S\s+ftruncate\s+\-F\s+exit=\-EPERM\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
As you can tell the 'stig.rules' contains an extra syscall (open_by_handle_at)
which will cause this check to always fail unless either the OVAL is updated or the audit
rule is modified to match the check exactly. It might make more sense to check multiple
patterns and require that they all pass:
^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?.*\-S\s+creat.*\-F\s+exit=\-EPERM\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
AND
^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?.*\-S\s+open.*\-F\s+exit=\-EPERM\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
AND
^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?.*\-S\s+openat.*\-F\s+exit=\-EPERM\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
AND
^\-a\s+always,exit\s+(\-F\s+arch=(b64|b32)\s+)?.*\-S\s+truncate.*\-F\s+exit=\-EPERM\s+\-F\s+auid>=500\s+\-F\s+auid!=4294967295\s+\-k\s+[-\w]+\s*$
Note the '.*' bookending the actual syscall being matched in each test.
Although I am aware that this begins to make the OVAL content much more bulky and we are
probably trying to make it as terse as possible. This is probably also a special case
because most services don't include templates like auditd. Anyway, I'm just trying
to open up a discussion and possibly help out.
Let me know if I can help.
Thanks again!
-Lesley Kimmel
Date: Thu, 11 Jun 2015 05:27:15 -0400
From: jlieskov(a)redhat.com
To: ljkimmel99(a)hotmail.com
CC: scap-security-guide(a)lists.fedorahosted.org
Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
----- Original Message -----
> From: "Lesley Kimmel" <ljkimmel99(a)hotmail.com>
> To: "SSG" <scap-security-guide(a)lists.fedorahosted.org>
> Sent: Thursday, June 11, 2015 12:14:56 AM
> Subject: RHEL6 SSG Bug (SSH,Ciphers)
>
> All;
>
> I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely
> an issue with the check for approved Ciphers. Initially the check passed
> with no entry at all for Ciphers. I then placed a Cipher line with (1) valid
> cipher: pass. Finally I put an entry in sshd_config with a bogus cipher:
> passed. I just ran into this at the end of my workday today so I didn't get
> much of a chance to analyze it. Plus I'm really just starting to dig into
> the 'innards' of the content so I don't fully realize the connections of
all
> the various sections (rule/def/tst/obj/ste).
Thank you for the report. I will have a look into this issue && report the
findings back once obtained.
> I'm also pretty sure that some
> of the other checks against sshd_config are off. The check for
> 'PermitRootLogin no' passed even though the file contains
'#PermitRootLogin
> yes
For this part it is possible the corresponding regular expression doesn't
honours comments properly. I will double check that (btw would be good
if you could try the very same with the most recent scap-security-guide
0.1.22 version from upstream's Git, since it's possible it got corrected
upstream
in between already). But I will double check that, and report back.
>' and typically the checks are looking for the presence of the target
> string, not the absence of it.
For the last part ("the checks are looking for the presence of the target
string, not the absence of it" - this is motivated by the "nature" of the
sshd service and it's config file /etc/ssh/sshd_config.
A bit longer story about sshd hopefully without too much gory details being
as follows - sshd besides loading settings from /etc/sshd/sshd_config file
honours also internal "default" options / settings. To mention an example --
"Protocol 2" directive has become a default setting starting from certain
sshd version. The implication of these internal "default" settings being
that in order to obtain the exact sshd configuration, that will be actually
used, it is not sufficient to inspect the content of /etc/ssh/sshd_config file,
because it will not list / contain all the settings that will be actually applied.
The only way how to obtain the real settings is to run the "sshd -T" command,
which will print out the real settings. Since in the OVAL checks it is not
possible to run external / arbitrary commands (this limitation is one of the
features of the OVAL language), it is not possible within sshd OVAL checks
to run "sshd -T" to obtain final configuration, and therefore it is not
possible
reliably to verify if some setting is applied or not (it might be applied
despite not being explicitly present in the /etc/ssh/sshd_config file.
Like it is the case for the "Protocol 2" default internal setting for some
time already).
Since we can't inspect the values of internal "default" options, the only
way how
for sure to tell if the system is configured properly, is to require the option
being explicitly present in the /etc/ssh/sshd_config file. In other words we still
require the "Protocol 2" directive to be explicitly present in the
/etc/ssh/sshd_config
file even when "Protocol 2" internal setting has become "default"
already and it's
very unlikely some sshd setting would use "Protocol 1" version. The obvious
implication
of this approach being that the sshd OVAL checks might report false negatives in some
cases (system is configured properly due to the use of safe internal "default"
value,
but since the particular option isn't present in /etc/ssh/sshd_config [it's the
sshd's
default, so it's not necessary to be listed there, since it will be used anyway],
we are reporting failure like in the case the system would be configured improperly).
There of course is a way how to report proper sshd results - add a new <sshd_test>
probe to the 5.12 version of the OVAL language that would internally run "sshd
-T"
command when querying sshd options.
That way we would truly inspect sshd options, that would be really applied. But
it is not a short-term solution (it takes time till the proposal is accepted into
OVAL language, it takes time till the new feature is implemented, and last but not
least it would work only on those OVAL scanner versions supporting OVAL 5.12 language
versions. IOW till this is implemented, I am afraid we don't have a different
option,
just to explicitly require some option to be present in /etc/ssh/sshd_config even
when this might lead to reporting false negatives in some cases).
>
> Any input would be appreciated.
Hope the above explains the background / motivations behind requiring presence
of an options a bit. FWIW regarding those two reported issues (Ciphers check &&
PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting) I will
inspect them yet && report the findings back.
>
> Thanks,
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
> Les Kimmel
> Systems Engineer, CSC
>
> --
> SCAP Security Guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
https://github.com/OpenSCAP/scap-security-guide/