Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure SSH X11 forwarding is disabled task only fixes first occurence #380

Closed
fgierlinger opened this issue Jun 1, 2024 · 4 comments
Closed
Assignees
Labels
bug Something isn't working

Comments

@fgierlinger
Copy link

fgierlinger commented Jun 1, 2024

Describe the Issue
The hardening guide requires to disable X11 forwarding unless there is an operational requirement. The task 5.2.12 accomplishes this with the lineinfile module. lineinfile only replaces the first occurrence of X11Forwarding. But X11Forwarding can appear multiple times in the ssh config. Once as a general option and once as an user option.

Expected Behavior
All occurences of X11Forwarding should be disabled by the playbook.

Actual Behavior
Only the first occurence of X11Forwarding is disabled by the playbook.

Control(s) Affected
v8 4.8 Uninstall or Disable Unnecessary Services on Enterprise Assets and Software
v7 9.2 Ensure Only Approved Ports, Protocols and Services Are Running

Environment (please complete the following information):

  • branch being used: tag 2.6.0 (bc4cdf8)
  • Ansible Version: 4.0.0 (core 2.11.12)
  • Host Python Version: Python 3.11.5
  • Ansible Server Python Version: Python 3.6.8
  • Additional Details:

Additional Notes
MVE of sshd_config

X11Forwarding yes

Match User anoncvs
    X11Forwarding yes

Possible Solution
Use replace instead of lineinfile module. As there is a disabled match user block in the default sshd_config, a regex match on lines starting with # cannot be used as it would enable the indented line in the block. This could cause a config error. Therefore, only lines that are already enabled are checked. The default value for X11Forwarding on RHEL8 is no.

- name: "5.2.12 | PATCH | Ensure SSH X11 forwarding is disabled"
  ansible.builtin.replace:
      path: /etc/ssh/sshd_config
      regexp: '^(\s*)X11Forwarding.*'
      replace: '\1X11Forwarding no'
  when:
      - rhel8cis_rule_5_2_12
  tags:
      - level2-server
      - level1-workstation
      - automated
      - patch
      - ssh
      - rule_5.2.12
@fgierlinger fgierlinger added the bug Something isn't working label Jun 1, 2024
uk-bolly added a commit that referenced this issue Jun 18, 2024
Signed-off-by: Mark Bolwell <mark.bollyuk@gmail.com>
@uk-bolly uk-bolly self-assigned this Jun 18, 2024
@uk-bolly
Copy link
Member

uk-bolly commented Jun 18, 2024

hi @fgierlinger

Thank you for this issue, i can see you are referring to the older benchmark version 2.0.0.
CIS v3.0 was released a while ago.
I have therefore added these fixes to a new locked branch called benchamrk_v2.0.0.

I hope this helps.

Many thanks

uk-bolly

@fgierlinger
Copy link
Author

@uk-bolly The CIS v3.0 was released a while ago, but there has been no release of the RHEL8-CIS for CIS v3.0. The last release is the tag 2.6.0 (commit bc4cdf8).

Is there a chance to release a 2.0.1 / 2.1.0 for the changes on the benchmark_v2.0.0 branch?

But the issue persists in the devel branch. DisableForwarding can also be part of a Match block and therefore occur multiple times in a sshd_config. Using ansible.builtin.replace instead of ansible.builtin.lineinfile is advices.

- name: "4.2.8 | PATCH | Ensure sshd DisableForwarding is enabled"
ansible.builtin.lineinfile:
path: /etc/ssh/sshd_config
regexp: "^#DisableForwarding|^DisableForwarding"
line: 'DisableForwarding yes'

@uk-bolly
Copy link
Member

hi @fgierlinger

Thank you for the feedback, our process is a devel to main normally after a couple of weeks to confirm no issues.
As i noticed you stated you were using a specific tag i have created the fix for that release of the benchmark as we can't easily add this into devel. Its why we have the long period of time between devel and main releases to hopefully pick these kind of things up.

I am already working on the next push to devel for these fixes before we release to main for the v3.0.0 release, which is likely to be either the end of this week or next week.

I hope that makes sense?

many thanks again for your feedback and time.

uk-bolly

@uk-bolly
Copy link
Member

hi @fgierlinger

Thank you again for your time regarding this issue. You should find that this fix was merged into devel and is now in the main branch. I will close this issue, please feel free to reopen if this is not resolved as expected.

Many thanks

uk-bolly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants