16:10:42 <cyberpear> #startmeeting Ansible Lockdown Working Group
16:10:42 <zodbot> Meeting started Thu Jun 27 16:10:42 2019 UTC.
16:10:42 <zodbot> This meeting is logged and archived in a public location.
16:10:42 <zodbot> The chair is cyberpear. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:10:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:10:42 <zodbot> The meeting name has been set to 'ansible_lockdown_working_group'
16:10:48 <shepdelacreme> sorry folks...meetings all day
16:10:55 <cyberpear> #chair shepdelacreme dfed
16:10:55 <zodbot> Current chairs: cyberpear dfed shepdelacreme
16:11:23 <cyberpear> #topic core-supported modules
16:11:37 <cyberpear> #info there was a suggestion that we limit ourselves to core-supported modules
16:11:46 <dfed> I did not say limit, I said favor when possible
16:11:59 <cyberpear> I don't see a good reason to limit; use the best tool for the job
16:12:02 <dfed> and the argument is around supportability.
16:12:28 <cyberpear> e.g., the best tool for modifying ini files is `ini_file`, IMO
16:12:32 <dfed> There was, when I was head of support, plans to split RH's official support of community modules off, leaving "core" modules as supported with SLA.  That afaik is still in place.
16:12:47 <shepdelacreme> I think it makes sense to say we "prefer supported core modules"
16:12:48 <dfed> and many of the community modules require epel, which customers of our cannot use
16:13:03 <cyberpear> I'm okay avoiding modules that require epel
16:13:17 <cyberpear> should work w/ RHEL out-of-the box, is my opinion
16:13:22 <bcoca> i would also argue that you really want 'full file control' as 'partial file updates' can be easily overriden by duplicate entries with more precedence
16:13:33 <bcoca> specially in the ini case
16:13:49 <shepdelacreme> many of the non-core modules may require epel or other package managers in the future if they get split out
16:13:53 <cyberpear> (things in rhel-7-server-optional-rpms are also not supported, for example)
16:14:26 <dfed> again, this also has to do with SLA.  core supported modules have action to redress under an SLA, community does not.
16:14:32 <shepdelacreme> limiting the amount of extra stuff that needs to be installed, outside of the core helps usability as well as supportability
16:15:34 <cyberpear> what non-core modules are we using today?
16:15:48 <cyberpear> (at least `replace` and `pamd` that I know of, but I haven't checked b/c it's never mattered)
16:15:56 <dfed> I haven't done a full audit, but I was focusing on using core supported as I finish out the stig role for rhel 7
16:17:22 <cyberpear> shepdelacreme: is there a particlar thing you're referring to wrt installing extra stuff?
16:17:30 <dfed> again when possible to favor it.
16:18:44 <cyberpear> To help w/ reliability, it probably would make sense to add some (more) integration tests into core ansible for the non-core modules we're using
16:19:19 <dfed> maybe, but that still doesn't get us SLA support.
16:19:44 <shepdelacreme> Just a quick intro for everyone that isn't aware. dfed is previously of the Ansible team for many years and is now with us at MindPoint Group leading up our efforts to get the STIG and other hardening roles sorted/etc. He is a core maintainer from our side as myself and defionscode are busy with other things.
16:20:26 <shepdelacreme> As far as extra stuff...I'm would just like to limit the amount people need to install in the future. i.e. if non-core gets split out that becomes an issue for use
16:20:45 <dfed> I have no definitive timeframe for when that happens, btw, but I would llike to head off the headacche
16:21:01 <cyberpear> how often has SLA been needed for modules we use, as we use them?
16:21:07 <dfed> I pinged appnel and michelle perz to understand how that is progressing in product planning
16:21:08 <cyberpear> I'm only aware of one breakage of pamd
16:21:55 <cyberpear> in that case, the `pamd` module had no integration tests in ansible, but only unit tests
16:22:01 <dfed> @cyberpear not a good metric. The first customer of mindpoint that has issues comes to me and I may need to act on a timeframe, having a partner relationship or a customer relationship in ansible support is a different path than community maintenance.
16:23:12 <dfed> and down the road when the split happens, this saves us headache.
16:23:28 <dfed> now I'm not saying don't use community atm, I am saying when given a choice, favore core.
16:23:29 <cyberpear> what about copying particular tasks from scap-security-guide, then calling RH for support of that?
16:23:56 <cyberpear> it's BSD-3-Clause, so compatible w/ MIT, if I understand
16:23:58 <dfed> RH support path for that may not end up in ansible support's queue.
16:24:08 <dfed> it may end up with the openscap team
16:25:25 <shepdelacreme> Also, they are only going to support the tasks if you are using/applying them with the ssg
16:25:34 <shepdelacreme> not if you copy them into another playbook for use
16:25:38 <dfed> bingo
16:26:06 <shepdelacreme> not to mention they are often just command or shell tasks :(
16:26:23 <cyberpear> #agreed prefer core-supported modules when possible
16:26:30 <dfed> TY.
16:26:55 <dfed> btw I'll resubmit from a new branch to clean up the other things.
16:27:10 <dfed> I need to get a bunch of things plumbed correctly now that I have settled in
16:27:15 <cyberpear> In this particular case, I think we should just plop the snipped into the conf.d directory w/ `copy` (or `template` if you prefer)
16:27:35 <cyberpear> don't try to use lineinfile, because that doesn't work well for managing ini files
16:27:40 <dfed> that works. I'd template b ut that's muscle memory. I wasn't aware copy populated the vars in the file
16:28:19 <cyberpear> especially for single-digit files, I greatly prefer `copy` w/ `content`
16:28:35 * dfed shrugs
16:28:39 <dfed> I have no argument against that
16:28:44 <cyberpear> tiny files, but do what's easiest for you
16:29:28 <cyberpear> shepdelacreme would prefer to have a shorter <tasks>.yml but that's kind of a lost battle unless we want re-organize
16:30:07 <shepdelacreme> yeah
16:30:12 <dfed> I mean, shorter and more elegant is fine, but if it compromises readability and easy understanding that's an issue.
16:30:12 <cyberpear> #agreed use `copy` or `template` instead of `ini_file` when config snippets are supported
16:30:38 <shepdelacreme> the cat2 file is unweildy but not worth splitting stuff out for now
16:30:54 <dfed> it is a monster, to be sure.
16:31:30 <cyberpear> #topic ansible-hardening integration, organization
16:32:01 <dfed> so, can I get a recap on thiis topic?  being new(ish) and all?
16:32:22 <cyberpear> there was some agreement to integrate openstack's ansible-hardening and ansible-lockdown
16:32:28 <dfed> right got it.
16:32:34 <cyberpear> w/ ansible-lockdown being the name of the merged topic
16:32:39 <cyberpear> shepdelacreme: may be able to provide more details
16:33:05 <dfed> I remember this in the fog of my first couple weeks, vaguely.  I think we were talking about difference in format/style of the roles
16:33:22 <cyberpear> I attempted to use ansible-hardening against an ubuntu 16.04 system, and got my first good look inside...
16:33:30 <dfed> how'd that go?
16:33:48 <cyberpear> looks like it was a rhel7 stig role that was tweaked to allow it to run on other OSes
16:33:57 <dfed> um.  that's problematic
16:33:59 <cyberpear> so it doesn't specifically implement the ubuntu STIG
16:34:05 <shepdelacreme> yeah the goal with this was to support applying the rhel7 stig to non-RHEL systems like Ubuntu and what not
16:34:26 <cyberpear> there's now an official ubuntu 16.04 stig at V1R2
16:34:39 <dfed> there's a ubuntu stig though...the rhel one will get specific into rhel-ish things in filesystem and location and env that may be troublesome
16:34:42 <shepdelacreme> I think it makes more sense to just build STIGs specifically for systems that have a STIG defined and extend the RHEL7 STIG to be usable on RHEL-alike systems
16:34:47 <dfed> yeah
16:34:50 <dfed> agreed with that
16:34:59 <cyberpear> I did a bit of comparison, and there's a lot similar, but DISA seems to have done a poor job of the SRG references between the 2.
16:35:12 <dfed> hm.
16:35:17 <shepdelacreme> of course they did...its DISA
16:35:20 <dfed> LOL
16:35:45 <cyberpear> they reference the "follow the STIG" SRG requirement several times as a reference for particular requirements
16:36:00 <cyberpear> yeah, I LOLed
16:36:16 <dfed> ...Where's my facepalm gif?
16:36:23 <cyberpear> the base requirement for including a particular task in the STIG is an upstream requirement to "follow the STIG"...
16:36:31 <cyberpear> (but we're a bit off topic, I guess)
16:36:48 <dfed> ok so what should we do to adopt the hardening stuff?
16:37:07 <cyberpear> a lot of it maps over exactly
16:37:16 <cyberpear> exact same checks and remediations
16:37:25 <dfed> ok
16:37:52 <dfed> we should, at some point, talk about moving the repos into the ansible-lockdown github org, but that's off topic for now
16:37:52 <cyberpear> I was toying w/ the idea of re-using ansible-hardening's "topic" split-out, perhaps further splitting that out by severity
16:38:06 <cyberpear> just in the interest of not having a 2-3k-long tasks file
16:38:08 <dfed> oh, that might be interesting.
16:38:28 <cyberpear> we'd previously agreed to just keep our severity break-out but it might be worth reconsidering
16:38:37 <dfed> in fact some category split, then another severity split could work mapped out correctly for more controls in the vars as to which to run
16:38:51 <dfed> the topic part could help that
16:39:25 <cyberpear> we also can split out the vars files w/ `defaults/main/tasks.yml`, `defaults/main/config.yml`, etc
16:39:31 <cyberpear> same for vars, tec
16:39:33 <cyberpear> etc
16:39:38 <dfed> agreed
16:39:53 <cyberpear> (somehow that feature didn't make it into the anisble release notes so I just became aware of it; available since 2.6)
16:40:20 <dfed> I remember some interesting support tickets on that one
16:40:35 <shepdelacreme> that would def help with limiting file size and git commit blast radius as the tempo of changes picks up
16:40:55 <dfed> regardless, let's dig in there and see what we can improve in our design of the roles
16:41:07 <dfed> agreed @shepdelacreme
16:41:28 <cyberpear> I still haven't had the chance to demonstrate my "all-in-one linux SRG/STIG" role idea, but hopefully I can get to it shortly
16:41:57 <cyberpear> (key features being that it keeps the usability and configurability of the RHEL7-STIG role)
16:42:08 <dfed> interesting
16:42:48 <cyberpear> so you'd use 'rhel7stig_my_config' vars for rhel7 customizations, but ubuntu16stig_ or equivalent for those OSes
16:42:59 <cyberpear> perhaps w/ some generic name that would work for both
16:42:59 <dfed> brb y'all I have to let the dog out.
16:43:54 <cyberpear> would implement using the `vars` and perhaps `varnames` lookups, but that implementation wolud be hidden in `vars/` where no one should ever have to look
16:45:47 <cyberpear> #info worth evaluating a break-out of role tasks by category like ansible-hardening
16:46:14 <cyberpear> I think ssg has their own category system, but I haven't paid too close attention
16:47:10 <shepdelacreme> I wonder if there is a STIG or SRG categorization we can reference (aside from cat 1, 2, 3 obviously)
16:47:33 <shepdelacreme> if not then I think most items can be logically placed in different buckets
16:47:49 <shepdelacreme> i.e. auditd, authentication, ssh, etc
16:47:50 <cyberpear> #info consider splitting `defaults/main.yml` into `defaults/main/tasks.yml`, and `defaults/main/config.yml` (bikeshed names)
16:48:05 <cyberpear> does CIS have good categories?
16:48:37 <shepdelacreme> maybe...they didn't used to but they have mostly standardized now I think
16:50:12 <cyberpear> something like CISSP has security "domains" but those don't really map here
16:53:46 <cyberpear> dfed: FYI, you can force-push rather than opening a new PR. `git push --force-with-lease` is your friend
16:54:18 <dfed> fair.
16:54:29 <dfed> I mostly wass using that as a window to watch the travis/testing pickup
16:54:49 <dfed> which is why you got sloppy PRs. They'll be more polished going forward.
16:55:20 <cyberpear> I think github also allows you to mark them as "draft" PRs, and adding WIP to the title at the start
16:55:30 <dfed> does it?  TIL
16:55:36 <dfed> *does it?  wow bad keyboard
16:55:45 <cyberpear> then add a comment like ready_for_review once ready
16:55:53 <dfed> I'll do that going forward.
16:56:22 <cyberpear> does anyone know how well the ansible-hardening does relative to the ubuntu 16.04 stig?
16:56:31 <cyberpear> (today, that is)
16:56:49 <dfed> I've not poked at it to evaluate, but I can put that on my list
16:57:48 <cyberpear> I don't have time now to do an audit, but I've audited the RHEL7 and RHEL 6 STIG roles, and they are phenomenal.
16:58:35 <cyberpear> and the shortcomings of RHEL7-STIG are well documented in https://github.com/MindPointGroup/RHEL7-STIG/issues/44
16:58:56 <dfed> should we adopt those to our own instead of me writing new tasks per our format?
16:59:20 <dfed> I assume you mean the stig roles from harden ing
16:59:25 <cyberpear> sorry
16:59:31 <cyberpear> lockdown roles are phenomenal
16:59:36 <dfed> got it.
17:00:03 <cyberpear> only 7 items outstanding for RHEL7-STIG in my mind for non-GUI uses
17:00:14 <dfed> working on those ;)
17:00:15 <cyberpear> (most of the others are compliant in a default configuration)
17:00:42 <cyberpear> I don't think I have anything else on topic
17:00:46 <dfed> honestly I don't know how often we'll get the GUI uses in the field, but we'll see
17:00:49 <cyberpear> any other news/announcements/plans to discuss?
17:01:03 <dfed> none from me.
17:01:20 <dfed> @shepdelacreme you good?
17:01:29 <shepdelacreme> yup I'm good thanks
17:01:31 <cyberpear> I'm starting to see GUI more often, but sometimes it's b/c folks are in a windows world and not comfortable w SSH
17:01:41 <cyberpear> thanks all!
17:01:48 * dfed waves
17:01:50 <cyberpear> #endmeeting