Bug 1636392
Summary: | ansible remediations put colons into PAM configuration | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | amitkuma |
Component: | scap-security-guide | Assignee: | Watson Yuuma Sato <wsato> |
Status: | CLOSED ERRATA | QA Contact: | Matus Marhefka <mmarhefk> |
Severity: | urgent | Docs Contact: | |
Priority: | urgent | ||
Version: | 7.6 | CC: | bjarolim, cww, jcerny, matyc, mhaicman, openscap-maint, sshaurya |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | scap-security-guide-0.1.43-1.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-08-06 13:04:08 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1594286, 1648377 |
Description
amitkuma
2018-10-05 09:51:55 UTC
Dear Team, Customer is looking for an update. ||2. Can we conclude from where 'state_data' is taking value 'unix'. If in some ||configuration file, Can we update the variable and make oscap work? state_data = "" Hello and sorry for late response. Unfortunately, openscap has no capability to skip remote filesystems. Moreover there is the issue with draining memory on huge filesystems. This is caused by memory management in openscap which stores all results in memory until scan finishes. The result is that if you are scanning huge filesystems with big amount of files you need to disable the following rules (which are checking files on the whole filesystem) to overcome the problem: * Ensure No World-Writable Files Exist id: xccdf_org.ssgproject.content_rule_file_permissions_unauthorized_world_writable * Ensure All Files Are Owned by a User id: xccdf_org.ssgproject.content_rule_no_files_unowned_by_user * Ensure All Files Are Owned by a Group id: xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned * Ensure All SUID Executables Are Authorized id: xccdf_org.ssgproject.content_rule_file_permissions_unauthorized_suid * Ensure All World-Writable Directories Are Owned by a System Account id: xccdf_org.ssgproject.content_rule_dir_perms_world_writable_system_owned You can create a tailoring file which will disable these rules (you can use SCAP Workbench to do so). For more details please see: https://www.open-scap.org/security-policies/customization/ https://www.open-scap.org/resources/documentation/customizing-scap-security-guide-for-your-use-case/ In the https://bugzilla.redhat.com/show_bug.cgi?id=1598166#c9 you can find a possible solution how to skip remote filesystems by modifying OVAL content from scap-security-guide. Considering the conversion of the string to an integer error, will you be able to provide a full backtrace from gdb when this happens? As Matus explains, I would definitely suggest to first run scan with reduced subset of rules, if the issue persists or not. You can utilize tailoring for cases of limited subset, or --rule command if you want to check only one rule. The best case (for debugging) is if the bug triggers even in case of single rule being evaluated. --rule needs full ID, i.e. something like `xccdf_org.ssgproject.content_rule_service_zebra_disabled` Hey Marek Haicman, a. I think at this point, Customer is not sure on which rule check oscap is hitting "Conversion Error". So don't you think it would be a huge time-consuming activity to test each rule which fails or create tailoring file? b. will you be able to provide a full backtrace from gdb when this happens? I found this article. https://access.redhat.com/solutions/274793 But I don't think application oscap is dumping a core. It just logs "Conversion ...." and returns. oval_result_t oval_str_cmp_str(char *state_data, oval_datatype_t state_data_type, const char *sys_data, oval_operation_t operation) { if (!cstr_to_intmax(state_data, &state_val)) { oscap_seterr(OSCAP_EFAMILY_OVAL, "Conversion of the string \"%s\" to an integer (%u bits) failed: %s", state_data, sizeof(intmax_t)*8, strerror(errno)); return OVAL_RESULT_ERROR; } .... } How we can generate backtrace without core dump file? You can generate a backtrace by adding a breakpoint with certain condition (in this case state_data == ""): (gdb) b FILE.c:LINE_NUMBER if $_streq(state_data, "") when gdb reaches the breakpoint just print the backtrace using "thread apply all bt" command. Hello Amit, I believe it would help with debugging, to know, whether it is any specific rule, or only big enough rule set (or possibly rules spanning whole file system, which Matus named. It should be fairly quick to check. To run every rule separately in automated way: ``` # unfortunately we do not have simple tool to list rules of given profile oscap xccdf eval --profile stig-rhel7-disa --progress /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml > rule_ids cat rule_ids | sed 's/:.*//g' | while read ID;do oscap xccdf eval --profile standard --progress --rule $ID /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml;done ``` Hope it helps! (In reply to Marek Haicman from comment #9) > Hello Amit, > I believe it would help with debugging, to know, whether it is any specific > rule, or only big enough rule set (or possibly rules spanning whole file > system, which Matus named. It should be fairly quick to check. To run every > rule separately in automated way: > > ``` > # unfortunately we do not have simple tool to list rules of given profile > oscap xccdf eval --profile stig-rhel7-disa --progress > /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml > rule_ids > > cat rule_ids | sed 's/:.*//g' | while read ID;do oscap xccdf eval --profile > standard --progress --rule $ID > /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml;done > ``` > > Hope it helps! Hey Matus, As I understood this script does 2 things: a. Add rule Ids to file b. Scan system for each rule by reading IDs from start. And hopefully with above 2 command, oscap scan will stop after the rule that's causing state_data="". I would be asking customer to run these 2 commands and provide us the output. Please correct me if i misunderstood. Thanks Hi Amit, first script creates list of rule IDs. Second iterates over the list and runs every rule separately. There is no autodetection of failure though. Checking the output visually should be enough to identify which rules trigger that. Dear Team, Customer conveyed This is the "faulty" ID: ========= xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval ============ xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval:fail OpenSCAP Error: Conversion of the string "" to an integer (64 bits) failed: Invalid argument [oval_cmp.c:111] Conversion of the string "" to an integer (64 bits) failed: Invalid argument [oval_cmp.c:111] And this is the script I've been using: cat ids | while read ID do echo "========= ${ID} ============" oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig-rhel7-disa --progress --rule $ID /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml done Next Steps: 1. Can we ask customer to pull out pam_faillock.so from auth, account sections and run the scan(if he agrees to do)? 2. Also, inspect any program is not reshaping the pam configuration? Or anything additional/auxiliary? Sorry, I misconceived I think this rule changes the pam configuration itself so while the rule is selected=true and the scan is in process we cannot remove the pam_faillock.so lines from auth, account section. So, 'quick fix' can be to procreate a tailoring file where this rule is pointedly set to false? Hello Amit, thank you for the PAM files. I have found out that the issue is in our content regular expressions which do not expect that PAM configuration files can contain double quote characters (I am not sure if double quotes are allowed in PAM config files). Anyway, to fix this issue please remove double quotes (") in /etc/pam.d/password-auth-ac: # BEGIN MANAGED BY ANSIBLE-HARDENING # V-71945 - If three unsuccessful logon attempts within 15 minutes occur the associated account must be locked. auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=604800 auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=604800 # END MANAGED BY ANSIBLE-HARDENING I will investigate if double quotes are actually a valid character in PAM configuration and if they are we will update our code and content. Hey Matus Marhefka, That's Admirable. I funneled this instruction to the customer to clear away Double quotes from PAM config. Let customer evaluate this, I will revert with Customer's statement. Have A lucky Day! Dear Matus Marhefka, Customer validated that after abolishing "" from pam.d/ oscap does not quits. Also, as per # man pam_faillock There is no chronicle of encompassing options with "", Also this is not a prevalent practice. I am uncertain at this point why "ANSIBLE-HARDENING" added double quotes to etc/pam.d/password-auth-ac which is not required. Hello Amit, I have found out that double quotes are not valid in pam config files. Please follow with the customer on the "ANSIBLE-HARDENING" part in the pam config file as I am not sure what was used to produce this configuration (there is no Ansible fix for this rule in scap-security-guide right now). Dear Matus, Customer is generating ansible(*.yml) playbook using: # /usr/bin/oscap xccdf generate fix --fix-type ansible \ --profile xccdf_org.ssgproject.content_profile_stig-rhel7-disa \ --output stig-rhel7-role.yml \ /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml Then remediation role is applied using: # yum install ansible -y # ansible-playbook -i "10.74.253.140," /root/stig-rhel7-role.yml --ask-pass Ansible playbooks are written using the YAML Ain’t Markup Language (YAML) language. It looks space {} is treated as "" by playbook. # stig-rhel7-role.yml - name: set auth pam_faillock before pam_unix.so pamd: name: system-auth type: auth control: sufficient module_path: pam_unix.so new_type: auth new_control: required new_module_path: pam_faillock.so module_arguments: 'preauth silent even_deny_root deny={{ var_accounts_passwords_pam_faillock_deny }} Hello Amit, you are right, the issue is in our ansible playbook. I got confused because originally we have found out that the xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval caused oscap to exit with the error but the rule does not have ansible remediation. The remediation causing this issue is actually from different rule: xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny_root we need to fix this in our content and also make sure that other PAM rules do not put double quotes into config files. Dear Matus, Great, Thanks for narration. Do revert in case we need any one thing from customer. Have A Fantastic Day! Dear Matus, Do we have update on this bugzilla. Customer is looking for it Thanks This BZ has been fixed upstream in PR https://github.com/ComplianceAsCode/content/pull/3723 Verified for scap-security-guide-0.1.43-5.el7 by running upstream test scanarios for both rules accounts_passwords_pam_faillock_deny_root and accounts_passwords_pam_faillock_deny: INFO - xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny_root INFO - Script missing-default-die-pam_faillock.fail.sh using profile xccdf_org.ssgproject.content_profile_ospp OK INFO - Script missing-required-pam_faillock.fail.sh using profile xccdf_org.ssgproject.content_profile_ospp OK INFO - Script both-correct.pass.sh using profile xccdf_org.ssgproject.content_profile_ospp OK INFO - xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny INFO - Script skip_correctly.pass.sh using profile xccdf_org.ssgproject.content_profile_C2S OK INFO - Script default_die_pam_unix.fail.sh using profile xccdf_org.ssgproject.content_profile_C2S OK INFO - Script disablefaillock_authconfig.fail.sh using profile xccdf_org.ssgproject.content_profile_C2S OK INFO - Script skip_correctly_short.pass.sh using profile xccdf_org.ssgproject.content_profile_C2S OK ERROR - Script skip_longer_comment.fail.sh using profile xccdf_org.ssgproject.content_profile_C2S found issue: ERROR - Rule evaluation resulted in pass, instead of expected fail during initial stage ERROR - The initial scan failed for rule 'xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny'. INFO - Script remediable_sssd_authconfig.fail.sh using profile xccdf_org.ssgproject.content_profile_C2S OK INFO - Script skip_longer.fail.sh using profile xccdf_org.ssgproject.content_profile_C2S OK INFO - Script config_without_skip.pass.sh using profile xccdf_org.ssgproject.content_profile_C2S OK The issue reported by the skip_longer_comment.fail.sh is still not fixed and it is tracked in the bz#1549671 Also verified manually that after applying Ansible PAM remediations on the system there are no colons in the PAM configuration. Dear Matus, 1. So Does replacement of ':' by '=' in PAM module_arguments will fix customer's Issue? ----------Customer's Issue------------- # oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig-rhel7-disa --results-arf test.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml ........ OpenSCAP Error: Conversion of the string "" to an integer (64 bits) failed: Invalid argument [oval_cmp.c:111] Conversion of the string "" to an integer (64 bits) failed: Invalid argument [oval_cmp.c:111] ---------------------------------------- If so, Can you please build a test build for customer to test from upstream. 2. Will error generated by skip_longer_comment.fail.sh will hinder the oscap scan, since its postponded to 7.8? ERROR - Script skip_longer.fail.sh using profile xccdf_org.ssgproject.content_profile_C2S found issue: ERROR - Scan has exited with return code 0, instead of expected 2 during stage initial Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2198 |