Azure image requires UDF mounting support. about rhel7-cis HOT 8 CLOSED

This is my workaround.

With an ansible-galaxy requirements.yaml of:

- src: https://github.com/MindPointGroup/RHEL7-CIS.git

You will need a top level playbook.yaml of:

---
- hosts: all
  roles:
    - role: RHEL7-CIS
      vars:
        - rhel7cis_rule_1_1_1_7: false # Required so the azure waagent can mount init scripts

Related to: Azure/WALinuxAgent#246

from rhel7-cis.

Hmm...well you could go through and disable all the rules in section 1 and then enable them 1 at a time to see where it fails. This could be a bit tedious though. You could probably start with disabling things that affect the boot loader/etc.

i.e.
Grub and bootloader password rules
rhel7cis_rule_1_4_1: false
rhel7cis_rule_1_4_2: false

Grub selinux and general selinux rules
rhel7cis_rule_1_6_1_1: false
rhel7cis_rule_1_6_1_2: false
rhel7cis_rule_1_6_1_3: false

Also let us know what you find! If I have time I'll test out making an image on Azure as well.

from rhel7-cis.

Yeah, disabling one by one was my next option - but was hoping for a jump start! I did do a skip on selinux, but that didn't help (maybe they are all level 2 anyway).

I'll try the suggestion above and report back.

from rhel7-cis.

My tests indicate that the following stops the machine from being deployed in Azure:

"SCORED | 1.1.1.7 | PATCH | Ensure mounting of udf filesystems is disabled"

from rhel7-cis.

@hakabo Thanks for tracking this down! I found this in the Azure docs. https://docs.microsoft.com/en-us/azure/virtual-machines/linux/agent-user-guide

Per that page the Azure Linux Agent requires "Kernel support for mounting UDF filesystems."

We will make a note of it in the README.

from rhel7-cis.

I'm changing this to docs from bug since it really just needs to be noted in the docs so people know to disable this rule in Azure.

from rhel7-cis.

This requirement (UDF must be enabled for initial provisioning of a VM) applies whether waagent or cloud-init is used to handle provisioning. The requirement actually comes from the Azure control plane which constructs the UDF image with unique content for each VM it creates. The in-VM provisioning agents capture the content, redact any secrets (e.g. passwords), and persist the redacted content in /var/lib/waagent/ovf-env.xml.

from rhel7-cis.

Hello,
I wanted to reach out and let you know that this issue is being closed. We have re-worked the role and want to start with a fresh issues list with this latest version. There was a post in the Ansible-Lockdown google group (https://groups.google.com/g/ansible-lockdown) with the details of the changes that are coming. Please checkout the thread titled RHEL 7 CIS and STIG Changes for all of the details, I also have the message pasted at below.
Please as you use the latest version and open issue tickets as you find them, it is the best way for us to improve the role for everyone. Thank you for being part of the community and providing awareness of problems or advice on improvement. Reporting is a huge part of improving this project.

Hello,
Thank you to everyone in the Ansible-Lockdown community who has contributed to RHEL7 STIG/CIS. Our team at MindPoint Group has been working with the entirety of the Ansible-Lockdown project, and we have some significant updates for both RHEL 7 STIG and CIS. With these updates, some larger changes have been made. I have these changes/updates outlined below.
Testing:

1. CI/CD - We have implemented some automated testing pipelines to test pull requests into the devel and main branches. With the current workflow, the community will PR into the devel branch (never the main branch) for review by the administrators. When your PR is created, the first check will remain the DCO check. The second check is a functional testing pipeline that will automatically perform a functional test of the branch the PR is initiated from. Once both tests pass, someone from the Administrator Team will review the changes and merge them into the devel branch. From there, an additional review is completed before the devel branch is merged into the main branch. Only the Admin Team will perform PRs/merges into the main branch. There is also an automated pipeline for PRs from devel to main. Please do not edit the .github/workflows files since those are used as part of the pipeline.
2. Compliance Checking – MindPoint Group has been working to create our own compliance audit scan tool. The tool uses a goss framework executable to run custom checks that we have created. The goal is to provide a more thorough check for control compliance and decrease the number of false positives/negatives. For example, it will check the configuration file related to the control and as well as checking if that configuration is active. With a smarter scan, we can hopefully identify attempts to trick scanners as well (for example stacking a parameter in a config file where the first instance is enabled and second disabled. Most audit tools search for the first instance but the application might look for the last instance of the parameter, thus making the scanning tool think it's enabled). In testing, we have found that our audit scan runs significantly faster than other audit tools, reducing audit times. Our audit tool and profiles will have their own repositories in the Ansible-Lockdown org, but within the remediation role there will be an integrated way to incorporate the audit. Keep an eye out for the audit tools as they are released. We plan on developing a goss audit profile for each current remediation role. Going forward, we plan to release a remediation role and goss audit tool profile simultaneously.
   Role Updates:
3. RHEL 7 STIG/CIS – We have re-written much of the RHEL 7 STIG and CIS roles to increase clarity and readability and address some functionality items. We performed these updates while creating our goss testing framework for each of these roles. We plan on pushing our update to the devel and main branches. We will move the current devel and master branches to a devel_stable_ and master_stable_ branch in the respective repositories. Accordingly, community members who rely on the current version can still use that version going forward; this process will not remove what is currently there. The latest versions of the roles have also been updated to comply with the latest benchmarks.
4. Role Architecture – All roles will change with regard to the structure in the tasks folder. Taking CIS as an example, there will be a folder per section and yaml files for each sub-section. For example control 1.2.1 in CIS will be located in RHEL7-CIS/tasks/section_1/cis_1.2.x.yml. The cis_1.2.x.yml file will contain all controls related to section 1.2.x. This will hopefully make updates to roles a bit easier with less risk. This matches the architecture of our audit tool, creating consistency across remediation and audit platforms. The end goal is to repeat this architecture (the best we can) on STIG roles, but we are starting with CIS.
5. Existing PRs and Issues – With all of these changes comes the task of cleaning up existing PR’s and issues. Our plan is to close all of the existing PR’s and issues because of the re-work. Our team is growing and should be able to stay on top of the new issues and PRs as they come in.
   Again, I would like to thank the community for your involvement in this project. The input and work from the community has contributed significantly to the success of this project. Please keep an eye out for these changes, which will be rolling out in the coming weeks.

from rhel7-cis.