Code Monkey home page Code Monkey logo

Comments (18)

bbaassssiiee avatar bbaassssiiee commented on May 27, 2024 2

I like thiis PR. More room for corporate policies (with exceptions) and a more tractable way to run the role.

from rhel7-cis.

shepdelacreme avatar shepdelacreme commented on May 27, 2024 1

@thisdougb That makes sense to me. Thanks!

from rhel7-cis.

thisdougb avatar thisdougb commented on May 27, 2024 1

OK, a quick and dirty Python script to convert the original section files into having when: clauses - https://gist.github.com/thisdougb/927c1ccf8988fb28896f7fef5a236081

I'm converting two levels (x.x.x and x.x.x.x), handling existing when: lines in the old format but not when: as lists (Ansible warns of these, so quicker to manually fix if it happens).

produces tasks looking like this:


- name: "SCORED | 1.1.8  | PATCH | Ensure nodev option set on /var/tmp partition\n
         SCORED | 1.1.9  | PATCH | Ensure nosuid option set on /var/tmp partition\n
         SCORED | 1.1.10 | PATCH | Ensure noexec option set on /var/tmp partition"
  mount:
      name: /var/tmp
      src: "{{ rhel7cis_vartmp['source'] }}"
      state: mounted
      fstype: "{{ rhel7cis_vartmp['fstype'] }}"
      opts: "{{ rhel7cis_vartmp['opts'] }}"
  when:
      - rhel7cis_rule_1_1_8
      - rhel7cis_rule_1_1_9
      - rhel7cis_rule_1_1_10
      - rhel7cis_vartmp['enabled'] == 'yes'
  tags:
      - level1
      - scored
      - patch
      - rule_1.1.8
      - rule_1.1.9
      - rule_1.1.10

and spits out the vars for default/main.yml:

rhel7cis_rule_1_1_1_2: true
rhel7cis_rule_1_1_1_3: true
rhel7cis_rule_1_1_1_4: true
rhel7cis_rule_1_1_1_5: true
rhel7cis_rule_1_1_1_6: true
rhel7cis_rule_1_1_1_7: true
rhel7cis_rule_1_1_1_8: true
rhel7cis_rule_1_1_2: true
rhel7cis_rule_1_1_3: true
rhel7cis_rule_1_1_4: true
rhel7cis_rule_1_1_5: true
rhel7cis_rule_1_1_6: true
rhel7cis_rule_1_1_7: true
rhel7cis_rule_1_1_8: true
rhel7cis_rule_1_1_9: true
rhel7cis_rule_1_1_10: true
rhel7cis_rule_1_1_11: true
rhel7cis_rule_1_1_12: true
rhel7cis_rule_1_1_13: true
rhel7cis_rule_1_1_14: true
rhel7cis_rule_1_1_15: true
rhel7cis_rule_1_1_16: true
rhel7cis_rule_1_1_17: true
rhel7cis_rule_1_1_18: true
rhel7cis_rule_1_1_19: true
rhel7cis_rule_1_1_20: true
rhel7cis_rule_1_1_21: true
rhel7cis_rule_1_1_22: true
rhel7cis_rule_1_2_1: true
rhel7cis_rule_1_2_2: true
rhel7cis_rule_1_2_3: true
rhel7cis_rule_1_2_4: true
rhel7cis_rule_1_2_5: true
rhel7cis_rule_1_3_1: true
rhel7cis_rule_1_3_2: true
rhel7cis_rule_1_4_1: true
rhel7cis_rule_1_4_2: true
rhel7cis_rule_1_4_3: true
rhel7cis_rule_1_5_1: true
rhel7cis_rule_1_5_2: true
rhel7cis_rule_1_5_3: true
rhel7cis_rule_1_5_4: true
rhel7cis_rule_1_6_1_1: true
rhel7cis_rule_1_6_1_2: true
rhel7cis_rule_1_6_1_3: true
rhel7cis_rule_1_6_1_4: true
rhel7cis_rule_1_6_1_5: true
rhel7cis_rule_1_6_2: true
rhel7cis_rule_1_7_1_1: true
rhel7cis_rule_1_7_1_2: true
rhel7cis_rule_1_7_1_3: true
rhel7cis_rule_1_7_1_4: true
rhel7cis_rule_1_7_1_5: true
rhel7cis_rule_1_7_1_6: true
rhel7cis_rule_1_7_2: true

