17:01:17 #startmeeting Security 17:01:17 Meeting started Thu Nov 19 17:01:17 2015 UTC and is due to finish in 60 minutes. The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:21 The meeting name has been set to 'security' 17:01:25 #chair tmcpeak 17:01:25 Current chairs: hyakuhei tmcpeak 17:01:28 sup yall 17:01:30 hi 17:01:32 how it do? 17:01:34 howdee 17:01:34 hi 17:01:35 hi 17:01:39 o/ 17:01:41 hi 17:01:49 hi all 17:02:11 We’ll give people a second to roll in and then get started :) 17:02:28 Sorry if I am unresponsive, need to mutli-task in a meeting now. 17:02:46 no worries michaelxin - thanks for swinging by :) 17:03:00 hi all! 17:03:01 #link https://etherpad.openstack.org/p/security-20151119-agenda 17:03:05 Hey nkinder ! 17:03:09 hyakuhei: thanks. 17:04:16 ok gues, so take a quick look at the Agenda and add anything required. 17:04:31 Sadly we don’t have a redrobot here 17:04:47 we haven’t spoken since last week so I don’t have an update on the location yet 17:04:50 hyakuhei: I met with his boss this week. 17:05:05 talk about hosting the event in rackspace. 17:05:25 They are waiting for our decision. 17:05:56 cool, so… soon? I mean it’s only what, ~11 weeks away 17:06:16 haha 17:06:19 plan early 17:06:24 It’ll fly by! 17:06:39 When will be a good time to decide? 17:06:51 I'm in for Texas :) 17:06:59 One of the reason is that we want to book for conference rooms. 17:07:02 well asap really because if that falls through we’ll have to find something else soon 17:07:08 +1 17:07:30 should check if there's other conferences or something that people want to go to 17:07:35 (I don't have any) 17:07:35 I expect we’ll all be backin texas in April/May 17:07:39 bknudson_: good idea 17:07:52 +1 17:08:05 So, what's the plan here? 17:08:14 has barbican picked a date? 17:08:23 I can talk with them any time. 17:08:44 11 weeks time seems rather soon for the mid-cycle, we will loose a lot of time over the vacation 17:09:00 It’s because of the release cycle dg 17:09:07 So you can commit by/for a certain milestone 17:09:25 yeah...but... 17:09:38 https://wiki.openstack.org/wiki/Sprints 17:09:40 still, Im +1 for somewhere sunny and warm in january 17:10:02 can we have a 2 month meeting? 17:10:07 lol 17:10:12 haha 17:10:21 Sounds good 17:10:24 yeah I guess it would be better to finalize now so people can book travel before everybody collectively loses interest in work in mid December 17:10:29 +1 17:10:42 Want it all locked in before people start being AFK for holiday season 17:10:47 yeps 17:10:54 +1 17:10:56 so hyakuhei you happy with Austin? 17:10:56 makes sense 17:11:03 SA or wherever we're going? ;) 17:11:05 I think it was San Antonio right ? 17:11:13 Yes. 17:11:15 Yeah, though I don’t know how many HP can send 17:11:17 San Antonio 17:11:21 ok cool 17:11:27 HPE? 17:11:35 cool, michaelxin: want to check if it's available? 17:12:05 what's available? 17:12:07 bknudson_: yeah HPE 17:12:12 *sigh* 17:12:16 lol 17:12:16 the room 17:12:19 (s) 17:12:26 Typing HP is like 33-50% easier than typing HPE 17:12:35 who's on first? ;) 17:12:39 truth 17:12:49 o/ 17:12:53 We already booked 5 break rooms. And in the process of booking two large conferences. 17:13:01 nice 17:13:02 excellent thank you michaelxin 17:13:11 ok cool, I guess should we fire up the etherpad then? 17:13:34 #link https://etherpad.openstack.org/p/security-mitaka-midcycle 17:13:40 Barbican's mid-cycle will be from Mondy-Wednesday. 17:13:46 Good idea, happy for unconference style again though we can lay out a few more stable “must haves” too 17:13:48 Ours will be from Tuesday-Friday 17:14:10 So, there will be some overlaps for both teams to co-operate. 17:14:31 Excellent, I want Security people to be able to contribute to the Barbican setuff properly 17:14:44 which might mean limiting what gets done on Tuesday 17:14:55 Lisa wants to get confirmation from us. 17:14:57 ok so what are our dates? 17:15:01 Jan 11-15? 17:16:21 geeze, I suck at picking colors 17:16:22 Barbican Midcycle: Jan 11-13, M-W (averages 20 attendees though it may be higher w/ Castle location) 17:16:22 OSSP Midcycle: Jan 12-15, T-F (averages 15 attendees though it may be higher w/ Castle location and Barbican overlap) 17:16:48 ok cool 17:17:07 ok so as always, please add your name to the list if you would like to attend and think that there's a chance you might be able to 17:17:14 I'll see if I can get some more people from IBM to go. 17:17:23 also add any proposed agenda items 17:17:26 tmcpeak: +1 17:17:32 bknudson_: +1 17:17:43 softlayer is in tx. 17:17:53 So, the decision is made for the time and location? 17:18:18 I think so 17:18:23 seems like it 17:18:24 hyakuhei: Great. 17:18:44 I will talk with Barbican guys and let them know this. 17:18:51 awesome 17:19:07 So, we can move with booking rooms and other preparations. 17:19:16 michaelxin: that would be awesome, thanks man 17:19:20 Ok lets roll onto the next point, I want to juggle the agenda a bit to bring this up the stack while michaelxin is around 17:19:25 #topic FuzzTest 17:19:29 #link https://www.rdoproject.org/blog/2015/11/openstack-fuzztest/ 17:19:32 So this is interesting ^^ 17:19:38 tristanC: You around? 17:19:54 There’s obvious overlap with Syntribos here 17:20:01 hey, well I figured I might as well present this here 17:20:26 though it have been quite a rush since the summit, so I didn't want to "butt in" the agenda 17:20:34 in keystone we implemented JSONSchema over most of the API to help with this. 17:20:42 Yes. Tristan showed me this during the summit. 17:20:47 oh this is cool 17:20:53 No it makes sense to push it up here, lots of the stuff on the agenda are status checks 17:21:04 bknudson_: does that mean you can get the jsonschema through rest calls? 17:21:06 also, this.. https://review.openstack.org/#/c/216303/ <_< 17:21:18 so for the uninitiated (such as myself), what are the differences between the two tools approaches? 17:21:24 It is cool to see people come up with different solutions for same problems. 17:21:27 elmiko: no, we don't have that yet... the jsonschema is used to validate the input 17:21:33 bknudson_: ack, thanks 17:22:08 it would be easy enough to publish the JSONSchema (although I think there's custom validators) 17:22:23 tmcpeak: restfuzz generates inputs based on api definition while syntribos generates input based on pre-recorded trace 17:22:29 yea, i was just curious (something similar came up during api-wg meeting) 17:22:41 oh cool 17:22:50 tristanC thats cool 17:22:56 i will have a play :) 17:22:58 is the api description generated automatically? 17:23:20 tmcpeak: I couldn't figure a way to do that cross project, so it's currently hand written 17:23:33 I will play with it for sure. 17:23:37 I wonder if the AST can help 17:23:42 tmcpeak: one cool usecase imo is that it also digg the log and display new uniq traceback 17:24:10 if we parse the python code for a services rest api, detect the appropriate decorated functions and inputs, and then generate the description automatically from that 17:24:17 tmcpeak: sadly each project seems to have a different approach for api routing, and such ast introspection seemed hard at first glance 17:24:30 I like this a lot tristanC 17:24:34 tristanC: agreed, it does seem hard. Prohibitively hard for a PoC 17:24:43 tmcpeak: it would better, imo, to link into the auto-generated api doc impls that working about. like a swagger parser would be ideal for this. 17:24:51 keystone also has JSONHome to describe the routes 17:24:55 elmiko: +1 17:25:00 (which is published) 17:25:01 elmiko: good point 17:25:25 yeah no sense reinventing the sheel… swagger parser does seem ideal 17:25:27 thanks for the feedback guys, I'm not sure this needs to be gone over thoroughly during this meeting 17:25:29 something like the json-home doc would be perfect for this effort as well 17:25:30 it should be easy enough to switch from JSONHome to swagger 17:25:41 yea exactly 17:25:43 that part could be a plugin system 17:25:51 though I'd like to work some more on this, and figures a way to integrate with other framework so that the wheel is not reinvented here 17:26:10 Will you be at the midcycle tristanC ? 17:26:24 Projects like this often get a really big boost with a hands on sprint 17:26:25 I can't say for now, I'll try to yes 17:26:44 Cool 17:27:00 ok any questions for tristanC peoples? 17:27:05 I'd prefer a clearish definition of the goals of each syntribos and RestFuzz so that we don't duplicate efforts 17:27:13 +1 17:27:24 I mean the goals are apparently pretty similar, different approaches, which is cool 17:27:38 maybe we can plugin the different approaches in some way and leverage common core 17:27:47 would both syntribos and restfuzz be able to make use of a swagger definition? 17:28:02 if so I can try to move it up on my list o' things to do. 17:28:36 imo, adding swagger generation to any service project has big win potentials beyond just fuzzing 17:28:44 I can see how both would benefit 17:29:32 if I have questions about publishing JSONSchema or the swagger I've got a contact ( elmiko ) 17:29:46 ;) 17:29:50 elmiko, aka elswagger 17:29:58 * elmiko chuckles 17:30:02 rofl 17:30:12 ok, lets do a quick run through of $thethings 17:30:19 bknudson_: you might find this interesting too, http://specs.openstack.org/openstack/api-wg/guidelines/api-docs.html 17:30:21 tkelsey: anything on Anchor this week? 17:30:29 #topic Anchor 17:30:31 thanks hyakuhei for picking this up :) 17:30:32 nope, nothing major 17:30:35 Nothing to report 17:30:40 #topic Bandit 17:30:58 tkelsey: want to roll it? 17:31:19 improvements to baseline stuff, config generator, other stuff 17:31:32 we just rolled 0.16.2 17:31:37 let me find the notes 17:31:59 congrats, so 016.2 is in pypy? 17:32:02 ah yeah, some dead code cleaning and similar 17:32:09 yep 17:32:18 great! 17:32:23 something we mentioned a little last meeting, but is worth touching on again 17:32:25 the config gen is interesting 17:32:35 i need to find time to properly play with it 17:32:37 the baseline system should be perfect for a project to use for a gate 17:32:52 basically regardless of how many issues you currently have, the baseline will make sure that you don't introduce new issues 17:33:08 btw - I've got someone working on enabling bandit for glance 17:33:11 so you can kind of draw a line in the sand and say "that's it, no more x, y, and z issues in my project" 17:33:23 Yeah that’s going to be useful 17:33:24 bknudson_: nice 17:33:26 bknudson_: awesome! 17:33:57 so next step for projects to use this new gate- tkelsey and I will work with the infra guys to get the job set up 17:34:01 then it's just up to projects to use it 17:34:05 nice 17:34:19 should be an easier sell though than "fix all of your issues, then implement Bandit gates" 17:34:45 Though wouldn’t it be lovely if finding issues was something projects wanted? 17:34:51 :P 17:34:56 crazy talk hyakuhei 17:35:04 hyakuhei: but then you have to fix them! :) 17:35:20 Trudat! 17:35:27 Any more bandit things? 17:35:30 oh 17:35:40 is anybody interested in increased Bandit involvement? 17:35:48 we've been a little short handed since sigmavirus24 retired 17:35:53 yep 17:36:05 interested yes, have time no 17:36:07 I'll have a little more time to dedicate to it over the next month or two as things slow down a bit for the holidays 17:36:07 I could possibly move beyond my one commit 17:36:18 hopefully next year a guy will get freed up and I'd try to get him helping with bandit. 17:36:19 What’s required? 17:36:22 is there a todo list somewhere? 17:36:29 When I wrap up my other stuff and learn more, I'll be looking to get involved with something, so that might be a possibility 17:36:32 we have bugs and blueprints in launchpad 17:36:47 #link https://launchpad.net/bandit 17:36:59 ccneill_: ah tmcpeak beat me to it :) 17:37:04 boom 17:37:05 ty 17:37:13 cool 17:37:18 something to think about, I know everybody is busy but IMHO Bandit is a lovely little project :P 17:37:30 here here! 17:37:31 tmcpeak: +1 17:37:38 cool, that should be it for Bandit :) 17:37:45 yup ypu 17:37:59 cool 17:38:02 #topic Killick 17:38:09 dg: Anything to add here? 17:38:18 Not everyone is sold on short life certificates 17:38:21 They want revocation 17:38:25 and explaining it doesn’t work 17:38:32 doesn’t magically tick their revocation box 17:38:37 so now Killick is a thing 17:38:49 #link https://github.com/openstack-security/killick 17:38:51 not touched it this week, although i might have sold it to a couple of people as a solution 17:39:03 wait, so just to understand - people want the thing that doesn't work to just work? 17:39:31 more that they dont understand why revocation doesnt work, so they want to keep doing it the dumb way 17:39:31 People want to pretend that the thing that doesn’t work does, because people who don’t know about the thing said it works. 17:39:41 ^that 17:39:46 Yeah what dg said :) 17:40:08 umm, ok. I'm fairly sure I've seen a preso or two from some smart chaps with British accents explaining why revocation doesn't work 17:40:19 yeah thats us, we are awesome. 17:40:23 ;) 17:40:26 lol 17:40:31 hehe 17:40:39 dg: and modest ;) 17:40:40 maybe we’re presenting in the wrong places. 17:40:46 however, anchor was never intended to be a 100% solution 17:40:54 it was always inteded to be used along with a traditional pki 17:41:10 anchor is very very cool, and everyone should use it (and hopefully I've got a bunch of other places wanting to use it) 17:41:22 Yarp, Anchor is more closed community, falls down for things like production edges. 17:41:26 Is it that revocation doesn't work, or is it that implementing it takes a lot of work and the revocation lists have to be checked? 17:41:38 it's that revocation is painful for certain cases 17:41:38 revocation lists can also be blocked 17:41:49 wayward710: both tbh 17:41:54 thanks 17:42:01 wayward710: CRLs are pretty non-deterministic and oftern aren’t checked, in most cases a 404 on a CRL won’t stop crypto systems working 17:42:11 and of course OCSP just isn’t a thing outside of the browser. 17:42:14 wayward710 revocation lists and ocsp mostly only work in the browser, most libraries dont support them 17:42:17 revocation does work, it's just a hassle 17:42:28 sometimes it works 17:42:43 gotcha, so that's the push to limit cert lifetimes? 17:42:59 yeah, I'd go with "works in limited cases" 17:43:09 if certs are short-lived, you accept the risk of it being compromised for a short period of time 17:43:12 Yeah, you get passive revocation, you don’t need to worry about the certificates from yesterday 17:43:15 nkinder: you do anyway 17:43:17 ...which might be shorter than a CRL update 17:43:25 hyakuhei: understood 17:43:28 typically anchor certs are shorter than CRLs or OCSP caches 17:43:33 almost no libraries check revocation status. most check certificate expirey 17:43:34 nkinder: sorry, slow fingers today 17:43:43 So yes, lets not make this an Anchor sales pitch 17:43:49 this is for hte thing that isn’t anchor 17:44:05 using validation and AuthN chains from Anchor to make smart decisions with Killick 17:44:18 or to help inform a human RA to help them make smart decisions 17:44:23 yeah, so it's really just a lightweigh traditional PKI as I see it 17:44:28 Yeah 17:44:35 some traditional PKIs can auto-issue too based off of rules 17:44:37 lightweight, pure python, easy peasy 17:44:54 Not trying to be all things PKI to all people, just enough to do sensible TLS 17:45:02 +1 17:45:30 ok any questions before we roll on? 17:45:36 thanks for the questions wayward710 17:45:38 nkinder as a certificate administrator, i dont want to be manually checking that a request meets our certificate policy 17:45:52 i want the pki to tell me that this has passed, or the following xyz rules have failed 17:46:04 nkinder: Yup, policy for PKI is a thing, you can do it with various tie-ins 17:46:13 ADCS does it with roles, EJBCA does it with entities 17:46:15 dg: yeah, understood. We do this in dogtag 17:46:28 Dogtag probably does it with some sort of ritual sacrifice 17:46:34 :P 17:46:42 generally though they work as part of a wider identity piece 17:46:54 you define cert profiles that can have rules or automated checks (or require manual approval as needed) 17:46:56 ADCS needs AD, I’m assuming Dogtag wants FreeIPA/Kerb or something 17:47:07 nah, just uses LDAP underneath it (389) 17:47:32 as a core pillar of the issuing, Killick should be able to do some more symantic analysis, like Anchor does with reverse DNS lookups etc 17:47:50 thats the current approach, it just re-uses the anchor validators 17:48:03 which has the nice bonus, that if we add functionality to anchor, we get it for free in killick 17:48:11 +1 17:48:23 Probably want to look at breaking the CA/RA apart more in Anchor 17:48:37 Thanks for the education hyakuhei :) 17:48:45 theyre fairly broken already i think... tim and I made a bunch of changes last month(?) 17:49:22 Yeah but I’m basically thinking that Killick/AnchorCA just become pluggable things. We should sync on this tomorrow :) 17:49:33 Just so we don’t chew through the rest of this meeting 17:49:47 Speaking of - nkinder want to talk about OSSNs? 17:50:15 #topic OSSN 17:50:28 #link https://wiki.openstack.org/wiki/Security_Notes 17:50:39 oh yeah, saw nkinder did some activity on this 17:50:39 The queue has 4 in it (one embargoed) 17:50:55 I have a draft written up that I'm getting reviewed by a core on the affected project today 17:50:55 #link https://bugs.launchpad.net/ossn 17:51:07 Great, nkinder let me know when you want me to take a look 17:51:08 ...for the embargoed one that is 17:51:23 hyakuhei: what tool did you use last time for reviewing the embargoed OSSN? 17:51:40 hyakuhei: we could use something like google doc, but you used something else that I can't recall 17:51:59 gitlab 17:52:04 that's right 17:52:16 OSSN-TEMP 17:52:23 Yeah, I’m not sure it’s the best but it was useful enough 17:52:27 ok, well once I have the technical review on the draft, I'll get it over to hyakuhei and tmcpeak 17:52:30 yeah worked well enough 17:52:35 cool 17:52:40 what's the deal with this one? https://bugs.launchpad.net/ossn/+bug/1497031 17:52:40 Launchpad bug 1497031 in OpenStack Security Notes "Authenticated Denial of Service in Blacklists" [Undecided,New] 17:52:50 how did this even get OSSN on it? 17:53:32 <_< 17:53:35 * ccneill_ waves 17:53:53 I wasn't sure how best to handle this issue 17:53:58 ahh ok 17:54:03 I think I asked in the openstack-security channel at some point what th do with it and OSSN was floated 17:54:05 Authenticated DOS seems legit? 17:54:18 it does seem legit, it just doesn't look like we went through the triage process 17:54:19 it's definitely a real issue, just wasn't sure of the severity 17:54:24 They’ve pushed a fix though, is there no back fix? 17:54:26 but yeah, channel works too :) 17:54:41 note that blacklist modification are admin only iirc 17:54:52 ^ yes, important note 17:54:53 yeah 17:54:55 Oh ok 17:54:59 I didn’t notice that 17:55:18 oh this is a cool bug though 17:55:26 OSSN: Admins, don’t intentionally bork your cloud. 17:55:30 the ossn task seems to have been added for extra review before dropping the security status 17:55:33 arbitrary regexes ftw 17:55:35 I suppose if it’s possible to accidentally set this situation up 17:55:49 yeah, I'm not sure what to recommend 17:55:49 yeah, but that's not really worthy of an OSSN 17:55:53 but I’d be happy enough to not have an OSSN for this as there’s a published fix already 17:56:06 would CVE be appropriate? 17:56:24 It's just a flat out bug IMHO, not necessarily a security issue 17:56:54 +1 17:56:56 it would be pretty contrived for someone to do this to themselves 17:57:17 do we have time for a brief AOB item? 17:57:22 ok so shall we close the OSSN part? 17:57:39 #topic AOB 17:57:43 thanks 17:57:48 tmcpeak: Yeah, I'll close it 17:57:51 awesome 17:57:55 at midcycle we talked a bunch about threat analysis 17:57:59 that's my contribution for the day 17:58:09 i've got buy-in from the sahara team and my local team to do this type of work during mitaka 17:58:21 legit 17:58:30 is there any chance of getting the HP threat analysis stuff we talked about during mid-cycle for reference? 17:58:31 ok that’s exciting 17:58:42 Lets chat about it on -dev 17:58:48 :) 17:58:57 yea, i have a clear thought about how we can deliver something that is useful to the community and operators 17:59:00 HPE 17:59:04 and maybe inspire other teams to do it 17:59:05 HPE are still happy to get involved / share our findings 17:59:11 cool, thanks 17:59:20 and yea HPE, sorry for the inaccuracy ;) 17:59:36 heheh 18:00:01 I was working on upstreaming as much of the HPE process as possible 18:00:04 i'll send an email sometime today 18:00:19 thats still WIP but i should crack on with it really 18:00:19 o/ 18:00:35 thanks dg 18:00:41 http://www.businessinsider.com/how-to-say-hpes-name-2015-11 18:00:50 rofl.. 18:00:56 take this to the security room, given the time? 18:01:03 yarp 18:01:07 thanks everybody! 18:01:07 #endmeeting