16:01:03 #startmeeting Lockdown Working Group 16:01:03 Meeting started Thu Nov 1 16:01:03 2018 UTC. 16:01:03 This meeting is logged and archived in a public location. 16:01:03 The chair is defionscode. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:03 The meeting name has been set to 'lockdown_working_group' 16:01:11 hello 16:01:34 Alright roll-call, who's here? Already got shepdelacreme and cyberpear checked. 16:02:03 howdy 16:02:15 * defionscode waves 16:02:32 ansible hardening folks will be a bit later 16:03:18 everyone have the agenda handy? I was thinking just to go down the list, but if someone has limited time and wants to hit something off the bat we can do that first 16:03:28 #link https://github.com/ansible/community/issues/388#issuecomment-435033692 16:04:30 yup 16:04:49 alright lets start 16:05:09 #meetingtopic general project 16:05:32 cyberpear brought up making a policy for adding new repos to lockdown 16:06:21 so i think there are two paths 16:06:45 It's easy enough to use the bench parse tool to generate the template for a given Stig 16:06:58 1) repos which we 'endorsed/curated' and others which might be entirely driven outside our own policies/governance 16:07:00 cyberpear: I agree 16:07:19 #agreed use benchparse to init new role 16:07:28 Do we need a category kind of like the kubernetes incubator? 16:07:48 not sure what the incubator is? 16:08:09 It's basically the experimental stuff that's not production grade yet 16:08:51 just googled it's been superceded the idea is the same 16:08:54 #link https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#sig-repositories 16:09:09 #idea model after k8s subprojects 16:10:33 hmm any preference on the GH hosting org? 16:10:36 Are we talking about the SIG repositories stuff and creating a new github org or something? 16:11:27 I suppose that's on the table? 16:11:31 so questions are 16:11:41 What if we maintain a list of projects in the main lockdown repo with a status: Official, Incubating, etc 16:11:46 1) how is a new repo requested added and 2) where does it live? 16:12:11 shepdelacreme I dont think we would have issues just having it live in the mindpointgroup org, or what do you think? 16:12:19 those repos can sit in individuals GH accounts or we can host at the MPG org if they want? 16:12:48 I would prefer for us to have some level of control over it, to prevent funky settings or the repo being deleted outright 16:12:56 To get in lockdown or whatever they have to accept the projects CoC, style guidelines, etc? 16:13:04 ok 16:13:09 IO 16:13:17 I'm fine with that as well 16:13:21 i think that should be a given regardless of official/incubating 16:13:50 and the request can/should be made in the ansible-lockdown repo 16:14:02 If we host them in the MPG org we can see about making the maintainers outside collaborators on those repos? 16:14:13 yeah exactly 16:14:46 the difference could be that 'incubating' repos would have no restrictions on direct merges/pushes to master by the maintainer 16:15:00 once it 'graduates' then changes/tags/etc would be restricted 16:16:04 I'm fine with that...playing devils advocate though. Do you think some folks will have issue having those repos be within the MPG org? 16:16:32 so 1) requests happen as issues in lockdown root repo 2) repo is made in MPG org 3) 'incubating' repos let contributors make direct changes, wild-west style 4) once it's ready then it can be graduated and changes would follow governance 16:16:57 shepdelacreme: if they do then we can figure it out later? IOW it's not a real problem yet 16:17:04 cyberpear: what do you think? 16:17:11 I'm good with that :thumbsup: 16:17:42 Not sure how often people will want to add new repos, but it's easier to convince a company to contribute to an existing project... 16:17:56 Than convince them to release their own thing 16:18:16 especially in this space 16:18:43 ok just to be explicit cyberpear shepdelacreme any objections? (also anyone else lurking can chime in) 16:19:28 I'm good with this approach 16:19:55 Sorry, I'm high latency today. Typing on a phone... it might be worthwhile to create an ansible lockdown GitHub organization and automatically create repos for every Stig, then move them into the mpg repo once they're stable 16:20:21 But no objection to what's already been mentioned 16:20:45 oh that's not a bad idea 16:21:48 we probably will exclude certain stig benchmarks but i like the gist 16:21:50 The only reason I'd be opposed to that is because it would be another thing to manage hehe 16:22:33 shepdelacreme: i think the additional overhead would be negligible, i already have a crawler that parses the DISA site for stigs, I can script out a generator 16:22:35 also would the org just house incubating stig repos? The official AL repo would stay where it is in the Ansible org? 16:22:41 shepdelacreme: correct 16:22:57 Yeah, it'd take a few hours to automate 16:22:57 we want to make sure folks understand it's a formal part of the upstream Ansible community 16:23:04 Oh I mean the overhead of managing another GH org 16:23:38 shepdelacreme: even that shouldnt be tough, it wont have private repos, or billing, or anything, just the three of us and whoever else jumps on board as a maintainer later 16:23:48 But I'm generally fine with it 16:24:27 ok let me mark this up 16:24:32 ansible-lockdown-incubating 16:24:34 ? 16:24:47 #agreed create ansible-lockdown org to house incubating roles 16:24:55 we can probl just call the org ansible-lockdown 16:24:57 dont see why not 16:25:28 confusion about what is housed in the Ansible org, the MPG org, and the ansible-lockdown org? 16:25:44 I will defer to you two though 16:26:05 ansible org repo is for global issues, housing submodules, github project stuff 16:26:27 mpg org for 'official/endorsed/ready-for-primetime' roles 16:26:37 ansible-lockdown for beta/incubating roles 16:26:40 thats how I grok it 16:27:47 #action defionscode to make org and role scaffolding for stigs 16:27:48 In the long run, I'd anticipate minimal resistance to having "supported" roles in a 'ansible-lockdown' org 16:28:01 vs "who is MindPointGroup"... 16:28:03 right...I mean confusion having an "ansible-lockdown" org that doesn't house the official ansible-lockdown repo? Do you think people that search for ansible-lockdown and hit the org are going to ask...why isn't the ansible-lockdown repo housed here/etc 16:28:31 hmm 16:28:39 perhaps ansible-lockdown for stable and ansible-lockdown-incubator for unstable? 16:28:56 with as-is git submodules from the official ansible org 16:29:15 (I'm guessing that ansible doesn't want 200 repos in their org directly...) 16:29:33 I'd prefer not to move the official roles out of the MPG repo 16:29:39 cyberpear_: yeah probably not, esp since lockdown is already a unique repo in that it's a repo that subs to other repos 16:30:14 no strong opinion here 16:30:23 MPG has done most of the work 16:30:29 ok so middle ground, just an ansible-lockdown-incubator org then? 16:30:41 sounds good to me 16:30:53 ok 16:31:00 shepdelacreme that good with you? 16:31:07 yup 16:31:49 #agreed create ansible-lockdown-incubator org for things not-yet-endorsed by lockdown maintainers as 'ready' 16:32:08 ok done 16:32:23 next item 16:32:28 ansible version support 16:33:19 I think Im inclined to say current and previous dot release and only current major release? 16:33:59 but...the modules issue is a tricky one 16:34:10 ie pamd is gonna work differently even between dot releases 16:34:11 At a minimum, I'd expect that. 16:34:31 but as a stop gap we could 'host' the upstream pamd module relative to the role 16:34:35 We could ship fixed modules with our repo to continue supporting older releases... 16:34:38 right 16:34:55 yeah...that might be the only "good" way to do it 16:35:22 or create a dependent role that has those fixed items so they don't need to be duplicated 16:35:29 How do we bring in new changes from the upstream official module though? 16:35:49 it would be an extra thing to track. 16:35:49 shepdelacreme: you can just have a library/ dir in the role 16:36:10 also, we'd have to have an upstream-first policy: don't fix issues in our copy of the module w/o fixing it in upstream ansible first 16:36:23 easy to agree with that 16:37:04 cyberpear: i like the dependent role thing at face value but I think that'd be tricky b/c 1) you'd need to use galaxy and 2) would be pointless for people on latest or devel 16:37:40 I dont think that galaxy automatically pulls in deps at the moment, but i could be wrong, I just know they're in the middle of a big re-write 16:38:29 perhaps a better question for #ansible or #ansible-devel, but is it possible to have 'ansible-galaxy install' pull in a role without having that role explicitly run when the depending role is run? 16:38:37 I _think_ we could do something really hacky where we get_url the latest here via the github raw link and then still use it in a subsequent task 16:38:39 yes, it does if it's listed as a dependency in meta/main.yml 16:39:07 cyberpear: ah ok 16:39:39 what about making the library dir a submodule pointing at another repo that houses "fixed" modules 16:40:04 o/ apologies for being late 16:40:06 shepdelacreme: that's not a bad idea 16:40:06 that could work, then only clone w/ submodules when on an older ansible 16:40:09 that way it can be used across all the different repos without having to keep them all in sync 16:40:11 odyssey4me: n oworries 16:40:18 yeah that wfm 16:40:44 ok so submodule at /library inside roles that point to fixed modules, any objections there? 16:40:44 does the git-1.8 in rhel 7 support submodules? 16:40:49 not from me 16:41:02 (I always use the rhscl version, currently rh-git29) 16:41:18 +1 to /library submodule 16:42:00 cyberpear: do you know how galaxy interacts with submodules when publishing? 16:42:00 Submodule support has been available in Git since version 1.5.3. 16:42:02 I've never tried 16:42:11 no experience w/ galaxy and submodules 16:42:15 nor galaxy pushing 16:42:20 https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial 16:42:27 always use galaxy w/ git repos internally 16:42:42 lets try that path and if it doesnt work well with galaxy we can revisit, any objections? 16:42:57 none from me 16:43:43 #agreed create a submodule at /library to house patched modules in order to support older ansible releases 16:44:12 ok so odyssey4me is here and I want to respect his time so lets talk merger stuff now for a bit, cool? 16:44:44 #topic merger with ansible hardening 16:45:26 odyssey4me: what do we gotta do to be able to start leveraging the openstack infra for testing? 16:45:33 TBH I've not had much time to look into any of the action items from last week. I'm not sure if any others have managed to. 16:46:11 ok i'll table the follow-up agenda items then 16:46:41 defionscode That's a good question. Let me make a note to follow up on that - where do the meeting logs go so that I can have them handy for that discussion. 16:47:36 odyssey4me: at the end of the meeting zodbot will show the url but they are all available here https://meetbot.fedoraproject.org/sresults/?group_id=ansible-lockdown&type=channel 16:48:12 https://meetbot.fedoraproject.org/ansible-lockdown/2018-10-17/hardening-lockdown_merger_first_steps.2018-10-17-14.04.html 16:48:20 #action odyssey4me to follow up internally regarding ansible lockdown's use of openstack infra 16:48:41 cyberpear: that was the first meeting though 16:48:53 ok, got them - thanks, and apologies for not already following that up - it's been a rough week 16:49:02 https://meetbot.fedoraproject.org/ansible-lockdown/2018-10-17/hardening-lockdown_merger_first_steps.2018-10-17-14.04.html 16:49:16 lol, same link 16:49:16 odyssey4me: shit happens, we'll all be alright ;) 16:49:19 <--- nitwit 16:50:15 odyssey4me next q, have you any clue what we need to do to get a green light on adding rackspace branding to lockdown stuff? 16:50:24 if it's not desired/wanted that's fine with me too 16:50:26 given cloudnull and mnaser aren't around, I guess all the action items will have to carry forward 16:50:32 yep totally 16:51:04 I’m semihere 16:51:22 haha 16:51:28 I defer to odyssey4me though for any decision! Dunno about branding stuff tho 16:51:36 on rackspace branding - I'll have to follow up on whether that's desired and what the terms would be... 16:52:08 mnaser can make decisions about vexxhost branding though :p 16:52:17 ok, thats entirely your call, it could just be openstack branding or nothing at all, it's really up to you folks 16:52:50 I think as an open source project it’d be better to leave brands out of it. But I don’t mind having us there 16:53:32 +1 16:53:40 there is a formal partnership with MPG and RedHat (IBM now I guess) around this project hence some branding on the landing page, it's not an exclusive club though 16:54:06 but alright, just lemme know if the desire changes or starts leaning one way or another 16:54:17 Cool, will do. 16:54:48 #action odyssey4me to find out whether Rackspace wishes to add branding, and what the terms are if they do. 16:55:30 mnaser: odyssey4me regarding Ubuntu, right now AH has content work with Debian based distros and I think this was made prior to there being an Ubuntu STIG Benchmark, any object to having Ubuntu hardening exists as a function of that role? versus having rhel7 stig content be usable against ubuntu? 16:56:02 last meeting it seemed that odyssey4me and cloudnull were delegating that decision to mnaser hence the question now 16:58:02 also more of a non-committal question, odyssey4me cloudnull mnaser (and anyone else) would you like to be listed as active members in the Lockdown working group? 16:58:21 doesnt bind you to anything other than the occassional person seeing that you're active in this circle 16:58:36 I'm happy to be listed - I doubt cloudnull will have an issue with it either. 16:59:25 #action defionscode to add odyssey4me and cloudnull to active members list on the community page 16:59:43 mnaser is probably tied up so we can defer the ubuntu question until next time too 17:00:16 shepdelacreme: cyberpear odyssey4me mnaser (or others) have anything to add regarding merger talks? 17:00:37 shepdelacreme: is already doing some proof of concept work using the ansible-hardening docs builder on ansible-lockdown stuff 17:01:49 * cyberpear has nothing at the moment 17:03:09 ok, it's the top of the hour, cyberpear & shepdelacreme are you able to continue on or shall we push remaining agenda stuff to next week? 17:03:18 im fine either way 17:03:31 I'm still here 17:03:43 I can keep going for 30 min 17:03:53 ok lets proceed then 17:04:12 #topic how to best address manual and not remediated tasks 17:04:47 my idea is to have a callback plugin that just outputs the rule data (maybe name + rule id) at the end of a playbook run 17:05:09 but that could be not-desired if teh content is being used as part of a larger playbook with several other roles 17:06:02 do role-included callback plugins run by default? 17:06:15 cyberpear: I think you'd still need to whitelist it 17:06:25 I could see it being useful to aggregate the results of those things at the end instead of mixed in the output as it is now 17:06:26 * cyberpear thought so, but wasn't sure 17:07:01 tbh i havent written a callback plugin a while so maybe the behavior changed, if it's whitelisted then I suppose users are able to dictate if it's enabled or not 17:08:02 should it be sufficient to output "$RULE_ID $SEVERITY $RULE_TITLE"? 17:08:03 what would be really awesome is a results-xccdf.xml that could be imported to STIG viewer 17:08:08 I remember that we wanted to do something similar in AH, but never figured out a good way. 17:08:42 I think we thought it better to have the results recorded in a file which could then be imported into some sort of tool. 17:09:12 cyberpear: you up to make that? Im not against it, but I really dont wanna mess with XML more than i have to 17:09:31 odyssey4me: yeah that's what cyberpear is alluding to 17:09:47 im personally not an xccdf schema expert but im not opposed to the idea 17:09:50 It may be nice to use a callback to drop it into a sqlite DB or an xml file. 17:10:02 Put it on the "wish list"... unlikely I'll be able to allocate time to it in the next few months. 17:10:30 #idea generate xccdf xml report that can be ingested into DISA's STIG viewer 17:11:22 ok so short term we can do the callback route with plain text output on stdout? Then we can iterate from there? 17:11:52 odyssey4me: i like the sqlite idea though i wouldnt want it to bork the run on account of someone not having sqlite locally 17:12:14 especially ansible tower users 17:13:42 shepdelacreme: cyberpear odyssey4me any objections to just having a stdout report for now via callback? 17:13:51 nope 17:14:00 nope, that's what AH does now actually IIRC 17:14:19 odyssey4me: oh? so there is a callback plugin in your repo? i didnt notice it 17:15:33 #agreed callback plugin to output manual/nonremediated benchmark rules 17:15:46 oh, it got removed https://github.com/openstack/openstack-ansible-plugins/commit/bfc26ac6983bc97201403be36f6d564a3ab7031d 17:16:00 #action defionscode to make mvp of callback plugin for manual/nonremediated rules 17:16:24 it was a simple thing which wasn't great anyway, you can do something similar with built-in plugins these days 17:16:29 odyssey4me: ok cool 17:16:47 alright this topic is done i think 17:16:54 #topic Style Guidelines 17:17:10 a simple one 17:17:34 line length, shoudl we have a line length limit? I vote no, for this type of project I think it would make things less readable to enfroce a length limit just cuz 17:18:11 I vote no...I dislike arbitrarily short line length limits in general 17:18:27 I'm generally in favor of limited line lengths 17:18:45 but it'd be hard to implement for benchparse 17:18:49 so I'm fine leaving as-is 17:18:56 apologies - I need to run, something just broke that needs my full attention 17:19:08 * cyberpear 's commits will generally be limited in line-length regardless 17:19:09 odyssey4me: no worries, thanks for making the time 17:19:26 cyberpear: yeah I dont think we should refuse them in a dogmatic way 17:19:32 but simply not enforce/require it either 17:19:44 +1 17:20:05 #agreed no line limit lenght, but allow for changes/commits that do line breaks/continuation 17:20:14 ansible upstream also ignores the line-length limit item from pep8 17:20:29 ok, this one i think we all agree on already 17:20:44 removing severity, audit, and patch tags 17:20:55 severity tags go to the include level in main.yml 17:21:03 and audit/patch tags go away completely 17:21:03 +1 17:21:20 audit/patch is handled at '--check' and ansible_check_mode 17:21:25 yep 17:21:37 shepdelacreme, you're on board? 17:21:37 +1 17:21:40 ok 17:22:09 #agreed removing severity, audit, and patch tags severity tags go to the include level in main.yml and audit/patch tags go away completely 17:22:41 remove audit playbook? i think it's safe to do at this point 17:22:48 so +1 from me 17:23:18 What audit playbook? 17:23:42 in the rhel7-stig role, there's audit-cat1.yml and fix-cat1.yml 17:23:45 I mean yes I agree the audit playbooks should go away but I thought they were removed 17:23:57 oh ha i must have been looking at an old commit hash 17:24:05 cyberpear: not anymore 17:24:13 * defionscode is not sure how he missed htat 17:24:16 cyberpear I don't see that in devel 17:24:22 k, at some point, would be nice to rename fix-cat1.yml to cat1.yml 17:24:33 yeah i think we can do that now 17:24:34 to be consistent across roles 17:24:41 it would be a non breaking change 17:24:44 ahh looks like RHEL6-STIG still needs work 17:24:51 to remove the audit playbooks 17:25:00 #agreed rename fix-cat* to cat*.yml 17:25:16 maybe thats what i was looking at 17:25:26 agree with the rename 17:25:32 next thing 17:25:59 ensuring blocks have names, even though it has no output utility at the moment it's still a +1 for dev-exp purposes 17:27:12 I agree with that...however what is the policy for naming tasks under the block 17:27:31 +1 names on blocks, even though they are not printed at runtime (yet) 17:27:42 i think that should stay the same shepdelacreme 17:28:11 I've generally been keeping the task name the same as the stig title, except when it's a complicated block, then I explain what's going on 17:28:23 right 17:28:59 #agreed blocks should be named, and should follow convention unless it's complex and further details are warranted 17:29:00 The block name should be the official STIG title or whatever...tasks underneath can have a different title that explains the action a little better I think 17:29:12 shepdelacreme: the problem is output 17:29:47 lets go into details next week on block specifics, for now we agree it should be used 17:29:59 it's 30 after now so you have to go, right? 17:30:00 yeah no I am agreeing with you and cyberpear :) 17:30:10 kk 17:30:23 Lets finish up these style guidelines 17:30:30 ok 17:30:34 then I need to leave 17:30:58 'yes/no' to actual boolean values? I think i was hitting yamllint issues with yes/no values 17:31:05 what do you guys think 17:31:22 would be easy to sed for it i think 17:31:34 I'm good with moving to true/false 17:32:37 I'm partial to yes/no 17:32:46 they are native booleans in yaml 17:33:02 and more English-like 17:33:34 I don't think we have "yes" and "no" (strings) anywhere 17:34:01 on my .yamllint, I have 17:34:02 truthy: disable 17:34:04 a lot the "changed_when" stuff uses yes/no 17:34:24 not sure if that made it to the .yamllint in rhel7-stig 17:34:47 yeah truthy: disable is in there 17:35:58 hm ok we should be consistent in any case 17:36:09 +1 for consistency 17:36:11 we can just as easily convert 'true' => yes 17:36:23 and 'false' => no 17:36:27 +1 17:36:36 i'll concede 17:36:37 agreed 17:36:53 #agreed standardize on yes/no for BOOL 17:37:00 however :) 17:37:06 :O 17:37:18 this is just for something like "changed_when: no" right? 17:37:39 and for rhel7stig_RULEID: yes/no 17:37:56 and not "changed_when: somevar == false" 17:38:08 obviously that syntax is garbage but hope you get the gist 17:38:24 correct, at that point it's more python than yaml 17:38:36 ok I'm good with yes/no then 17:38:46 ok 17:38:49 next style item 17:38:57 move "myvar | failed 17:39:00 syntax 17:39:01 yes, once you get more complicated, you are in python land 17:39:07 to myvar is failed 17:39:12 +1 17:39:13 +1 17:39:17 ok 17:39:31 it can be done in a way that maintains compat w/ ansible-2.4 17:39:42 #agreed move away from "myvar|failed" to "myvar is failed" 17:39:43 99% of the time it "just works" w/ 2.4 17:40:01 cyberpear: is there a trick for the 1%? 17:40:16 the only caveat is "myver is version('>=', '2.4')" 17:40:27 "myver is version_compare('>=', '2.4')" 17:40:33 ^use the latter 17:40:48 it exists in 2.4, the former doesn't 17:41:11 that's the only one I've run into where the autoconverter doesn't do it optimally 17:41:39 don't remember how much we use that, though 17:41:47 ok well that's 3 dot release ago so I dont know that i'd add those changes as a 'guarantee' but I wouldnt refuse contribs/changes that allow for 2.4 support just not 'promised' 17:41:55 +1 17:42:07 kk 17:42:10 last item 17:42:43 i have a soon-to-be PR'd to upstream module that can parse oscap results.xml and expose the important data as facts 17:42:47 it's a facts module 17:43:08 should we start making CI check for pass % on oscap eval? 17:43:26 it can be done at the severity or at the global score level 17:43:38 or both 17:44:15 hmm 17:44:41 how would that work for in progress roles? The builds would be failing until they hit a score level? 17:46:25 shepdelacreme: it can be tuned 17:46:33 initially the pass criteria can be 0 17:46:42 and adjusted as it makes sense to 17:47:19 ok 17:47:40 cyberpear any opinions? 17:47:44 sounds great to me 17:47:56 ok 17:48:08 oscap can process DISA content, as well 17:48:21 *DISA benchmarks, rather 17:48:31 #agreed once accepted into the upstream, use the scap_facts module to trigger failures in CI for roles 17:49:01 cyberpear: the problem, AFAICT, is that sans a tailoring file, you cant have it fail conditionally 17:49:10 i think it does a non zero rc if any check fails 17:49:57 ok I gotta jump 17:50:04 ttyl 17:50:32 my module exposes a "scap_facts: min_high_score=100 min_medium_score=50" 17:50:35 type of interface 17:51:10 cyberpear: i added you to the repo so you can see the WIP 17:51:20 it's functional now, just want to make sure I addressed any kinks 17:51:20 k, I'll look when I get a chance 17:51:52 cyberpear: anything else you want to go over before we wrap up? 17:52:03 close it out! 17:52:14 alikins_: you're here no? anything from you? 17:52:42 going once... 17:53:00 alright, thats a wrap 17:53:02 #endmeeting