scap-security-guide November 2013

scap-security-guide@lists.fedorahosted.org

23 participants
73 discussions

[PATCH] [Fedora] Include descriptions for permissions section, and rules for checking permissions and ownership of shared library files and system executables
by Jan Lieskovsky 28 Nov '13

28 Nov '13

This patch includes descriptions for: * permissions section (File Permissions And Masks), * and descriptions for four rules related to checking permissions and ownership of shared library files and system executables (descriptions taken from RHEL6) Pushed to master (since it's just descriptions addons for Fedora, that already exist in RHEL6). Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

1 0

Automated SCAP content testing - request for feedback
by Jan Lieskovsky 27 Nov '13

27 Nov '13

Hello folks, in relation with recent SCAP content failures: [1] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-November/… (I will come with a final fix for this one yet) [2] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-November/… (confirmed as valid report) [3] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-November/… (confirmed as valid) [4] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-November/… (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

1 0

gpgcheck fails ......... at epel-6-scap-security-guide.repo
by Gerwin Krist | LinQhost B.V. 27 Nov '13

27 Nov '13

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

1 0

[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 26 Nov '13

26 Nov '13

[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

1 0

[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 25 Nov '13

25 Nov '13

[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

1 0

[Fedora] Add package_installed OVAL templating functionality [Fedora] Include initial OVAL check if ntpd service is enabled
by Jan Lieskovsky 25 Nov '13

25 Nov '13

[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

1 0

Compose with the OSCAP Anaconda Addon available
by Vratislav Podzimek 25 Nov '13

25 Nov '13

The project page of the OSCAP Anaconda Addon [1] now has a section about testing with links to the custom Fedora 20 compose with the OSCAP Anaconda Addon included and to some testing files. [1] https://fedorahosted.org/oscap-anaconda-addon/ Suggestions, comments and bug reports welcome. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

4 5

[PATCH] [Fedora] Include Services section and XCCDF description for selected ntpd's sshd's rules
by Jan Lieskovsky 23 Nov '13

23 Nov '13

Introduce 'Service' Fedora's guide section, and include XCCDF descriptions for selected ntpd and sshd rules. OVAL checks and remediations for them to follow later once confirmed as working. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team

2 1

[PATCH] typo in auditd_data_retention_admin_space_left_action.sh
by Trayer, Jeb D CTR 22 Nov '13

22 Nov '13

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

2 1

[PATCH] typo in accounts_password_warn_age_login_defs.sh
by Trayer, Jeb D CTR 22 Nov '13

22 Nov '13

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

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide November 2013