RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1636392 - ansible remediations put colons into PAM configuration
Summary: ansible remediations put colons into PAM configuration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide
Version: 7.6
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Watson Yuuma Sato
QA Contact: Matus Marhefka
URL:
Whiteboard:
Depends On:
Blocks: 1594286 1648377
TreeView+ depends on / blocked
 
Reported: 2018-10-05 09:51 UTC by amitkuma
Modified: 2019-08-06 13:04 UTC (History)
7 users (show)

Fixed In Version: scap-security-guide-0.1.43-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-06 13:04:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2198 0 None None None 2019-08-06 13:04:20 UTC

Description amitkuma 2018-10-05 09:51:55 UTC
Description of problem:

Customer hitting issue during oscap scan.
# 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]

Customer's System is hardened.

I build oscap from source and placed debug statements.

state_data value in my case is "unix", But customer found it NULL.

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;
                }
....
}


Version-Release number of selected component (if applicable):
# rpm -qa | grep scap
openscap-utils-1.2.16-8.el7_5.x86_64
perl-Pod-Escapes-1.04-292.el7.noarch
openscap-scanner-1.2.16-8.el7_5.x86_64
openscap-containers-1.2.16-8.el7_5.noarch
openscap-1.2.16-8.el7_5.x86_64
scap-workbench-1.1.6-1.el7.x86_64
scap-security-guide-0.1.36-10.el7_5.noarch
# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.5 (Maipo)


How reproducible:
All times in customer env

Steps to Reproduce:
1. Run scan on Customer's RHEL box. Find the issue
2.
3.

Actual results:
oscap scan quits with error

Expected results:
oscap scan should succeed.

Additional info:
sosreport, Additional information at:
https://foobar.gsslab.pnq.redhat.com/02173338/

Comment 2 amitkuma 2018-10-10 06:19:59 UTC
Dear Team,
Customer is looking for an update.

Comment 4 amitkuma 2018-10-11 09:15:10 UTC
||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 = ""

Comment 5 Matus Marhefka 2018-10-12 09:36:01 UTC
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?

Comment 6 Marek Haicman 2018-10-18 19:59:13 UTC
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`

Comment 7 amitkuma 2018-10-19 10:11:07 UTC
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?

Comment 8 Matus Marhefka 2018-10-22 09:37:27 UTC
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.

Comment 9 Marek Haicman 2018-10-22 09:39:29 UTC
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!

Comment 11 amitkuma 2018-10-22 10:17:14 UTC
(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

Comment 12 Marek Haicman 2018-10-22 11:30:55 UTC
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.

Comment 13 amitkuma 2018-10-30 11:19:46 UTC
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?

Comment 14 amitkuma 2018-10-30 11:31:41 UTC
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?

Comment 16 Matus Marhefka 2018-11-02 10:56:22 UTC
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.

Comment 17 amitkuma 2018-11-02 12:07:04 UTC
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!

Comment 18 amitkuma 2018-11-05 09:47:37 UTC
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.

Comment 19 Matus Marhefka 2018-11-06 14:39:51 UTC
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).

Comment 20 amitkuma 2018-11-07 11:38:19 UTC
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 }}

Comment 21 Matus Marhefka 2018-11-07 15:04:31 UTC
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.

Comment 22 amitkuma 2018-11-08 09:34:32 UTC
Dear Matus,
Great, Thanks for narration.
Do revert in case we need any one thing from customer.
Have A Fantastic Day!

Comment 23 amitkuma 2018-12-03 13:29:56 UTC
Dear Matus,
Do we have update on this bugzilla. Customer is looking for it
Thanks

Comment 28 Jan Černý 2019-02-22 13:18:47 UTC
This BZ has been fixed upstream in PR https://github.com/ComplianceAsCode/content/pull/3723

Comment 30 Matus Marhefka 2019-04-30 07:50:22 UTC
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.

Comment 31 amitkuma 2019-05-14 09:28:11 UTC
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

Comment 41 errata-xmlrpc 2019-08-06 13:04:08 UTC
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


Note You need to log in before you can comment on or make changes to this bug.