16:00:34 <defionscode> #startmeeting Ansible Lockdown WG
16:00:34 <zodbot> Meeting started Thu Mar  7 16:00:34 2019 UTC.
16:00:34 <zodbot> This meeting is logged and archived in a public location.
16:00:34 <zodbot> The chair is defionscode. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:34 <zodbot> The meeting name has been set to 'ansible_lockdown_wg'
16:00:51 <defionscode> Who is here?
16:01:27 <shepdelacreme> me!
16:01:48 <defionscode> @cyberpear @cyberpear_ ?
16:02:45 <defionscode> I wish IRC had a @here function
16:02:59 * cyberpear_ waves
16:03:12 <defionscode> So right now I'm looking over cyberpear_ PRs
16:03:24 <cyberpear_> awesome!
16:03:31 <defionscode> are there any particular topics ya'll want to discuss?
16:03:50 * defionscode proposes refactoring everything to c++
16:03:53 * defionscode hides
16:04:02 <cyberpear_> lol
16:04:16 <shepdelacreme> haha
16:04:43 <shepdelacreme> I was going to suggest we just review PRs today since there are a lot outstanding
16:05:33 <cyberpear_> is there a way to change an ansible config setting on a per-role basis?
16:05:47 <defionscode> afaik no
16:06:06 <shepdelacreme> @cyberpear_ for https://github.com/MindPointGroup/RHEL7-STIG/pull/223...I think there is a related issue about using a non-static grub salt
16:06:07 <cyberpear_> otherwise, we're going to get this spurrious deprecation warning for every task for 2 releases: https://github.com/ansible/ansible/issues/53428
16:06:09 <defionscode> maybe, but I've never tried to set `environment` to ansible config env var options
16:06:54 <cyberpear_> but if we opt-in to the new functionality, the warning goes away
16:07:36 <cyberpear_> yes, I opened the non-static salt issue when I was coding up #223
16:08:01 <cyberpear_> I didn't have time at that moment to troubleshoot why my trivial fix didn't work for it
16:08:11 <shepdelacreme> ok
16:08:13 <defionscode> I'm ok with deprecation warnings personally, as long as we're staying true to not supporting EOLd version
16:08:14 <cyberpear_> so I just left the static salt part as-is
16:08:44 <cyberpear_> IMO the deprecation warning does not affect us because we aren't using the functionality that's being deprecated
16:09:02 <defionscode> i agree
16:09:02 <cyberpear_> currently, the string "false" is interpreted to mean a false boolean on a when: statement
16:09:13 <cyberpear_> but we use native bools everywhere
16:09:41 <cyberpear_> I opened that ansible bug  because my screen was filled w/ purple on running the role on 2.8
16:11:30 <shepdelacreme> What happens if we set CONDITIONAL_BARE_VARS to False...there is no effect on how the role runs?
16:11:38 <cyberpear_> The check that says "two factor must be used for privileged access" requires adding service=pam to /etc/sssd/sssd.conf
16:11:40 <maxamillion> defionscode: I've added a highlight notifier in my irc client for that because a lot of people coming to irc from slack expect it to work :)
16:11:59 <defionscode> ha
16:12:29 <cyberpear_> there is no effect on how our role runs by changing that.  It only would affect us if we were using strings like "true" and "false" or "yes" or "no" etc
16:12:56 <cyberpear_> we're using native bools
16:13:09 <shepdelacreme> yeah ok
16:14:02 <cyberpear_> for sssd.conf, if starting from an empty file adding that line causes a broken config... I'm thinking of adding a minimal valid config so we can add service=pam per that check
16:14:05 <shepdelacreme> we can just drop an ansible.cfg in the role dir with that override right?
16:14:10 <maxamillion> defionscode: and I use irccloud so it sync's everywhere (phone, tablet, laptop) ... it's just as convenient/annoying as slack ;)
16:14:40 <defionscode> I use ZNC for that
16:14:57 <cyberpear_> shepdelacreme: that would work if folks chdir into our role and run it from there, such as using the local.yml playbook, but that'd override any settings in their /etc/ansible/ansible.cfg or ~/.ansible.cfg
16:14:58 <maxamillion> ah +1
16:14:58 * defionscode should probably stop being a hipster
16:15:31 <shepdelacreme> yeah...I see https://docs.ansible.com/ansible/latest/reference_appendices/config.html#ansible-configuration-settings Ansible doesn't merge settings from different files :(
16:15:33 <maxamillion> defionscode: eh, embrace it ... I used to love running all my own stuff ... now I have two small children and I do that considerably less
16:16:20 <defionscode> cyberpear_ I think I'm ok with injecting a basic sssd.conf if it's empty/not-there
16:16:38 <cyberpear_> I've taken to using ANSIBLE_* env vars for config since those win over any ansible.cfg settings, but defer to ansible.cfg if not specified
16:16:54 <defionscode> ok
16:16:57 <defionscode> about to get merge-happy
16:17:06 <cyberpear_> hehe
16:17:07 <defionscode> any objections to approved prs?
16:17:16 <defionscode> assuming not, given "approved"
16:18:36 <cyberpear_> for the "workaround_for_disa" type flags, I plan to reverse those changes if/when DISA fixes their benchmark
16:18:47 <cyberpear_> but none of them make a system non-compliant
16:18:54 <cyberpear_> or less secure
16:20:02 <defionscode> yeah that's fine
16:20:16 <defionscode> auditors aren't always pro-logic
16:20:41 <shepdelacreme> DISA auditors are especially bad
16:20:56 <defionscode> bam
16:21:09 <defionscode> all PRs merged sans the outstanding mikerenfro one
16:21:19 <cyberpear_> some day, I need to turn off that flag and send an e-mail to disa.stig_spt@mail.mil complaining of all the failures...
16:21:49 <cyberpear_> haven't gotten the motivation (nor direction) to do that yet, though
16:23:12 <cyberpear_> would  be great to get a 1.0 release out the door some day
16:24:04 <cyberpear_> thanks for the reviews and merges!
16:24:09 <defionscode> np
16:25:00 <shepdelacreme> I think we are closing in on full implementation for all the stig items that can reasonably be automated
16:25:11 <shepdelacreme> once that happens I think a 1.0 release makes sense
16:25:15 <cyberpear_> has someone tackled the GUI items?
16:25:41 <shepdelacreme> nope
16:25:56 <cyberpear_> A coworker made some noises that he might try those, but no movement yet...
16:26:02 <shepdelacreme> ok
16:26:37 <shepdelacreme> I need to review the checklist in issue 174 and see where we are at with those changes. I think most of those are actually implemented
16:26:51 <cyberpear_> I guess I should go thru the v2r1 ticket and mark the complete items from these merged PRs
16:28:08 <cyberpear_> There were a couple that were "fixed" and merged but I wanted to go back and review that it was proper.  (I'd marked a comment on those items in the relevant ticket)
16:28:28 <cyberpear_> (these were PRs by outside folks, iirc)
16:28:51 <shepdelacreme> I think you DoS'd readthedocs with all those merges defionscode
16:28:57 <cyberpear_> lol
16:30:33 <shepdelacreme> We should add a section to the docs about the disa_workaround stuff I think
16:31:49 <cyberpear_> yeah, then maybe turn it off by default to get more attention on the bugs in DISA benchmark
16:31:58 <cyberpear_> (or does that just make us look bad?)
16:32:18 <defionscode> I'm all for calling out DISA
16:32:45 <defionscode> can we buy disaproblems.dev?
16:32:53 <cyberpear_> just not sure how much clout we have... if we turn it off, we should make its availability VERY clear
16:33:03 <cyberpear_> I'm sure it's not taken :P
16:33:13 <defionscode> probably not much clout
16:34:29 <cyberpear_> better approach might be to turn off workaround_for_ssg, then work w/ ssg to fix their content since they are upstream to DISA.
16:34:47 <cyberpear_> but I don't really have time to do that anymore, at least not recently
16:36:34 <defionscode> we're working hard to figure out a way to have someone staffed on a semi-full time bases to work on this stuff
16:36:51 <cyberpear_> that would be cool
16:36:55 <defionscode> will it happen? I dunno. But it's possible
16:36:59 <cyberpear_> heh
16:37:08 <cyberpear_> anyone familiar with auditd configuration?
16:37:22 <shepdelacreme> Looks like 34 controls "not implemented" and 10 of them are GUI things. The other 24 controls are mostly stuff that can't reasonably be automated.
16:37:35 <cyberpear_> the new RHEL-07-030330 requires the warning to be set at 75% of free space remaining rather than 25%
16:37:53 <cyberpear_> Is DISA actually asking us to send warnings when space usage reaches 25% rather than 75%?
16:37:59 <cyberpear_> that's how I read that change
16:38:15 <cyberpear_> but maybe I don't understand the auditd.conf correctly
16:38:39 <cyberpear_> admin_space_left is considered the last warning before running out of space and must be less than space_left
16:38:57 <cyberpear_> that tells me that space_left warns when xxMB of space is left, not when xxMB of space is used
16:39:30 <cyberpear_> I mean we can change that in our code to comply w/ DISA, but warnings will start flying out way too early, IMO.
16:39:54 <cyberpear_> (this was a V2R2 change)
16:41:43 <shepdelacreme> The intent of the control is to alert when 75% of space is used
16:41:48 <shepdelacreme> Determine what the threshold is for the system to take action when 75 percent of the repository maximum audit record storage capacity is reached:
16:42:04 <shepdelacreme> If the value of the "space_left" keyword is not set to 75 percent of the total partition size, this is a finding.
16:42:19 <cyberpear_> so their "finding" statement is wrong, as I read it
16:42:32 <shepdelacreme> But you are right that it might not be what they are actually accomplishing with the setting
16:42:58 <defionscode> for this I'd go with intent over fix text, assuming the fix text is actually improper
16:43:00 <cyberpear_> because setting that would casue the alert at 25% of space used, but I suppose I could just go test it to be 110% sure...
16:43:29 <cyberpear_> I 99% ignore fix text.  It's the check text that rules generally, and here, it's wrong.
16:44:14 <cyberpear_> btw, one of my changes knocked out one from https://github.com/MindPointGroup/RHEL7-STIG/issues/44 ! 041003 had been outstanding for a while
16:44:33 <cyberpear_> (going thru and marking items comple for those merged)
16:46:13 <cyberpear_> so looks like 4 outstanding New rules from V2R1
16:47:24 <defionscode> hm yeah that was poorly written
16:47:39 <defionscode> I just checked the man page to be sure and RH docs
16:47:46 <defionscode> it's definitely what you're saying
16:47:57 <defionscode> The space_left parameter, which specifies the amount of free space left on the disk for which an action that is set in the space_left_action parameter is triggered, must be set to a number that gives the administrator enough time to respond and free up disk space. The space_left value depends on the rate at which the Audit log files are generated.
16:49:36 <shepdelacreme> I would say we set it to the proper 25% value
16:50:22 <shepdelacreme> I wonder if that item is a manual review item or if its automatically checked by the benchmark
16:50:32 <cyberpear_> We can put a comment to the effect...
16:50:42 <Sicnus> (Sorry, I can't remember the commands for meeting, but when it's appropriate I'd like to ask a question.)
16:50:45 <cyberpear_> AFAIK, it is not automatically checked, or at least it doesn't fail as-is.
16:50:58 <cyberpear_> Sicnus: what's your question?
16:51:43 <Sicnus> I guess there was an old version and you guys would ship an local.yml  ?  Now it doesn't come with one and I can't figure out how to run the / playbook based on the roles.
16:51:54 <Sicnus> I know that's quite a vague question.
16:52:13 <Sicnus> I guess the question is:  is ansible-galaxy a req now?
16:52:22 <cyberpear_> I thought we do ship local.yml... going to check.
16:52:43 <cyberpear_> it's still there: https://github.com/MindPointGroup/RHEL7-STIG/blob/devel/local.yml
16:52:46 <cyberpear_> which version are you using?
16:53:16 <cyberpear_> maybe we never added it to the RHEL6-STIG role
16:53:20 <Sicnus> I pulled from the git download link.
16:53:22 <cyberpear_> Sicnus: which role are you using?
16:53:27 <Sicnus> one sec.
16:53:47 <Sicnus> https://github.com/RedHatOfficial/ansible-rhel7-disa-stig-role
16:53:53 <defionscode> that's not us
16:54:01 <Sicnus> perhaps that's the problem.
16:54:03 <Sicnus> LOL
16:54:11 <Sicnus> :(
16:54:19 <defionscode> https://github.com/MindPointGroup/RHEL7-STIG
16:54:27 <Sicnus> ahhhh right THAT's where I got it before
16:54:34 <Sicnus> so sorry to interrupt.
16:54:34 <defionscode> is us
16:54:39 <defionscode> oh no it's o
16:54:41 <defionscode> ok
16:54:43 <defionscode> that's what this is for
16:55:00 <defionscode> a predictable time where at least a subset of the maintainers are available for real time communication with the community
16:55:03 <cyberpear_> that RedHatOfficial org is the auto-generated roles/playbooks from ssg content
16:55:35 <Sicnus> tyvm!
16:56:17 <cyberpear_> Sicnus: maybe try #openscap
16:56:58 <Sicnus> we have to use DISA stuff.  But thanks.  (you guys have always been helpful)
16:57:45 <cyberpear_> our role does implement DISA STIG
16:57:56 <defionscode> redhat official isn't officially from DISA either
16:58:46 <cyberpear_> if you run our RHEL 7 role on RHEL 7.5, you can get 100% score on the DISA V2R2 benchmark, assuming you have central auth and central logging set up on your own
16:59:36 <cyberpear_> another question
16:59:40 <cyberpear_> ntpd vs chrony
17:00:01 <cyberpear_> the STIG says to put the relevant line into ntpd.conf, but it seems that the line is a chrony-compliant line.
17:00:09 <cyberpear_> Is DISA messed up here, too?
17:00:18 <shepdelacreme> yes...I would say so
17:00:33 <cyberpear_> RHEL-07-040500 I think
17:00:49 <cyberpear_> nope, not that one
17:01:44 <cyberpear_> actually, yes that one, but vaulted.io google link brought me to the wrong one...
17:01:56 <Sicnus> cyberpear_: yeah I've used you guys' stuff before.  :D  Just been a little while.
17:03:01 <cyberpear_> https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_security_technical_implementation_guide/V-72269?version=V2R2&compareto=V2R1
17:04:04 <cyberpear_> sorry, version comparison is wrong order
17:04:23 <cyberpear_> https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_security_technical_implementation_guide/V-72269?version=V2R1&compareto=V2R2
17:04:26 <cyberpear_> fixed ^
17:04:35 <shepdelacreme> this seems entirely focused on ntpd settings and doesn't mention chrony anywhere
17:04:43 <cyberpear_> anyone immediately familiar w/ ntpd/chrony settings?
17:04:59 <defionscode> yeah I'd have to do a little research
17:05:13 <defionscode> it's been a while since i messed with either on a semi frequent basis
17:05:22 <cyberpear_> yeah, it doesn't mention chrony, but the line seems like a chrony line, given the fix
17:05:37 <cyberpear_> server 0.rhel.pool.ntp.org iburst
17:05:45 <cyberpear_> that's a default line from /etc/chrony.conf
17:05:54 <cyberpear_> that's the part they added to the STIG item
17:06:07 <cyberpear_> hence why I think they meant to say chrony
17:06:12 <shepdelacreme> that line should work with nptd
17:06:48 <shepdelacreme> its not an invalid ntpd config
17:06:50 <cyberpear_> ok... I should probably just e-mail them and confirm that it's okay to use the default chrony
17:06:58 * cyberpear_ is not familiar w/ ntp config of any sort
17:07:18 <shepdelacreme> yeah it should work in either
17:07:31 <cyberpear_> good to know
17:07:53 <shepdelacreme> but what is weird
17:08:19 <shepdelacreme> it says the system has to sync with one of the redundant USNO servers
17:08:37 <shepdelacreme> but then instructs you to use 0.rhel.pool.ntp.org
17:08:44 <cyberpear_> heh
17:09:31 <shepdelacreme> the check content doesn't actually mention which servers it should point to so I guess its fine
17:09:57 <shepdelacreme> it just cares about maxpoll setting and a cron file existing
17:10:34 <defionscode> I have to step away gents
17:10:37 <defionscode> ya'll good to conclude the meeting w/o me?
17:10:38 <cyberpear_> sending a PR now to clear out one workaround_for_disa flag... and cover one V2R1 item
17:10:40 <shepdelacreme> yup
17:10:45 <defionscode> #chair shepdelacreme
17:10:46 <zodbot> Current chairs: defionscode shepdelacreme
17:11:27 <cyberpear_> if you have a second: https://github.com/MindPointGroup/RHEL7-STIG/pull/226
17:11:37 <shepdelacreme> I'll take a look today
17:11:50 <shepdelacreme> Do we have anything else?
17:12:07 <cyberpear_> I think that's all... plus we're over
17:12:13 <cyberpear_> thanks for your time everyone!
17:13:33 <cyberpear_> #endmeeting
17:13:41 <cyberpear_> j/k, I'm not chair
17:13:57 <cyberpear_> shepdelacreme: #endmeeting at your convenience!
17:14:20 <shepdelacreme> haha thanks cyberpear_ !
17:14:25 <shepdelacreme> #endmeeting