17:03:22 #startmeeting openstack security group 17:03:23 Meeting started Thu Mar 12 17:03:22 2015 UTC and is due to finish in 60 minutes. The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:26 The meeting name has been set to 'openstack_security_group' 17:03:29 o/ 17:03:34 o/ 17:03:34 o/ 17:03:36 o/ 17:03:38 Hey everyone, full house today! 17:03:40 o/ 17:03:49 hey all 17:03:52 o/ 17:04:06 hi 17:04:33 glad to see the prodigal nkinder 17:04:42 woot! hey nkinder ! 17:04:59 hey guys 17:05:08 hullo! 17:05:13 serious full house today =) 17:05:16 ok agenda for today, I actually don’t have much, lots of things that were in flight are still erm, flying. 17:05:19 nkinder hope youre feeling better 17:05:23 2 weeks in a row is a record for me this year I think! 17:05:26 tmcpeak: nkinder: bdpayne any updates? 17:05:31 d-9: thx 17:05:35 small Bandit update 17:05:50 hyakuhei: nothing big. We can talk about the OSSN template and "affected software/services" 17:05:50 I have a brief book update 17:06:18 ok cool, anything else? 17:06:30 tkelsey: How’s anchor coming along? 17:06:46 yeah, it going well :) 87% coverage or there about 17:07:06 still pushing tests 17:07:21 Jolly good, thanks for getting the functional tests in too! 17:07:34 Nice to know it actually works, as well as passing unit tests :P 17:07:35 ah yes, good to have those 17:08:02 ok, lets talk about the book before what I suspect will be a longer OSSN discussion 17:08:05 #topic security guide 17:08:17 so a few updates 17:08:45 we are working towards a book release that is aligned with the release coming out next fall 17:08:47 whatever that is, L? 17:08:49 * bdpayne loses track 17:08:53 Liberty 17:08:57 thanks ;-) 17:09:20 one of the big things we want there is to fill out the content specific to openstack core services such as Nova, Cinder, Keystone, etc 17:09:47 and one of the big things we want within _that_ is to have good recommendations around the policy.json files 17:09:55 so... if you have knowledge and are able to help with such things 17:10:00 we'd love some assistance 17:10:01 :-) 17:10:17 +1 17:10:29 to get involved, just ping me here in IRC, email me, or similar 17:10:32 that's about all that I have 17:10:42 bdpayne: I can lend some assistance around policy.json 17:10:50 nkinder that would be great, thanks 17:10:58 I'll ping you :-) 17:11:02 bdpayne: sounds good 17:11:03 I've got the policy.json mapping doc'ed for keystone. 17:11:03 bdpayne: There’s (likely) going to be a talk on that at the summit :) 17:11:16 not sure if we want that for every service. 17:11:27 yes, I was thinking I'd ping the author of that talk hyakuhei 17:11:29 bknudson: yeah, that is a nice change 17:11:46 bknudson you have a pointer to that? just curious... 17:11:48 might be better to have it in the docs rather than in policy.json. 17:11:52 ... curious what it looks like 17:12:07 Sweet. Ok lets talk about OSSN format? 17:12:09 bdpayne: https://review.openstack.org/#/c/155919/ 17:12:13 #link https://review.openstack.org/#/c/155919/ 17:12:20 thatnks, take it away OSSN 17:12:30 #topic OSSN 17:12:36 nkinder: still fast. 17:12:45 nkinder: wwantto introduce it? 17:13:00 I saw some of the discussion hyakuhei was havint with tmcpeak on the "affected services" format in OSSNs 17:13:21 Typically, we go for a comma separated list like "nova, glance" 17:13:33 we also have versions in there - "icehouse, juno" 17:13:41 link in question: https://review.openstack.org/163041 17:13:44 #link https://review.openstack.org/163041 17:13:55 the idea is that a simple format can be parsed 17:14:18 So you can search for (with some tool that doesn’t exist) all OSSNs affecting “Keystone” for example 17:14:19 ...hence a tool could be written to check to see if an OSSN applies to a deployment 17:14:30 exactly 17:14:32 Yep 17:14:46 Now at the moment, we also basically present OSSNs to the world in that same format 17:14:47 So we also have strange cases like the FREAK or POODLE OSSNs... 17:15:03 * hyakuhei shuts up. Please continue nkinder 17:15:07 For these, we basically say "Affects all the things" 17:15:15 which is accurate 17:15:46 basically, these issues don't fit the mold, as they affect databases, message brokers, crypto libraries, etc. 17:16:16 Here's my opinion on it... 17:16:28 Today's OSSN format is really intended to be consumed by humans 17:16:31 ...not tools 17:16:48 We want to get to a parseable format where tools make sense, but we're not there. 17:17:09 to get that I think we'd want something more like tags 17:17:10 I think having a structured format alongside of the "human" format is where we need to end up 17:17:14 you could maybe take a similar approach to what the vmt are doing with ossa 17:17:22 So my question is do we want to continue with a do everything format. Or write something more ‘meta’ that gets parsed into various outputs 17:17:27 gmurphy: I was hoping you’d chime in 17:17:31 gmurphy: yeah, I looked at some formats 17:17:32 we have the advisory content in yaml (parsable) and then render that to .rst 17:17:33 How does the VMT do it 17:17:39 hyakuhei: transformation would be ideal 17:17:48 one master format, spit out all of the other ones we want 17:17:53 +1 17:17:54 nkinder: I think I agree, though it does raise the bar for entry a little 17:17:55 just a sphinx plugin i wrote 17:18:01 it is very low tech but does the job 17:18:08 gmurphy: got any links we could look at (git etc)? 17:18:24 think we just populate a jinja template using values from the yaml file 17:18:28 yeah 17:18:31 one sec 17:18:53 #link http://git.openstack.org/cgit/openstack/ossa/tree/ 17:18:59 is the top level project 17:19:19 yeah, that looks nice 17:19:26 and this is the crappy plugin - http://git.openstack.org/cgit/openstack/ossa/tree/doc/source/_exts/vmt.py 17:19:45 which basically fills in this template http://git.openstack.org/cgit/openstack/ossa/tree/doc/source/_exts/rst.jinja 17:19:55 That’s a lot more readable than I thought it would be (the yaml) 17:20:08 yaml seems nice for the root format 17:20:10 yeah. eventually i want to get the ossa data version information more accurate 17:20:10 So I can get behind something basic like this 17:20:13 do you have a gates to test the yaml isn’t horribly broken etc? 17:20:14 chair6: see how much better yaml is than JSON? :P 17:20:25 so i can run a db query etc 17:20:25 tmcpeak: quite or we put you back in the corner. 17:20:25 I was looking at things like CVRF last year... 17:20:35 hyakuhei still bitter about yaml.. 17:20:39 which is a nice standard, but probably more heavyweight than we need 17:20:43 +1 17:20:52 ...though we can always transform yaml to CVRF if there is a need in the future 17:21:01 yeah exactly 17:21:11 I think hyakuhei comment about a low bar is important 17:21:34 So you take yaml and munge it into jinja 17:21:41 at which point it can become whatever you want? 17:21:58 yeah. 17:21:59 basically 17:22:30 nkinder: yeah, but at least with a format like yaml we could have the gate do more automated checks than it does today possibly ? 17:22:43 yeah, I think so 17:22:48 and also little trip hazards like trailing whitespace and line length go away 17:23:36 do we want to publish the yaml somewhere too (besides git)? 17:23:42 There’d be a body of work to convert (manually or by magic) existing OSSN into whatever the new format is too 17:23:47 for ossa ? 17:23:48 That way a tool can be used to scan the yaml from a known location 17:24:08 hyakuhei: I think that would be manual... 17:24:09 yeah security.openstack.org = output of that project 17:24:14 nkinder: +1 17:24:25 only a few hours work split between a couple of us 17:24:26 could probably get at least 80% of the work done with a little magic 17:24:46 yeah, shouldn't be too bad with 45 notes 17:25:11 ok, well POC of yaml and a conversion to something close to what we publish today is the first step 17:25:23 I can work with gmurphy on that 17:25:41 steal whatever I can, then tweak it :) 17:26:06 yep. go for it. 17:26:25 ping me if you have any problems. 17:26:38 gmurphy: will do 17:27:07 nkinder: are you going to put the yaml poc in git? Easiest place to review/comment I imagine 17:27:28 I mean security-doc on git, obviously 17:27:56 hyakuhei: yes, yaml in git 17:28:03 it will be the "source" format 17:28:22 we will need to tweak the gate jobs too 17:28:29 Yeah 17:28:35 This is quite exciting :) 17:29:20 Anything else on OSSN today? 17:29:46 I copied bdpayne's note, it's all his fault 17:29:50 #topic Any Other Business 17:29:53 Nothing notable. There's stuff in the queue, some assigned (I think everyone who owns something is aware that it needs to be done) 17:30:10 Great! Yeah I’ve got one that I hope to write tomorrow 17:30:16 (not really sure where the week went) 17:30:42 hyakuhei: you know what I'm going to ask, don't you? 17:31:34 The developer guidelines 17:31:37 yep :) 17:31:46 where are we going to put them, what's the next step 17:31:48 Yeah they’re waiting on the discussions I’m having about making the OSSG OpenStack proper 17:32:01 As right now we don’t have a sensible place to publish them other than the wiki 17:32:12 well wiki could be good 17:32:16 We _could_ put them there for now 17:32:19 lots of OpenStack guidance goes there 17:32:30 Yeah and lots of stuff gets lost in the noise 17:32:37 true 17:32:46 If you want to create a wiki page under security and move them over I’m happy with that 17:32:57 what's the end game? 17:33:02 Though ideally I want them nicely formatted and linked somewhere off security.openstack.org 17:33:18 They look so pretty in GH Markdown :( 17:33:29 that sounds worthwhile, so that's blocked on your discussion about integrating OSSG as a proper group? 17:34:18 It would complicate things unduly to try to push stuff there right now 17:34:23 So wiki is fine 17:34:37 ok, should we publish them as is or do we need to do more editing? 17:34:42 some of them aren't consistent with the others 17:34:45 for example XSS 17:34:58 There’s some work required on some. I don’t have the time to do that this week. 17:35:09 like this: https://github.com/openstack-security/Developer-Guidance/blob/master/xss.md 17:35:15 sicarie: You’re a doc ninja, do you have any cycles next week to look at the content? 17:35:20 sure 17:35:41 awesome! 17:35:43 Yeah the XSS one isn’t great I’ll see if ukbelch can re-write it to be more inline with the others 17:36:04 sure 17:36:26 whoever did this: https://github.com/openstack-security/Developer-Guidance/blob/master/todo.md thank you 17:37:02 no worries 17:37:24 Bandit version pin imminent! code freeze is tomorrow EOD 17:37:34 oooh 17:37:41 then Monday I'm going to try really really hard to break it 17:37:42 good stuff tmcpeak 17:37:48 then version pin Monday by EOD 17:37:52 * bknudson needs to get keystone change ready. 17:38:20 if anybody else can carve out time to try to break Bandit Monday, that would be awesome 17:38:59 tmcpeak: have you run it over all the things in openstack/*? 17:39:06 gmurphy: yep, mostly 17:39:23 I'm probably missing some of the oslos, and my versions might be a bit old, but yeah, I've run against most projects 17:39:41 ok. cool. 17:40:30 that's probably it for Bandit this week 17:42:09 anything else guys? 17:43:58 well at some stage i want to revist the ossa metrics stuff. 17:44:13 gmurphy: yeah that’s the one thing we didn’t manage at the mid-cycle 17:44:20 Maybe we can try to get a design session on it 17:44:31 well me and jamie did a few -> https://etherpad.openstack.org/p/ossg-metrics 17:44:52 So we’re still in tuning what was your feel for it at the moment 17:45:16 we both got pretty similar answers for some things 17:45:31 a couple were ambiguous / it depends type things 17:45:41 but with the ossa data in a git repo 17:45:54 That looks pretty good actually 17:46:02 we could submit scores and nit the differences in rewiew 17:46:25 the IBM x-force team also has cvss scores for the vulnerabilities. 17:46:49 cool. would be interesting to pull that info in too. 17:47:18 i guess what i would ultimately like to get to is - is the proposed standard more accurate than cvss etc 17:47:38 gmurphy: I like that idea 17:47:51 well CVSSv2 is completely inappropriate for cloud applications 17:48:00 and we have the cvss info from red hat.. i'll pull in the xforce stuff too one rainy day.. 17:48:04 yeah. i agree. 17:48:05 hypervisor breakouts rank ~5 I think 17:48:13 “local privesc” 17:48:25 but hopefully we could demonstrate that with pretty graphs :-) 17:48:33 Ok so actions regardinging metrics? 17:49:02 well if anybody else wants to jump on that etherpad and have a go at rating those vulns that would be good 17:49:27 cool, I'll have a stab at it 17:49:30 tmcpeak: sicarie - either of you have time? 17:49:32 excellent 17:49:36 otherwise i will try to build a bigger sample base 17:49:50 and compare against cvss 17:49:54 hyakuhei I could probably take a look next week 17:50:15 That’d be great! 17:50:25 ok I think that’s a wrap, any last minute stuff? 17:50:59 Cool, thanks everyone! 17:51:02 #endmeeting