17:01:48 <cyberpear> #startmeeting Ansible Lockdown Working Group
17:01:48 <zodbot> Meeting started Wed Oct  9 17:01:48 2019 UTC.
17:01:48 <zodbot> This meeting is logged and archived in a public location.
17:01:48 <zodbot> The chair is cyberpear. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:48 <zodbot> The meeting name has been set to 'ansible_lockdown_working_group'
17:02:16 <dfed[m]> So I've recieved word that allowed to contribute is https://github.com/Michael-Angel-Sec/PostgreSQL-9_STIG
17:02:34 <dfed[m]> I have pushed them to PR to the PG9 stig in the Ansible Lockdown group
17:02:39 <dfed[m]> expect to see that soon
17:02:52 <cyberpear> excellent
17:03:27 <dfed[m]> I am aslo working to determine how to move the lockdown repos out of mindpoint's group into the ansible lockdown one, as only pg9 is in there now
17:03:37 <dfed[m]> I should have news on that this week
17:03:42 <cyberpear> sounds good
17:04:41 <dfed[m]> other than that I have not made much more progress on the push back up to upsteam for rhel 7, but will circle back to that this weekend
17:05:53 <dfed[m]> That's all I have at the moment, do you need to discuss anything?
17:06:04 <cyberpear> seeking feedback on ...
17:06:45 <cyberpear> https://github.com/MindPointGroup/RHEL7-STIG/pull/282
17:07:26 <cyberpear> specifically, does it make sense to set a default acl on the homedir so all content created there adheres to 755 mode requirement
17:07:59 <cyberpear> or should that part be optional
17:08:18 <cyberpear> or just set umask system-wide (also optionally)
17:08:32 <dfed[m]> I will need to ping with Dan on that. I think we should probably make it optional, because I can see use cases where it would not be well to
17:08:51 <cyberpear> at least, it'll skip container use cases since ACLs don't play well there
17:08:56 <dfed[m]> and in many cases the umask system wide will be set, so maybe that too
17:09:03 <cyberpear> the STIG doesn't actually require setting the umask system wide; it only forbids users to set their own umask
17:09:06 <dfed[m]> right
17:09:30 <dfed[m]> true, but at least three shops I dealt with used the system wide for audit reasons
17:09:37 <dfed[m]> so it'll be a common use case.
17:10:11 <dfed[m]> did this come from the downstream btw?  because I don't remember writing that LOL
17:10:22 <cyberpear> I did go thru and update lots of the old tickets w/ references to prs and checking off done items
17:10:40 <cyberpear> I saw yours and said "I can do it better"
17:10:41 <dfed[m]> oh awesome, thanks for that, I had that on my todo
17:10:57 <dfed[m]> I mean you sure can do better, LOL.  I will never claim to be the end authority on tasks
17:11:01 <cyberpear> (I'm swamped the next week or 2, so may be sparse)
17:11:11 <dfed[m]> fair
17:11:24 <cyberpear> it should have been a single task, but then there were the issues:
17:11:31 <dfed[m]> I like how this is handled atm, but I think we should make some optionals for dir and system wide acls
17:11:33 <cyberpear> 1. don't want to create domedirs in this task
17:11:54 <cyberpear> 2. file doesn't handle check-mode; always reports changed w/ recursive
17:11:58 <dfed[m]> no that's another contorl, right?  make sure interactives have a home dir
17:12:12 <cyberpear> exactly; I didn't want to conflate them
17:12:12 <dfed[m]> true
17:12:20 <dfed[m]> these are good changes, I think.
17:12:29 <cyberpear> then I added the ACL item to ensure future compliance
17:12:47 <cyberpear> so it really should be just a single "file" task, but reasons^ made it 4 tasks
17:12:47 <dfed[m]> I can add a review in depth more on the PR later today or tomrorow
17:13:10 <dfed[m]> I mean....always the case.
17:13:11 <cyberpear> I opened the smartcard PR based on downstream, and I had comments, but i'll add those to the draft PR
17:13:15 <dfed[m]> LOL
17:13:27 <dfed[m]> awesome, happy to take improvements to that one
17:13:28 <cyberpear> (I'd typed them on my phone, then it navigated away from the page and dropped them)
17:13:32 <dfed[m]> I have little ability to test that
17:13:52 <cyberpear> i'm implementing it for-real somewhere now, so I'll be able to test it
17:14:05 <dfed[m]> those controls specifically are tricky, I don't have a cac machine handy
17:14:19 <dfed[m]> nice
17:14:21 <cyberpear> really all you need is a smart card; doesn't have to be a cac specifically
17:14:27 <dfed[m]> that's invaluable, looking forward to the changes there
17:14:34 * cyberpear wonders if these modern credit cards could be used for the purpose
17:14:48 <dfed[m]> I guess I could do it against a machine I added a yubikey to maybe.
17:15:07 <cyberpear> yeah, if the yubikey is in CCID mode, it should work
17:15:21 <dfed[m]> noted, willl set up some stuff on that later
17:15:25 <cyberpear> on the "implement cat2 patches", i added comments where DISA breaks things
17:15:45 <dfed[m]> oh cool
17:15:49 <cyberpear> i.e., they tell you to use tls for communicating w/ ldap, but w/ active Directory, it encrypts w/ kerberos instead, and adding the starttls option breaks it
17:16:08 <dfed[m]> that's true, and I didn't know how to handle that specifically, btw.
17:16:22 <cyberpear> I'd raise that one in particular w/ DISA.
17:16:36 <dfed[m]> I can add that to the other windows-specific ones we opened
17:16:53 <cyberpear> it should be a SASL/GSSAPI OR TLS requirement
17:17:11 <dfed[m]> I think we can just do that, and use notes to explain for audits.
17:17:12 <cyberpear> raised it sev2 w/ red hat, and that's what they said
17:17:16 <cyberpear> yeah
17:18:15 <cyberpear> for the smart card stuff, it'd be good if we can avoid the authconfig tool, as it has a tendency to break the system, sometimes in a fail-open manner
17:18:31 <cyberpear> (I've seen it put an unconditional pam-permit.so at the top, e.g.)
17:18:33 <dfed[m]> did not know that specifically
17:18:35 <dfed[m]> wow LOL
17:18:56 <cyberpear> but in "best case scenario" it can give a good starting point
17:19:20 <cyberpear> w/ RHEL 8, they have authselect, which is a bunch of pre-tested pam configs and you choose one
17:19:42 <dfed[m]> yeah I'm starting to do rhel 8 stig now, I noticed a bunch of approaches like that
17:20:22 <cyberpear> Seems like RHEL 8 should be just parametrizing some paths, and a few things where one tool has been swapped for another
17:20:39 <cyberpear> (based on having read the release notes months ago)
17:21:00 <dfed[m]> yeah, how that vectors is what I'm looking at and I think you're right
17:21:16 <cyberpear> don't know if pam_pkcs11 config can ben snippeted, but at least blockinfile seems better than placing the whole file, I think
17:21:42 <cyberpear> but I hope to provide real-world feedback on that one when I get to it
17:21:47 <dfed[m]> agreed.
17:21:55 <dfed[m]> nice, I look forward to it
17:22:10 <cyberpear> I don't think I have anything more for today.
17:22:36 <dfed[m]> awesome.  Thanks for the meeting.  I'll ping you as I get through my action items
17:22:53 <cyberpear> sounds good. will close meeting in 5 in case anything comes up
17:22:58 <dfed[m]> we will likely need to talk about how the migration of repos goes
17:23:05 <dfed[m]> thanks!
17:23:29 <cyberpear> #info a complete PGS9 STIG has been made open source by a third party
17:26:25 <dfed[m]> They also seem to have kept real close to our conventions
17:29:59 <cyberpear> indeed.
17:30:38 <cyberpear> #endmeeting