setting:

# roles/RHEL7-CIS/defaults/main.yml
rhel7cis_rule_1_1_1_1: false

produces (snipped):

TASK [RHEL7-CIS : PRELIM | Check for rhnsd service] **************************************************************************************************
ok: [neo4j]

TASK [RHEL7-CIS : SCORED | 1.1.1.1 | PATCH | Ensure mounting of cramfs filesystems is disabled] ******************************************************
skipping: [neo4j]

TASK [RHEL7-CIS : SCORED | 1.1.1.2 | PATCH | Ensure mounting of freevxfs filesystems is disabled] ****************************************************
ok: [neo4j]

from rhel7-cis.

shepdelacreme avatar shepdelacreme commented on May 27, 2024 1

I just merged your first PR in...I'll be sure to review/merge as these come in so you can keep making progress.

Thanks!

from rhel7-cis.

shepdelacreme avatar shepdelacreme commented on May 27, 2024 1

@thisdougb Just merged in the last one! Thanks for the work on this.

from rhel7-cis.

shepdelacreme avatar shepdelacreme commented on May 27, 2024

@joaogbcravo Let me pose the question to the ansible-lockdown mailing list and see what the consensus is as far as adding this sort of thing to the role spec. I don't disagree that it would be easier to pick out specific tasks. Using tags to do this leaves a lot to be desired.

from rhel7-cis.

shepdelacreme avatar shepdelacreme commented on May 27, 2024

@joaogbcravo We've come to agreement on this. If you'd like to submit a PR with these changes we welcome it. We are going to start implementing this on all the roles we've released over the coming months.

One thing to note. The variable names cannot contain "dots" and will need to be as follows:
rhel7cis_rule_1_1_1_1
rhel7cis_rule_1_2

Thanks!

from rhel7-cis.

joaogbcravo avatar joaogbcravo commented on May 27, 2024

Hey! Thanks a lot for starting doing this!

I'm a little without time to do this changes but as soon as possible I will help too!

from rhel7-cis.

thisdougb avatar thisdougb commented on May 27, 2024

I have some time (and need) to do this. I'd suggest maybe I do one full section per PR, if that's ok?

from rhel7-cis.

thisdougb avatar thisdougb commented on May 27, 2024

cool, @shepdelacreme. do you have a link to the discussion on the ansible lockdown list that I can read through, to avoid asking already resolved questions?

because there are a large number of rules (228?), my thinking is that selectively turning off rules will result in smaller, more readable vars files. and turning off rules really should be the exception, so something like:

# roles/RHEL7-CIS/defaults/main.yml
# Section 1 rules
rhel7cis_rule_1_1_1_1: false

and the code change to each task would be:

# roles/RHEL7-CIS/tasks/section1.yml
- name: "SCORED | 1.1.1.1 | PATCH | Ensure mounting of cramfs filesystems is disabled"
  lineinfile:
      dest: /etc/modprobe.d/CIS.conf
      regexp: "^(#)?install cramfs(\\s|$)"
      line: "install cramfs /bin/true"
      create: yes
  when:
      rhel7cis_rule_1_1_1_1 | default(true)
  tags:
      - level1
      - scored
      - patch
      - rule_1.1.1.1
      - cramfs

A point to note, which may not be obvious to some, the variables override the tags. So the above variable settings prevent the rule running even if you '--tags rule_1.1.1.1'.

from rhel7-cis.

erpadmin avatar erpadmin commented on May 27, 2024

this has me thinking. groups of servers having different tweaks.

