RFC: Template/lineinfile strategy

[Jonathan Davila]

All,

In tackling the RHEL6 standards dealing with pam.d files, I've come to a fork in the road for implementation and would like to hear other thoughts.

This was briefly discussed between Sam Doran and I here: https://github.com/MindPointGroup/RHEL6-STIG/issues/28

So given the requirements:

• Patching tasks must be idempotent
• At most one standard patched/enforced by task (with very few exceptions)
• There are a few strategies I can think of at the moment:
  

1. lineinfile: this one allows for the greatest flexibility as it would not interfere with pre-existing settings that may already be in set and which aren't RHEL defaults. The down side is that it is painful to use, can become a challenge to read, and achieving proper idempotency can be a bit tricky.
2. template module multiple times: With this tactic we can have a template task hit the same file multiple times with different tasks. The huge down side is that idempotency is lost as a change would be reported every time. 
   
   #%PAM-1.0

   # This file is being managed by Ansible. Please make any desired changes to the template. Any changes made here will be likely overwritten.

   auth        required      pam_env.so

   auth        sufficient    pam_fprintd.so

   {% if login_failures_interval_audit is defined or logon_attempts_audit is defined %}

   auth        required      pam_faillock.so preauth silent deny=3 unlock_time=604800 fail_interval=900

   {% endif %}

   auth        sufficient    pam_unix.so nullok try_first_pass

   {% if login_failures_interval_audit is defined or logon_attempts_audit is defined %}

   auth        [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900

   {% endif %}

   auth        requisite     pam_succeed_if.so uid >= 500 quiet

   auth        required      pam_deny.so

   
   

   {% if login_failures_interval_audit is defined or logon_attempts_audit is defined %}

   account     required      pam_faillock.so

   {% endif %}

   account     required      pam_unix.so

   account     sufficient    pam_localuser.so

   account     sufficient    pam_succeed_if.so uid < 500 quiet

   account     required      pam_permit.so

   
   

   password    requisite     pam_cracklib.so try_first_pass retry=3 type=

   password    sufficient    pam_unix.so {% if pam_pwd_hash_audit is defined %}sha512{% else %}md5{% endif %} shadow nullok try_first_pass use_authtok

   password    required      pam_deny.so

   
   

   session     optional      pam_keyinit.so revoke

   session     required      pam_limits.so

   session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid

   session     required      pam_unix.so
   
   This is a template that takes into account a few different rules. It doesn't take long to realize that idempotency would not be possible. Additionally, this would of course overwrite any settings that may have pre-existed on the user's box. 
3. Template module as the last task: This would solve the idempotency problem of #2 but still override any pre-existing modifications to the pam settings. This would be another exception to the rule of one remediation per task.

That being said, I am now leaning toward going back to lineinfile usage (a change from my opinion on the GH issue). I'm open to other ideas of course. 

[Justin Nemmers]

I think that LineInFile is the right option here, with a modularized option as a close second.  Understanding that creating a pam management module would likely be a longer effort, it seems as though lineinfile is the correct route for now.

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@googlegroups.com.
To post to this group, send email to ansible-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/f01be42b-1c1c-42a4-8afb-01db8f86cb43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Shepherd]

I'm going to throw my vote in for lineinfile for now. I started thinking about ways we could use templates or the assemble module to do this and they are all complicated themselves and ultimately just a work around. The real solution is having ansible modules for pam, auditd rules, etc. i.e. http://docs.ansible.com/ansible/pam_limits_module.html this new module available in v2 would eliminate at least two lineinfile tasks I know of in the STIG.

On Thursday, October 22, 2015 at 8:22:26 AM UTC-4, Justin Nemmers wrote:

I think that LineInFile is the right option here, with a modularized option as a close second.  Understanding that creating a pam management module would likely be a longer effort, it seems as though lineinfile is the correct route for now.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdown+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-lockdown@googlegroups.com.

[Daniel Shepherd]

