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