is there a way to dynamically set defaults/main.yml based on group name in ansible hosts?

example:
2 different groups
[internal_hosts]
[dmz_hosts]

2 different files
main_int.yml
main_dm.yml

then somehow be able to use either as the main.yml settings according to the group name (or some other method)

from rhel7-cis.

shepdelacreme avatar shepdelacreme commented on May 27, 2024

@thisdougb Here is the discussion on the Google group regarding this: https://groups.google.com/forum/#!topic/ansible-lockdown/rsfyEXWvZJg

Also you can look at how this same setup was implemented in the RHEL7-STIG role: https://github.com/MindPointGroup/RHEL7-STIG

The var value in defaults/main.yml should be set to true unless there is a good reason to disable it. i.e. applying the setting by default is dangerous or has the potential to cause serious harm to a system.

In the tasks it should be something like:

  when:
    - rhel7cis_rule_1_1_1_1

And all rules should have a default value set in defaults/main.yml so don't need the | default(true)

Thanks!

from rhel7-cis.

shepdelacreme avatar shepdelacreme commented on May 27, 2024

@erpadmin This setup makes it much easier to control applying the role to different types of hosts since you can take all the rule variables and stick them into inventory vars files.

i.e. in your inventory

[internal_hosts]
int-host-1

[external_hosts]
ext-host-1

Then you would be able to do this:

/
  apply_stig.yml
  inventory/
    hosts    <- inventory file
  group_vars/
    all.yml    <- vars file that applies to all hosts. Any CIS vars that are common to all hosts can go here.
    internal_hosts.yml    <- any vars for the CIS role that need to be overridden for internal hosts
    external_hosts.yml  <- any vars for the CIS role that need to be overridden for external hosts

from rhel7-cis.

erpadmin avatar erpadmin commented on May 27, 2024

makes sense, thanks for the feedback

from rhel7-cis.

thisdougb avatar thisdougb commented on May 27, 2024

@shepdelacreme, yes you can still do exactly the same thing even if you put the default value on the when: clause, but the list of vars will be far fewer and easily readable. defaults/main.yml has role defined exceptions, groups_vars/all.yml has site wide exceptions, internal_hosts.yml has internal hosts exceptions, etc.

I get what you're saying, but I think having all those vars listed in one file makes for poor readability and a higher chance of making mistakes. Every task conditional must be (successfully) mapped to an entry in defaults/main.yml, rather than simply the task conditional itself. For example in https://github.com/MindPointGroup/RHEL7-STIG/blob/devel/defaults/main.yml, I think this would just be much neater (only specifying exceptions):

# This check breaks with redhat.com repos as they do not sign repo data
rhel_07_020070: false
# Not an automated task
rhel_07_020250: false
# Potential for locking out users
rhel_07_010260: false
# Send AIDE reports as mail notifications - Disabled by default as this is a non-ideal way to do notifications
rhel_07_020040: false

Anyway, I'll be writing some quick Perl to generate the defaults/main.yml and when: clauses, so it's no more work either way. I just think that the fewer characters people (admins, etc) have to read during their daily work the better.

from rhel7-cis.

thisdougb avatar thisdougb commented on May 27, 2024

I'm doing some work involving this role, so will be testing over the next few days. But if there's agreement then I can generate the new section files, and corresponding defaults/main.yml updates, and submit them as PRs in the next week or so.

from rhel7-cis.

shepdelacreme avatar shepdelacreme commented on May 27, 2024

@thisdougb Looks good to me! I'll keep an eye out for your PRs.

from rhel7-cis.

thisdougb avatar thisdougb commented on May 27, 2024

it occurred to me that I'll need to wait for each PR to be merged before creating the next one, otherwise there'll be messing about resolving the conflict with defaults/main.yml. So we'll need to do this in serial style :) No rush at all from my side, but just so you know that the next PR will only be done once I've updated my fork with the current PR merge.

from rhel7-cis.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.