Hate to reply to myself but a quick follow up.

What about providing two options. Option 1 would be the lineinfile, one standard patched per task method. This would be the default. Option 2 would be to allow users to use a template file and run a single task to apply all the corrections at once. This option could be switched on/off with a conditional which would also skip the lineinfile patch tasks.

Doing it this way would be more useful I think. If users are going to pull the hardening roles down and incorporate them into their own processes they are most likely going to want to be able to customize config files like: sshd_config, the pam files, and auditd.rules. Providing both options would better support that I think and wouldn't be too much trouble.

[Sam Doran]

I spent about two-three hours on this the other night and wanted to ask this same question to the group. I think Jonathan and I are both working through the same refactor. :)

The biggest problem with lineinfile, apart from the inherent inscrutability of regexes, is providing granularity in the tasks when the settings that need to be changed are all on the same lines. Currently there are five lineinfile tasks that cover three finding IDs. The last two of the five tasks overwrite each other, causing both to make changes each time. Trying to debug this the other night drove me nuts. This complexity is, I believe, counter to the spirit of Ansible.

I think the long term fix for this is a module. That abstracts the complexity away into an appropriate place.

Short term, I think an option to deploy a template with appropriate settings OR several lineinfile tasks will work. This can be toggled via a variable.

I could be wrong in my thinking, but most places do not deviate too much from the default configure in this file. It's even overwritten by running authconfig. So installing a full template is not entirely inappropriate if the end user of the roles feels that appropriate for their environment.

If someone knows they have custom settings they would like preserved, then the lineinfile tasks could be used. The current ones need some work so they stop stepping on each other, though. Also, this is a case where multiple findings have to be corrected by a single task, unless we get really crazy with the regexes and try to find/replace a particular key=value pair on one line. I did this years ago with sed. Maybe I can look at for some inspiration.

[Jonathan Davila]

Yeah the toggle between the two options is cool BUT!....after looking at the feedback and lots of self debating, I'm going to go ahead and create a pam module, this will of course delay the next release a bit, but I think both lineinfile and template are ultimately accumulating technical debt. Making the module now will likely payoff nicely and relatively soon. 

Definitely let me know if there are any objections.

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@googlegroups.com.
To post to this group, send email to ansible-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/98d1b69c-4f4d-4873-89b1-ab308d30cfdd%40googlegroups.com.

[Brian Coca]

Just FYI, we have an actual patch module that might work exactly as you want, can make changed idempotently and still respect other changes not in the same section.

[Jonathan Davila]

That's not a bad idea, though my only gripe would be that it may appear slightly less readable. I'll tinker for a bit and report back here. I definitely still want to crank out a pam module.

On Fri, Oct 23, 2015 at 9:37 AM, Brian Coca <bc...@ansible.com> wrote:

Just FYI, we have an actual patch module that might work exactly as you want, can make changed idempotently and still respect other changes not in the same section.

--

You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@googlegroups.com.
To post to this group, send email to ansible-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-lockdown/8eeac17e-30f3-4776-a2e0-9d77357a793a%40googlegroups.com.

[Jonathan Davila]

And the first iteration of the PAM module is complete. The PR can be seen here https://github.com/ansible/ansible-modules-core/pull/2384, until it get merged into the upstream and put into a stable release, it will live in the library directory of any role which needs PAM settings to be modified.

For those that are able, please give it a test and see if you find something I missed.

Thanks!

On Friday, October 23, 2015 at 10:27:19 AM UTC-4, Jonathan Davila wrote:

That's not a bad idea, though my only gripe would be that it may appear slightly less readable. I'll tinker for a bit and report back here. I definitely still want to crank out a pam module.

On Fri, Oct 23, 2015 at 9:37 AM, Brian Coca <bc...@ansible.com> wrote:

Just FYI, we have an actual patch module that might work exactly as you want, can make changed idempotently and still respect other changes not in the same section.

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdown+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-lockdown@googlegroups.com.