Automated SCAP content testing - request for feedback
by Jan Lieskovsky
Hello folks,
in relation with recent SCAP content failures:
[1] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-Novembe...
(I will come with a final fix for this one yet)
[2] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-Novembe...
(confirmed as valid report)
[3] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-Novembe...
(confirmed as valid)
[4] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-Novembe...
(pending review)
the more urgent requirement / need how to have a way for automated current RHEL6 (and Fedora)
SSG SCAP content testing available has arisen.
While these issues (when noticed) are mainly easy to be fixed, if went unnoticed they could
cause serious harm (false sense of security for failing RHEL6's sshd rule claiming it passed,
not working configuration for the login.defs / auditd cases).
To summary looks there's is an urgent need to have the content automatically tested somehow.
We were thinking about this yesterday a bit with Simon. Below are the (mainly in form
of brainstorming) proposals / comments:
* looks it would not be possible to have the test suite directly as part of SSG content
performing the tests during scap-security-guide package builds (for example to check
sshd rules it would require to modify underlying system configuration which would not
be straightforward on the system to be scanned),
* selected subset of the rules (mainly checks and remediations changing configuration)
could be tested via chroot directory. There's openscap offline scan feature:
[5] https://www.redhat.com/archives/open-scap-list/2013-May/msg00007.html
which could be used for this purpose (set up desired test directory structure somewhere
on the filesystem [possibly /tmp?] and instruct oscap via those environment variables
to perform rule evaluation for that directory structure). Have expected evaluation
result for each of such configurations, and compare the obtained results with the
expected ones.
* the previous proposal wouldn't still catch case when for example 'PermitRootLogin'
would be allowed by default in the sshd config. Rules like this require the OVAL
rule evaluation to be performed on one hand, on the other hand some kind of bash
script to be performed on the other (for this concrete case try to login remotely
for root via SSH to see if it's allowed), and compare result of the oval scan with
actual result from the system.
For this case we have been thinking to have set of predefined system configurations
(hopefully via kickstart files), and scripts to perform actual system behaviour checks.
The party responsible for the testing would then use the kickstart file to automatically
create the guest image of particular system, and would run those scripts on it (there
could be some unified interface to simplify the test runs yet).
We think that this could:
* prevent occurrence of issues like the above [1] up to [4] in the future,
* allow us to notice when something in the test outputs changed very early, so
we can possibly adjust the OVAL checks and / or remediations,
* speedup the certification process - since many of the failures would be
caught yet sooner than the content is provided to some independent party for
certification
* besides all the above it would be possible right in the moment of providing
new OVAL check / remediation to provide testing script for them too.
The proposal would still require us to perform the tests manually. But would at least
provided unified environment, the tests are expected to be performed at, and would provide
testing scripts (IOW requirements these concrete scripts must pass for the OVAL check /
remediation rule definition to be acceptable).
To be honest I see that this is just brainstorming proposal. Many things would need
to be changed during the way. Hopefully at the end we would end up combining
the above two approaches (running set of tests via oscap chroot's / offline scan
mode, another set via live testing operating system images and scripts modifying
their behaviour in desired way).
This has been written mainly with the intention, if there would be willingness
SSG upstream / members to participate in this effort.
If you have proposals, how this could be improved yet, we would like to hear
about them.
Once we have agreed on the preliminary form of the testing suite, we could
move on how it would be implemented, and where the content (the testing configuration
files, kickstart files, testing scripts) would be hosted.
Another possibility is us to start doing this for current Fedora content, and
apply it back against RHEL-6 content only in moment it has shown to be proper
approach, mature enough.
Comments / feedback welcome.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 4 months
gpgcheck fails ......... at epel-6-scap-security-guide.repo
by Gerwin Krist | LinQhost B.V.
Hi,
I'm new to open-scap, but i'm impressed with it so far. Very valuable piece
of software.
When I was cleaning things up I found that that the gpgcheck fails on
epel-6-scap-security-guide.repo. Which
has indeed gpgcheck=0 in it. I think this is not correct right?
Regards,
Gerwin
10 years, 4 months
[PATCH] [Fedora] Adjust service-enable-macro, service-disable-macro XSLT transforms. Fix service_ntpd_enabled OVAL check. Include patch from Simon Lukasik to obsolete openscap-content package
by Jan Lieskovsky
[Fedora] Adjust service-enable-macro, service-disable-macro XSLT transforms
definition to evaluate to proper systemd syntax
[Fedora] Fix service_ntpd_enabled OVAL check Fedora's make validate to pass again
[Fedora] Include patch from Simon Lukasik to obsolete openscap-content
package (RH BZ#1028706)
This patch includes the following:
* modifies the service-enable-macro, service-disable-macro definitions to use
systemd based syntax instead of chkconfig one (levels not present on Fedora
already),
* fix service_ntpd_enabled OVAL check Fedora's make validate not to fail with
"the max_depth, recurse, and recurse_direction behaviors are not allowed
with a filepath entity" error message,
* include Simon's patch to obsolete Fedora's openscap-content package
Passed basic sanity && regression testing. Pushed to master (since
the changes aren't invasive).
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 4 months
[PATCH] [Fedora] Add ntp_remote_server OVAL check [Fedora] Add new system/settings section to guide [Fedora] Include disable prelink rule into system settings
by Jan Lieskovsky
[Fedora] Add OVAL check to test if there's is remote NTP server configured for time data
[Fedora] Add system settings section for the guide (to track system wide hardening configurations)
[Fedora] Include disable prelink rule and OVAL check for it
This patch adds the following:
* provide OVAL check to test if /etc/ntp.conf contains 'server' entry
(based on RHEL6's one, just slightly modified),
* introduce new system/settings section for the guide (to track
universal system wide configurations / principles, which wouldn't
fall into other more specific category),
* include 'disable_prelink' rule as a representative of such a
system settings rule. Add OVAL check for it (based on RHEL6's one).
Please review.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 4 months
[Fedora] Add package_installed OVAL templating functionality [Fedora] Include initial OVAL check if ntpd service is enabled
by Jan Lieskovsky
[Fedora] Add package_installed OVAL templating directory structure and functionality
(prerequisite for the service enabled checks)
[Fedora] Include initial OVAL check if ntpd service is enabled
This patch adds:
* possibility to create package_installed OVAL checks in automated way
(based on RHEL6's checks/templates/create_package_installed.py),
* OVAL checks for ntp package installed and ntpd service enabled,
* and remediation for "ntpd service enabled" rule
Passed basic sanity && regression testing.
Please review.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 4 months
[PATCH] typo in auditd_data_retention_admin_space_left_action.sh
by Trayer, Jeb D CTR
Believe I found another one. After running the generated fix script auditd fails to start with the message "Wrong number of arguments for line X in /etc/audit/auditd.conf". Looked at auditd.conf and found admin_space_left_action wasn't equal to any action:
admin_space_left_action =
Looks like was just a typo in the /RHEL6/input/fixes/bash/auditd_data_retention_admin_space_left_action.sh between the variable in the populate statement with the variable that is used in the sed/echo statements, updates those statements to use the populate variable, generated new fix content and admin_space_left_action now gets set correctly.
Again, if looks good and someone that can push this (thanks Jan for doing the last one!) doesn't mind it's appreciated.
Thanks!
Jeb Trayer, CTR
USCG Operations System Center
Jeb.D.Trayer(a)uscg.mil
Signed-off-by: Jeb Trayer <jeb.d.trayer(a)uscg.mil>
---
...uditd_data_retention_admin_space_left_action.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/RHEL6/input/fixes/bash/auditd_data_retention_admin_space_left_action.sh b/RHEL6/input/fixes/bash/auditd_data_retention_admin_space_left_action.sh
index 68d684f..3499cc6 100644
--- a/RHEL6/input/fixes/bash/auditd_data_retention_admin_space_left_action.sh
+++ b/RHEL6/input/fixes/bash/auditd_data_retention_admin_space_left_action.sh
@@ -2,7 +2,7 @@ source ./templates/support.sh
populate var_auditd_admin_space_left_action
grep -q ^admin_space_left_action /etc/audit/auditd.conf && \
- sed -i "s/admin_space_left_action.*/admin_space_left_action = $var_auditd_space_left_action/g" /etc/audit/auditd.conf
+ sed -i "s/admin_space_left_action.*/admin_space_left_action = $var_auditd_admin_space_left_action/g" /etc/audit/auditd.conf
if ! [ $? -eq 0 ]; then
- echo "admin_space_left_action = $var_auditd_space_left_action" >> /etc/audit/auditd.conf
+ echo "admin_space_left_action = $var_auditd_admin_space_left_action" >> /etc/audit/auditd.conf
fi
--
1.7.1
10 years, 5 months
[PATCH] typo in accounts_password_warn_age_login_defs.sh
by Trayer, Jeb D CTR
Well here goes, first time I've ever made an attempt to submit a patch to any open source project!
I was testing some of the generated fix content and ran into an error when running user utilities(useradd/userdel) that used read /etc/login.defs, "configuration error - unknown item 'PASS_WARN_DAYS' (notify administrator)".
Looking at /etc/login.defs looks like "PASS_WARN_DAYS 7" was added to the end of login.defs, and I belive this should have been PASS_WARN_AGE. Looks like this was just a typo in the RHEL6/input/fixes/bash/accounts_password_warn_age_login.defs.sh, change PASS_WARN_DAYS to PASS_WARN_AGE, remade the guide, generated new fix content and ran it, and looks like /etc/login.defs is good, and error didn't return when running any user utils on RHEL 6.4
Hopefully I did everything correctly, if not please let me know. Also I won't be able to push anything to the git repo, so if this patch is good, if someone that can push the patch would, it would be appreciated.
Thanks!
Jeb Trayer, CTR
USCG Operations System Center
Jeb.D.Trayer(a)uscg.mil
Signed-off-by: Jeb Trayer <jeb.d.trayer(a)uscg.mil>
---
.../bash/accounts_password_warn_age_login_defs.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/RHEL6/input/fixes/bash/accounts_password_warn_age_login_defs.sh b/RHEL6/input/fixes/bash/accounts_password_warn_age_login_defs.sh
index 250b141..83ba76e 100644
--- a/RHEL6/input/fixes/bash/accounts_password_warn_age_login_defs.sh
+++ b/RHEL6/input/fixes/bash/accounts_password_warn_age_login_defs.sh
@@ -1,8 +1,8 @@
source ./templates/support.sh
populate var_accounts_password_warn_age_login_defs
-grep -q ^PASS_WARN_DAYS /etc/login.defs && \
- sed -i "s/PASS_WARN_DAYS.*/PASS_WARN_DAYS $var_accounts_password_warn_age_login_defs/g" /etc/login.defs
+grep -q ^PASS_WARN_AGE /etc/login.defs && \
+ sed -i "s/PASS_WARN_AGE.*/PASS_WARN_AGE $var_accounts_password_warn_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
- echo "PASS_WARN_DAYS $var_accounts_password_warn_age_login_defs" >> /etc/login.defs
+ echo "PASS_WARN_AGE $var_accounts_password_warn_age_login_defs" >> /etc/login.defs
fi
--
1.7.1
10 years, 5 months