19:00:28 <cyberpear> #startmeeting Ansible Lockdown Working Group
19:00:28 <zodbot> Meeting started Thu May 14 19:00:28 2020 UTC.
19:00:28 <zodbot> This meeting is logged and archived in a public location.
19:00:28 <zodbot> The chair is cyberpear. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:28 <zodbot> The meeting name has been set to 'ansible_lockdown_working_group'
19:00:34 <cyberpear> #topic Roll Call
19:00:35 <cyberpear> .hello2
19:00:36 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
19:00:41 <cyberpear> hi xgeorgex
19:01:00 <xgeorgex> How's it going?
19:01:07 <cyberpear> good. you?
19:01:12 <xgeorgex> I don't think David's going to make it this week
19:01:27 <cyberpear> ok. anyone else here today?
19:02:34 <xgeorgex> Sounds like It's just you and myself today
19:02:39 <cyberpear> yeah, I guess it's just the 2 of us!
19:02:45 <cyberpear> #topic Open Floor
19:02:46 <xgeorgex> lol
19:02:56 <cyberpear> anything new on the lockdown front?
19:03:15 <xgeorgex> I'm closing in on finishing up the tomcat STIG
19:03:25 <cyberpear> nice
19:03:35 <cyberpear> you figured out the `xml` module stuff?
19:03:36 <xgeorgex> We are also getting close to finishing up the windows server 2019 stig
19:03:48 <xgeorgex> Yeah, with a lot of head beating
19:04:15 <cyberpear> it's an essential module, but a pain to get working
19:04:45 <xgeorgex> One of the items I was fighting through just worked one day, I don't know what I was doing different that day since when I worked I just got the task to the way I thought I had it when it wasn't
19:04:49 <xgeorgex> But it just worked
19:04:59 <cyberpear> sometimes it just takes leaving and coming back
19:05:05 <xgeorgex> The other was some XPath stuff not working exactly how I was hoping it would work
19:05:14 <xgeorgex> And it took me a while to figure out how to work around that
19:05:21 <cyberpear> #info xgeorgex making good progress on Tomcat STIG role
19:05:27 <cyberpear> did you run into any namespace issues?
19:05:43 <xgeorgex> I had to figure out how to use it, but once that was done it was fine
19:05:53 <xgeorgex> There are a couple config files that have namespaces setup
19:06:14 <cyberpear> when I messed w/ it, I ran into an issue where legacy codebases used a different xmlns than what's currently expected by modern tomcat
19:06:19 <xgeorgex> Which I'm abit puzzled why a config file will have multiple name spaces
19:07:19 <cyberpear> it's XML, "overpowered"
19:07:20 <xgeorgex> But figuring out that module is making things a lot easier. I'm going to revisit my apache work to use that module
19:07:35 <xgeorgex> Since I did a bunch of crazy lineinfiles/replaces
19:07:36 <cyberpear> that sounds very nice
19:08:44 <cyberpear> I updated my lockdown-linux role to detect whether the system is "live" meaning it has an init system running
19:08:46 <xgeorgex> With that I have just been working on the other client project and poking at the tomcat stuff in between
19:08:59 <xgeorgex> We should be wrapped up with that work by the end of this week so I can fully focus on tomcat starting next week
19:09:05 <cyberpear> now it only attempts to restart services when an init system is running
19:09:16 <xgeorgex> nice
19:09:34 <cyberpear> auditd doesn't run in a container at all because audit subsystem of linux isn't namespaced
19:09:56 <cyberpear> audit doesn't run at all in auditing mode -- you can still run it as a server to accept audit logs from other systems
19:10:49 <cyberpear> tested the sshd_config rules on "live" and "dead" rhel6-8 containers, and "dead" ubuntu and opensuse containers
19:11:02 <xgeorgex> Sweet
19:11:40 <xgeorgex> That's a pretty good range of linux flavors
19:11:47 <xgeorgex> To confirm it with
19:11:56 <cyberpear> yeah
19:12:15 <cyberpear> I want to figure out how to get it hooked to Github Actions, since those are free for Open Source projects
19:12:50 <cyberpear> pulled my hair out elsewhere... someone decided to push the "remediate" button in Satellite for some RHEL 8 hosts... I was not pleased... it deployed all the scap-security-guide rules and broke the systems
19:13:06 <xgeorgex> hahaha
19:13:09 <cyberpear> not completely dead, but there's no "undo" button w/ SSG, so it's a rebuild in my opinion
19:13:12 <xgeorgex> Sounds like it was a fun time
19:14:14 <cyberpear> #topic Generic Linux Role
19:14:25 <cyberpear> question: do people care about the order rules run in?
19:14:48 <cyberpear> for sure, we care about the prep tasks and the cleanup tasks order, for proper functionality
19:14:59 <cyberpear> but for all the rules inbetween, do people care?
19:16:04 <cyberpear> My thought is that, especially if we're using the stig_xml callback, people can use the STIG Viewer to see the remediation/audit results, versus scrolling the ansible output.
19:16:58 <xgeorgex> From what I have seen I don't think so. We have some that aren't in order since you really can't do it in the order it shows up in the guide
19:17:02 <cyberpear> having the order be constant regardless of which standard is being applied can give us a better confidence that our role is identically-tested across standards
19:17:51 <cyberpear> but we can choose some logical order if there is one, and have it applied across all
19:18:40 <xgeorgex> Yeah that's something we can look into. I know going between versions, like RHEL7 to 8, a lot of the same tasks are there but they are moved around for some reason
19:18:49 <xgeorgex> So having some piece of it being consistent is nice
19:19:05 <xgeorgex> I think even between minor version changes I have seen controls swapped around
19:20:07 <cyberpear> yeah
19:20:19 <cyberpear> especially if you sort by V- IDs
19:20:25 <xgeorgex> yup
19:20:29 <cyberpear> the STIG-IDs are more consistent w/in a line of STIGs
19:20:51 <cyberpear> and DISA's going to renumber all the V- IDs, leaving the STIG-ID unchanged
19:22:09 <xgeorgex> Yeah that could be something we start looking at when we start looking at consolidating roles
19:23:20 <cyberpear> I think generally, it probably makes sense to have one role per technology.  "Linux", "Apache", "Postgresql", "Docker", "kubernetes" -- whatever
19:23:35 <cyberpear> just make the rules, and map them to CIS or STIG requirements and IDs
19:24:11 <xgeorgex> Yeah and I think that's where we are leaning at this point
19:24:33 <cyberpear> I was going to split out the `vars/main.yml` into separate `vars/main/<multiple-files>` to make it easier to look at only the relevant part; if you don't care about the STIG mappings, don't look at that file
19:25:11 <xgeorgex> That's a good approach to it
19:25:56 <cyberpear> it's supported since ansible-2.6, and since the approach for lockdown-linux only works from ansible-2.7, I've got no problem splitting them out like that
19:26:29 <cyberpear> otherwise, I'd generally want to keep compatibility with older ansible versions, since they still exist in the wild
19:27:58 <cyberpear> since Red Hat "doesn't ship tomcat" on RHEL 8, I was going to rebuild their "jws5" packages on COPR, and hopefully get it into CentOS
19:28:00 <xgeorgex> How old is 2.5?
19:28:39 <cyberpear> 2 years or so
19:28:48 <cyberpear> "jws5" == JBoss Web Server == tomcat 9
19:29:52 <cyberpear> ansible-2.4 is the version contained in the extras repo, and I believe the only version available w/ RHEL 7 Workstation
19:30:30 <cyberpear> (since they don't have a `rhel-7-workstaiton-ansible-2-rpms` repo, AFAIK)
19:30:32 <xgeorgex> ahh
19:31:32 <cyberpear> #topic Tomcat
19:31:46 <cyberpear> what were you using to test Tomcat?
19:31:58 <cyberpear> RHEL 7 w/ upstream tarballs?
19:32:30 <xgeorgex> To not have to deal with registering Cent 7
19:32:39 <cyberpear> yes, good point
19:33:33 <xgeorgex> Once I get it fully written I'll test against actual RHEL, even though they should be the same. But for like quick dev testing cent is what I generally use
19:34:52 <cyberpear> yeah, they're basically identical, with only the occasional bug affecting only CentOS or only RHEL
19:34:53 <xgeorgex> Once I get tomcat going with RHEL, I need to get it going with Ubuntu. So that will be the next set of test runs/adjustments before it's released
19:35:01 <cyberpear> I see
19:35:09 <cyberpear> targeting Ubuntu 18.04?
19:35:17 <cyberpear> (I know, they should be the same...)
19:35:23 <xgeorgex> Yeah
19:35:41 <cyberpear> colo
19:35:43 <cyberpear> *cool
19:35:48 <xgeorgex> I might even see how 16 does and I think the latest version that just came out is an LTS so probably that too
19:36:16 <cyberpear> yep, 20.04 is an LTS; just not STIG for it yet... funny that the 18.04 STIG dropped just before 20.04 came out
19:36:57 <xgeorgex> I think once we get tomcat done we will need to pick back up on os based stigs
19:37:10 <xgeorgex> I think Ubuntu is going to be one of the distros high on the list
19:38:12 <xgeorgex> Once we finish up windows server 2019, we will have to circle back and finish up the lose ends on server 2016
19:38:51 <cyberpear> seems likely; many folks use or want to use Ubuntu
19:38:56 <xgeorgex> Once we get tomcat done, I'm not sure what app based roles we will be working next
19:39:04 <xgeorgex> Yeah that's what Ive been gathering.
19:39:33 <xgeorgex> People seem pretty psyched on the Ubuntu stuff
19:39:49 <cyberpear> I'm curious who is the biggest audience for SUSE...
19:40:13 <cyberpear> it's had a STIG available for quite some time; I've just not come across it as often as RHEL/Ubuntu
19:40:30 <xgeorgex> Yeah I'm not sure, that fizzled out almost as fast as it become cool
19:41:16 <cyberpear> I think it's hugely beneficial that they exist to prevent a monoculture; just haven't learned what their key value is.
19:41:53 <cyberpear> on my "Ubuntu vs RHEL" list the other day, I added, "Ubuntu includes all build dependencies for its own packages; RHEL does not"
19:42:50 <xgeorgex> I remember a while ago there was a country that announced it was going all Suse (Germany, Switzerland, Norway, or something) and I thought that their moment
19:43:03 <xgeorgex> hahaha
19:44:00 <xgeorgex> For my personal laptop/computer I ran freebsd for a long time, but back in like 2007ish I migrated over to Ubuntu and never looked back
19:44:09 <cyberpear> Yeah, I guess maybe SUSE is popular outside US...
19:44:17 <cyberpear> yeah, I've heard folks running BSD on a laptop
19:44:44 <cyberpear> I've been all Fedora since Fedora 7
19:45:06 <xgeorgex> Nice, when I switched away from bsd fedora hated my video card
19:45:48 <cyberpear> Fedora 8 was the one that ruled the day, improving laptop compatibility in its day.  The recent Fedora 32 did the same, and now my nvidia/intel hybrid graphics ThinkPad works like a charm w/o any mucking w/ the kernel anymore
19:46:04 <xgeorgex> sweet
19:46:07 <cyberpear> (and no proprietary drivers)
19:46:15 <cyberpear> #topic Open Floor
19:46:47 <cyberpear> was very happy w/ the Lenovo/Fedora partnership where ThinkPads will be shipping w/ Fedora out-of-the-box
19:47:04 <xgeorgex> Yeah it's nice to non-windows stuff be an option
19:48:01 <cyberpear> I noticed that SSG seems to configure tmux to lock its screen after an inactivity timeout
19:48:12 <cyberpear> much better than the TMOUT bash setting
19:48:44 <xgeorgex> haha
19:49:13 <cyberpear> but it also forces you into a tmux session when you log in, which is annoying, especially when you become root and have nested tmux sessions...
19:49:58 <cyberpear> and if you've become root, root's tmux session will lock and it'll ask you roots password!
19:50:12 <xgeorgex> haha
19:50:21 <cyberpear> once again, the lesson is "don't remediate w/ SSG"
19:50:39 <cyberpear> use it for compliance checking, fine; just not enforcement
19:54:04 <xgeorgex> Hahaha, was there anything else you wanted to cover?
19:55:30 <cyberpear> I think that's all I head on-topic for today, unless I think of anything else in the next few minutes.
19:55:39 <cyberpear> but it's already been a few
19:55:46 <cyberpear> thanks for coming!
19:55:52 <xgeorgex> No worries
19:56:02 <cyberpear> anyone else lurking w/ last-minute questions/comments?
19:56:24 <cyberpear> will end in 1 minute
19:56:34 <xgeorgex> Sounds good
19:59:29 <cyberpear> #endmeeting