17:00:34 #startmeeting Security 17:00:35 hi 17:00:35 Meeting started Thu May 28 17:00:34 2015 UTC and is due to finish in 60 minutes. The chair is tmcpeak. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:39 The meeting name has been set to 'security' 17:00:46 I meant eh? 17:00:46 * sicarie waves 17:00:47 hi michaelxin, bknudson, tkelsey 17:00:51 o/ 17:00:54 hey tmcpeak 17:00:59 yo yo 17:01:00 hi, tmcpeak 17:01:08 so we'll give a couple minutes for stragglers and then get going 17:01:12 meanwhile throw agenda items at me 17:01:38 sounds good 17:01:47 bandit progress (world domination) 17:01:52 yo/ 17:01:52 +1 17:01:53 not an agenda item, but more informational, there is also an #openstack-security room that many lurk in 17:01:54 hi 17:02:13 yeah, a bunch of lurkers there ;) 17:02:33 o/ 17:02:50 tmcpeak: item "bandit patches coming in post-vancouver" 17:02:52 we did not finish reviewing https://etherpad.openstack.org/p/liberty-security-tooling 17:02:58 cool, got it 17:03:06 should we spend some time on it and came up with some action items? 17:03:15 michaelxin - sure, sounds good 17:03:30 A couple of those patches are mine. I'm sorry and you're welcome 17:03:41 sigmavirus24: ;) 17:03:49 ok cool, let's get going then 17:03:59 #topic Bandit Progress 17:04:07 I heard that you guys plan to re-brand bandit, any movement? 17:04:21 tkelsey, bknudson, etc - take it away 17:04:36 bandit is now posting on keystonemiddleware -- https://review.openstack.org/#/c/178707/ 17:04:39 michaelxin: I don't think we're doing that anymore (at least I don't know about it). That was only if we couldn't get the name on PyPI 17:04:47 cool, you should startmeeting tmcpeak :) 17:04:53 tkelsey: I have 17:04:55 tmcpeak: Thanks. 17:04:56 o/ 17:04:59 oh wait, yeah sorry my bad lol 17:05:11 bknudson: awesome, how's it going? 17:05:20 keystonemiddleware is passing. 17:05:26 it was only turned on yesterday 17:05:26 sweet 17:05:39 thats good work! 17:05:40 keystoneclient is waiting on https://review.openstack.org/#/c/178707/ 17:05:41 so are all keystone properties running Bandit now? 17:05:42 bknudson: awesome :) 17:05:49 we have a lot of repos 17:05:58 we should add bandit to keystoneauth too 17:06:01 keystone and keystonemiddleware are the big ones 17:06:10 since that'll be crucial for lots of projects 17:06:19 sigmavirus24: +1 , not sure what it is but it sounds important ;) 17:06:30 cool 17:06:30 keystoneauth is a new one that hasn't had a release yet 17:06:50 I don't think the bandit tests are as useful for the clients, but might as well get them working 17:06:59 bknudson: how come? 17:07:12 clients aren't going to use rootwrap for example 17:07:23 bknudson: can probably catch other things though 17:07:24 I guess they might create temp files 17:07:28 server side is more interesting 17:07:38 sure, actually the rootwrap test is not included in the Keystone profile I don't think 17:07:52 we don't have a good way to rule out false positives, so we'd have to use #nosec on all the safe rootwraps 17:07:53 what kinds of problems do you think bandit can catch in clients? 17:08:33 I guess they might decide to implement their own crypto for whatever reason 17:08:35 maybe handling creds insecurely, temp files, improper TLS handling, stuff like that? 17:08:46 bknudson: I would sure hope not ;) 17:08:56 tmcpeak: +1 17:09:14 tmcpeak: +1 17:09:15 bknudson: like glanceclient? 17:09:16 yeah 17:09:17 it'll eventually be enabled for everything in keystone 17:09:21 glanceclient has it's own crypto at the moment 17:09:27 :| 17:09:30 yea 17:09:33 I'm working on it 17:09:51 own crypto like algorithm or implementation of a known algorithm? 17:09:51 insecure logging might be another one 17:09:59 michaelxin: +1 17:10:12 tmcpeak: as in implementation of a verifying an https connection so they can set special opts with pyOpenSSL 17:10:29 ahh ok, so it's shelling out to OpenSSL or something? 17:10:30 By working on it, I mean I'm working on requests and urllib3 so we can stop those shenanigans 17:10:37 tmcpeak: pyOpenSSL doesn't shell out 17:10:51 Either way, that's a distraction of sorts 17:11:02 Back to the meeting ;) 17:11:06 sigmavirus24: oh good, getting that addressed in requests and urllib3 would be very useful in other cases too 17:11:13 yep 17:11:20 that's why I'm working on it :D 17:11:22 cool, bknudson: thanks for all the work pushing this in Keystone 17:11:28 sigmavirus24: good job 17:11:34 tmcpeak: maybe an action to hyakuhei on his 'overarching crypto monitoring' idea? 17:11:51 sigmavirus24: out of interest did we chat at vancouver about some pyOpenSSL stuff 17:11:53 for sure, I believe gmurphy is working on something along those lines too 17:12:08 tkelsey: maybe? I talked to lots of people at the summit 17:12:17 That said, if not we can chat in #openstack-security about it more 17:12:25 heh yeah same, sure 17:12:26 cool 17:12:29 so item 2 17:12:35 #topic Liberty Security Tooling 17:12:38 michaelxin: this is your item 17:12:50 #link https://etherpad.openstack.org/p/liberty-security-tooling 17:13:08 want to describe what's going on here? 17:13:11 We talked about this during summit design session 17:13:30 cool, any consensus or resulting action items? 17:13:37 We used the ether pad to track the projects or ideas 17:13:46 No, we do not have any action item yet. 17:14:01 I am not sure about the next step 17:14:17 Should we send this list to the email list and ask for feedbacks 17:14:28 so it looks like this is broken into several categories 17:14:30 Is this working towards a proposal for new tools? 17:14:36 improvements to existing projects: Anchor, Bandit 17:14:50 proposals for new tools: IDS, Rest API fuzzer, config validator 17:14:51 it is just like brainstorming 17:14:54 and open questions 17:14:59 yes 17:15:02 oh ok, cool 17:15:03 improvements to Bandit - write a roadmap? 17:15:05 good stuff 17:15:09 might be worth looking at cdent's gabbi tool to do api fuzzing 17:15:12 dg__: im on it :) 17:15:31 elmiko: good stuff, please add info to the etherpad 17:15:37 tkelsey: will do 17:15:39 dg__: tkelsey has expressed a never-ending passion for doc improvement, so he's going to get Bandit whipped into shape 17:15:49 tkelsey is my hero 17:15:49 :P 17:15:57 tmcpeak: +1 17:15:58 Im getting a t-shirt printed up with that on 17:16:04 lol, well when you put it that ... :P but yeah I am going to get stuck in 17:16:04 lol 17:16:31 we need a photo of tkelsey 17:16:34 personally I'd be very interested in some good API slamming tools 17:16:45 tmcpeak: +1 17:16:57 We can work on it 17:17:06 I'm not the biggest Tempest fan in the world though ;) maybe I had a bad early experience 17:17:14 tmcpeak: no that's justified 17:17:23 michaelxin: I think you mentioned that you guys are currently doing REST fuzzing - will any of that be submitted upstream? (or am I wrong about you mentioning that?) 17:17:24 Tempest is for integration 17:17:25 * sigmavirus24 speaks as someone with recent bad tempest experiences 17:17:32 michaelxin: that would be great! I'm sure you'll get some contributors to pitch in too 17:17:44 sigmavirus24: good to see it hasn't changed much :) 17:17:45 sicarie: Yes. 17:17:53 Some of them are Tempest. 17:18:01 Some of them are our own QE tools 17:18:08 tmcpeak: it's stable of course 17:18:19 We are thinking about creating our own API fuzzing tool. 17:19:00 that would be great 17:19:03 part of this might require having schemas for the openstack apis 17:19:10 I mean if you open source it :) 17:19:12 There is still debate in QA about Tempst 17:19:26 michaelxin: and is there any plan to submit that upstream, or assist in outlining an open version? 17:19:29 bknudson: yeah. Glance v1, for example, has 0 schemas 17:19:37 Our QE tool is open source 17:19:58 https://github.com/stackforge/opencafe 17:19:58 http://developer.openstack.org/api-ref-image-v2.html 17:20:15 Yes, we will for sure 17:20:20 most of the schema details are there 17:20:23 michaelxin: could you put any details into the etherpad please, so we can collect stuff there 17:20:26 y, but a computer readable schema so that a fuzzer could use it 17:20:33 tkelsey: Got it. 17:20:37 thanks :) 17:20:39 bknudson: +1 17:20:39 gmurphy: that's for v2 though 17:20:42 oh right. 17:20:45 v1 is there too 17:20:47 v2 has schemas 17:20:48 this might dovetail nicely into some of the swagger ideas that have been circling around 17:21:01 elmiko: don't you bring none of that API-WG nonsense in here ;) 17:21:02 y, I was thinking about swagger 17:21:15 sigmavirus24: lol 17:22:39 cool 17:22:44 so seems like we have some good ideas for tools 17:23:18 anybody want to take action items for future research here? 17:23:27 * sicarie volunteers 17:23:31 or I guess what I'm asking is how can we carry these from ideas into things 17:23:41 sicarie: awesome, what are you volunteering for 17:23:42 ? 17:23:48 tmcpeak: no idea 17:23:52 LOL 17:23:56 haha 17:23:57 I for API fuzzing 17:24:01 i've done a bunch with swagger, i can certainly participate with discussions about api fuzzing 17:24:03 i'd be interested in helping 17:24:08 #action michaelxin to look into API fuzzing options 17:24:14 Yeah, I'll help with michaelxin with API fuzzing if he needs it 17:24:21 sicarie: sure 17:24:24 Or another item if it needs effort 17:24:26 michaelxin: awesome shelleea007 sicarie awesome 17:24:34 #action elmiko to look into API fuzzing options 17:24:49 #action sicarie to look into API fuzzing options 17:25:01 cool, so that's a good group on that 17:25:13 maybe you guys can synch up in #openstack-security and provide an update next week or so? 17:25:24 sounds good 17:25:37 #action shelleea007 to look into API fuzzing options 17:25:47 sorry shelleea007, didn't see your name there too :) 17:25:55 sweet 17:26:15 #topic Signed Requirements 17:26:36 so I've been looking into getting the OpenStack requirements signed before they go to PyPI 17:26:37 its ok, I'm used to being ignored :p 17:27:06 I think I have a plan, I'm just ironing out some last minute details and then we can have a full discussion about it in a soon future meeting 17:27:31 the idea is though, that unless somebody goes and retrieves each requirement from the author page directly, we are vulnerable 17:27:56 PyPI credentials can be compromised and used to upload a malicious version of a package and cause all kinds of bad 17:28:22 this is something I'm planning to move to the top of my personal stack, and once I get everything ironed out I'll greatly appreciate help from the community 17:28:32 does anybody have any thoughts or questions about this idea? 17:28:38 how can we help out =) 17:28:52 elmiko: awesome :) I was hoping you might say that 17:28:58 LOL 17:29:14 sign not only the package but also require the bandit results and sign them. 17:29:24 so we'll need to create some simple guidance about how to get set up for GPG signing and upload a signed package to PyPI 17:30:06 bknudson: that would be perfect world, but I'm hoping to convince each developer of every requirement to give 10 minutes to the cause and sign and reupload their package, if we can get that we're in much better shape 17:30:23 do you have an example of a signed project? 17:30:35 sure, one sec 17:30:46 would this documentation live on security.openstack.org? 17:30:50 tmcpeak: you'll be using twine, right? 17:30:53 I assume bandit is 17:31:02 since twine is the only project that can securely upload packages to PyPI 17:31:07 https://pypi.python.org/pypi/argcomplete 17:31:14 bknudson: actually bandit is not 17:31:15 it also has a way of uploading signatures and doing signing for you 17:31:28 sigmavirus24: oh does, twine do the signing for you? 17:31:32 tmcpeak: yep 17:31:35 oh sweet 17:31:36 * sigmavirus24 maintains too many things 17:31:40 I'm wondering how you tell if it's signed or not 17:31:51 even better! one of the early items was to find the easiest path to get a signed package on PyPI 17:31:52 bknudson: I believe it uploads an asc 17:31:59 bknudson: it's difficult to tell, but you can tell by looking at the json 17:32:08 https://pypi.python.org/pypi/argcomplete/json 17:32:20 I'm probably wrong though, it's been a while since I touched that part of PyPI/twine integration 17:32:34 bknudson: yeah, sigmavirus24 is right, it uploads an asc, which isn't linked on the actual page, but you can download it by appending .asc to the end of the actual package you are downloading 17:32:51 it is not very easy to follow 17:33:04 so one of the foundations of this effort is that we aren't requiring any server side improvements to PyPI 17:33:10 has_sig = false for python-keystoneclient 17:33:12 michaelxin: it should get better when dstufft actually gets warehouse out the door iiuc 17:33:19 it is still using md5 17:33:28 michaelxin: it's switching to sha256 shortly 17:33:29 I've spoken to Donald Stufft - dstufft , and he has his hands full with Warehouse 17:33:42 the blocker was that devpi didn't support sha256 17:33:46 those signatures aren't what we're talking about… that's just for error detection 17:33:50 so now that it has a release with that, Donald will cut over 17:33:54 tmcpeak: correct 17:34:08 tmcpeak: just to clarify, is some of the intent here to help get more openstack project signed in pypi, like across the board? 17:34:29 also it won't help, the threat we're trying to prevent is a developer credentials becoming compromised and they upload a malicious version, which PyPI would happily calculate a sha256 sum for and everything would appear dandy 17:34:33 elmiko: +1 17:34:52 But it can happen to any developer, right? 17:34:52 twine isn't signed so we can't trust that either 17:34:54 elmiko: yes, the intent is to get every single think in global requirements signed 17:35:15 ack, tnx 17:35:39 bknudson: you're correct, any tooling which itself has not been signed can't be relied on 17:35:41 twine 1.1.1 has_sig but 1.4.0 lost it. 17:35:50 gee 17:35:57 bknudson: yeah because I took it over from Donald 17:36:10 just use Donald's sig 17:36:11 sigmavirus24: oh, twine is yours? 17:36:16 tmcpeak: I maintain it 17:36:21 It's PyPA's to be exact 17:36:27 Donald wrote it initially 17:36:32 sigmavirus24: awesome! one of the things on my list was to find who is in charge of twine 17:36:36 Like I said, I maintain too many things 17:36:47 hehe 17:37:01 sigmavirus24: +1 17:37:07 so the developer guidance that we'll create will also include to use twine, to prevent (among other things) credentials becoming compromised because setuptools standard upload process does not validate TLS 17:37:34 sounds nice 17:37:45 tmcpeak: +1 17:37:56 I believe it is the simplest way to get what we want, but I'll definitely want all of your opinions and help on it 17:38:22 tmcpeak: for sure, i would love to see this kind of guidance 17:38:24 I should have all details of plan firmed up in the next week and then I'll open it up and see if anybody has concerns and who would like to work on it 17:38:29 sweet 17:38:55 #topic Other Business 17:39:03 open floor, anybody have anything they want to discuss? 17:39:21 I have one question 17:39:26 michaelxin: sure, what's up? 17:39:41 nothing from me, other than to say thanks to folks pushing bandit patches :) lots of interest after Vamcouver 17:39:49 Does security involved with defcore by any chance? 17:40:06 It will be cool if they include security requirements there 17:40:09 michaelxin: good question, I have no idea 17:40:11 does defcore have any interest in security? 17:40:22 I thought it was just API compatibility 17:40:38 seems like there are already lots of cloud security standards 17:40:48 michaelxin: right now it's focused on APIs, so non-secure endpoints would pass tests 17:41:01 got it. 17:41:03 Thanks 17:41:17 it would still be interesting to get security tests into tempest 17:41:21 michaelxin: bknudson: That doesn't preclude it being part of the testing standard, though. It's just not part of it right now. 17:41:42 I haven't looked at security tempest tests lately, what's the state of them? 17:41:46 we need a "secure" gate 17:41:52 re bandit on Python 3: I just want it to be clear that Bandit's AST parsing will be made to work on Py 2 and Py 3 just like PyFlakes does 17:42:11 sigmavirus24: nice 17:42:11 Any code being tested with bandit run on Py 3 would have to have valid Python 3 syntax 17:42:26 tkelsey: doesn't it currently work against Py3 code? 17:42:34 And any code tested where bandit is run on Py 2 would need valid Python 2 syntax 17:43:09 There are also checks that will need to be done conditionally. The exec plugin will need to work differently on different versions. `exec` is both a statement and a function on Py2. On Py3 it's only a function 17:43:10 tmcpeak: I _think_ the ast should be similar enough that bandit can test py3 code 17:43:36 tkelsey: as long as the Py3 code is also valid Py2 syntax since you'd be compiling with Py2's AST 17:43:38 let's drop py2 support 17:43:43 bknudson: let's not 17:43:45 haha 17:43:52 sigmavirus24: +1 17:43:57 It's a bad idea until all the projects are off py2 17:44:08 sigmavirus24: +1 17:44:10 THEN we can drop Py2 support ;) 17:44:13 sigmavirus24: so is it a different AST lib for Py3 or something? 17:44:19 tmcpeak: yes 17:44:24 ahhh 17:44:28 Same basic API but the symbols from _ast are different 17:44:34 So TryExcept/TryFinally are just ast.Try now 17:44:44 ast.Exec doesnt' exist since exec isn't a statement 17:44:44 interesting... 17:44:45 etc. 17:44:49 Is there much py3 adoption in openstack? 17:44:50 I've done this before 17:44:55 * sigmavirus24 worked on pyflakes 17:44:57 hmm, yeah.. so it seems like even the plugins would have to be Py3 aware 17:44:58 sigmavirus24: thats very interesting 17:44:59 dg__: we're moving towards it so yes 17:45:01 all the clients use py3 17:45:10 tmcpeak: yep 17:45:21 can we change the bandit tox job to use py3 then? 17:45:23 @checks('Exec') is the current blocker on the tests passing on Py34 right now 17:45:30 bknudson: tox -e py34 just works 17:45:31 I wonder if there is some way to abstract that complexity away 17:45:39 tmcpeak: oh god, don't get me started 17:45:39 I mean the keystone tox -e bandit 17:45:43 bknudson: ah 17:45:53 would be nice to free plugin writers from worrying about those intracacies 17:45:54 lol 17:45:56 bknudson: well it won't work for a while 17:45:59 I didn't think about the interpreter 17:45:59 I guess there is no six for the ast lol 17:46:05 tkelsey: there isn't 17:46:10 I thought about doing it once 17:46:12 Another topic is container is so popular in the summit. Should we plan something too? 17:46:15 And then nope.gif'd right out fthere 17:46:15 looks like we just need to set basepython = python3.4 17:46:28 hahaha 17:46:44 michaelxin: yeah its been noted, we should think about things in that space for sure 17:46:57 michaelxin, tkelsey: yeah, agree 17:46:58 tell me when bandit works with py34 and I'll update my tox.ini s 17:47:09 I guess we could start by taking a good hard look at Magnum 17:47:15 tkelsey: tmcpeak: Cool, Thanks. 17:47:21 tmcpeak: +1 17:47:35 bknudson: good to hear. I'll keep you in the loop 17:47:41 bknudson: also add you to the review =P 17:47:44 makes sense, it seems like the state of the art hasn't caught up with all the ideas about signed containers and what not though 17:49:30 cool, anything else to discuss before we wrap for the day? 17:49:36 no, thanks. 17:50:06 tmcpeak: a fun note - the install docs recommend disabling firewalls 17:50:11 wut 17:50:16 lol 17:50:18 which install docs? 17:50:32 ubuntu 17:50:37 wut 17:50:44 link? 17:50:44 sicarie_: the install guide from OpenStack or is this Ubuntu's docs? 17:50:57 sigmavirus24: from OpenStack 17:51:05 tmcpeak: looking 17:51:07 oh man 17:51:20 sicarie_: you can file a bug for that on the openstack-manuals project 17:51:25 And mark me as nosey or whatever LaunchPad calls it 17:51:42 yeah, please do… that's horrible. We should never be recommending flat out disabling the firewall 17:51:50 sigmavirus24: sure 17:52:03 1) people just magically forget to put it back, 2) it's lazy guidance 17:52:26 In the install guide's defense, it's not meant as a guide to deploying a production cloud 17:52:37 I don't think it's right, but it's the purpose of the guide 17:52:41 fair enough 17:52:55 sicarie_: Good catch 17:53:02 also openstack-doc is a good channel to discuss this in 17:53:06 yeah, sicarie_: great catch 17:53:07 with the doc writers who likely wrote that 17:53:20 has any project made bandit a voting job in the gate? we're thinking about it for barbican. 17:53:21 sigmavirus24: I was in the docs working group at the summit when that was brought up 17:53:36 dave-mccowan: bknudson added it to keystone 17:53:49 dave-mccowan: it's not voting. 17:53:54 yet. 17:53:56 we can work with barbican team to add it 17:54:04 dave-mccowan: not yet that I'm aware of, I'd really encourage it though 17:54:05 dave-mccowan: same for sahara, we have it non-voting 17:54:11 I'll request to make it voting soon enough 17:54:30 ours needs more tuning and some local bug fixes to sahara before we go voting 17:54:38 i added it as non-voting to barbican. we're discussing to make it voting, but don't want to be first. :-) 17:54:42 elmiko: if you would like any help with it please let us know 17:54:50 #link: http://docs.openstack.org/icehouse/install-guide/install/yum/content/basics-networking.html 17:54:50 haha 17:54:51 tmcpeak: awesome, will do! 17:55:02 During this installation, certain steps will fail unless you alter or disable the firewall. 17:55:05 only bknudson has the stomach to be first :D 17:55:06 elmiko: dave-mccowan i can help as well 17:55:26 bknudson: trail blazing :) 17:55:26 tkelsey: ack, thanks 17:55:30 my bad, it was the rh guide, the ubuntu guide calls out that iptables/ufw is disabled by default 17:55:41 if there's a new release of bandit and it doesn't break us then I'll be happy to make it voting 17:56:01 otherwise I'll just request to make it voting after it's been running a while 17:56:17 sicarie: :| - I think we should file a bug against that 17:56:22 that seems sensible 17:56:23 the bandit job was broken for a while 17:56:24 bknudson: +1 17:56:32 bknudson: oh? 17:56:33 bknudson: broken how? 17:56:43 because I used bandit~=0.10 or whatever 17:56:49 ahh ok 17:56:54 and something changed so that wasn't working anymore 17:57:10 tmcpeak: done 17:57:10 it's fixed since we switched to having a test-requirements-bandit.txt 17:57:30 bknudson: interesting, sorry for the breakage 17:57:40 sigmavirus24: just added you to the bug 17:57:45 it was my own fault for trying to be on the bleeding edge 17:57:52 oh yeah.. ~=0.10 was pulling a version that we knew wouldn't work, right? 17:58:06 no, it was something didn't understand ~= format 17:58:14 not bandit related at all 17:58:18 oh yeah, that's right 17:58:33 cool. We'll get another Bandit release fairly soon to ease your troubled mind bknudson 17:58:50 :D 17:59:03 allright all, that's about it for the meeting, any last (quick thoughts)? 17:59:10 I'll always have a troubled mind. 17:59:10 I guess we can roll over to #openstack-security if so 17:59:14 lol 17:59:20 great meeting everybody, thanks for coming 17:59:22 have a good week! 17:59:24 #endmeeting