17:00:46 #startmeeting openstack security group 17:00:47 Meeting started Thu Aug 7 17:00:46 2014 UTC and is due to finish in 60 minutes. The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:50 The meeting name has been set to 'openstack_security_group' 17:01:03 Hey everybody! 17:01:09 Hey 17:01:11 hey, all 17:01:12 HOLA 17:01:12 * sicarie waves 17:01:13 :P 17:01:42 Im on foot FYI 17:01:57 on foot? 17:02:07 on phone IRC? 17:02:10 crazy 17:02:19 Walking yup :-) 17:02:23 oh cool, kids these days 17:02:43 I know right! 17:02:48 Its all the rage 17:02:55 ok, so what do people want to discuss today? 17:03:09 gmurphy or I can mention the Horizon XSS walkthrough idea 17:03:17 hi 17:03:22 hey bknudson 17:03:27 sounds good tmcpeak 17:03:30 what else? 17:03:47 can anyone provide an update on the stevedore work? 17:03:50 did anybody look at stevedore? 17:03:56 ;-) 17:03:58 I just started picking through the docs last night 17:04:00 read the docs 17:04:11 started looking at the code 17:04:11 I've been UTG trying to tie up some ends 17:05:13 so I guess for stevedore we'll postpone until next week so we can all finish going through it? 17:05:23 sounds like a plan 17:05:33 +1 17:05:41 cool 17:06:04 what's being done with stevedore? security audit? threat analysis? 17:06:15 #topic stevedore 17:06:23 nothing 17:06:30 bnkudson: I think we're starting with reading through the code 17:06:30 plan to do code review 17:06:34 bknudson even 17:06:35 #link https://github.com/openstack/stevedore 17:06:43 bknudson: to get an idea of how it works/ what it does 17:06:53 then threat modeling would probably be a solid approach IMO 17:07:00 dhellmann is probably the expert there 17:07:07 bdpayne: where did this come from btw? 17:07:36 hey 17:07:43 so this was a request from the glance community 17:07:48 they will be using stevedore soon 17:07:50 Lots of teams seem to be moving to it, bdpayne pointed out we should get involved :) 17:07:56 ah, you're here :D 17:07:59 and they recognized that it has some potential for negative security impact 17:07:59 I thought you were wondering where stevedore came from 17:08:00 ahh ok cool 17:08:10 no not itself, but the request to look at it 17:08:13 it is a library for loading code dynamically easy. 17:08:19 it does seem like it may be ripe for some good sploits 17:08:21 so, it's a code review to understand if they are doing things right from a security perspective 17:08:43 #link http://stevedore.readthedocs.org/en/latest/ 17:08:44 docs 17:08:57 ty 17:09:02 I believe other openstack projects either are using it, or will be using it soon 17:09:09 so it has broader impact too 17:09:14 ok so the tl:dr; is people are looking into it but no results yet ? 17:09:16 we had a proposal for keystone to use it 17:09:22 hyakuhei: +1 17:09:47 cool, I'm glad that some of you have starting pushing ahead with looking at it 17:09:53 looking forward to hearing what you find 17:09:55 Barbican uses ut 17:09:59 It 17:10:21 nice to know. Thanks. 17:10:21 yeah, I've actually seen it all over the place, just was wondering about where the idea to look at it from a security perspective came from 17:10:35 #link https://review.openstack.org/#/c/89419/ 17:10:43 there's the keystone change that was abandoned 17:10:50 so it's an example of how to enable it 17:10:57 anything going through Barbican needs some extra level of inspection... 17:11:05 bknudson: +1 17:11:11 probably make sure you keep some notes or a record of the audit / review if you can. 17:11:22 +1 17:11:24 will help with things become security supported by the vmt etc 17:11:25 gmurphy: oh good, you're here 17:11:47 where would these notes go? seems like the obvious place is stevedore docs 17:11:55 yep. sorry if i'm late. 17:12:13 gmurphy: no, you're good, just wasn't sure if the alarm would do it :) 17:12:23 can we use google docs or wiki page to track the progress 17:12:25 cool ok lets move along :) 17:12:35 Welcome gmurphy - crazy timezone for you.... 17:12:43 #topic XSS shenanigans 17:12:49 tmcpeak gmurphy you're up 17:12:54 gmurphy: wanna take it? 17:12:58 or I can, whichever you want 17:13:05 you're welcome to. 17:13:10 ok cool 17:13:12 i just wanted to raise the issue 17:13:24 gmurphy had the good idea that we've been seeing a lot of XSS in Horizon still 17:13:51 to prevent the same mistake from happening over and over it probably makes sense to have a strategy 17:14:03 so the idea is to do some code review for Horizon 17:14:03 But it's django right - that's an awesomely secure framework.... 17:14:14 Did we ever have a complete assessment on Horizon before? 17:14:17 yeah, Django is solid gold 17:14:33 So there's pretty good "don't do this" guidance for django already 17:14:37 michaelxin: not that I'm aware of, but I'm n00b 17:14:45 including lots on how to avoid XSS etc 17:14:57 XSS is really a subset of "escaping for formatted documents" and "trusting input" 17:15:06 so Django itself may be solid, but the Horizon implementation clearly still leaves something to be desired 17:15:26 So perhaps a first step is to take the issues that have been identified and review the django docs to see if horizon devs are simply ignoring django best practice 17:15:28 so we've got the same problem elsewhere... e.g., if we're generating URLs or XML docs. 17:15:46 sounds good 17:15:50 hyakuhei: +1 17:16:07 +1 17:16:23 ok great - so anyone feel they have enough time to take that as an action? 17:16:24 automation will be the king 17:16:50 I mean in the future :-) 17:16:56 michaelxin: what kind of automation? 17:16:56 that's the other thing. i guess is there a way we can get a web app scanner into CI? 17:16:58 I'll finish my work on stevedore first 17:17:36 yeah, the offer has been floated for free access to Qualys 17:17:38 and look at the delta of the warnings / logs etc? 17:17:43 gmurphy: Yeah we are working on using HP Fortify WebInspect for something along those lines 17:17:49 once we identify the pattern, we might be able to write some scripts to automatically check for the problems. 17:17:58 Yes 17:18:14 in many cases they've either disabled escaping or their missing appropriate decorators 17:18:19 I would imagine 17:18:20 IBM also has a web application scanner 17:19:02 Ok, so what's the action here and who wants to take it? 17:19:22 #link https://review.openstack.org/#/c/105476/ 17:19:23 well one could be looking at the process for how to get a web app scanner into the gate for Horizon 17:19:37 there's the horizon change to fix XSS issues 17:19:54 one is poking through the recently reported issues and classifying them 17:20:01 I can use our appscan to test Horizon 17:20:05 looks like you need to explicitly escape rather than unescape. 17:20:07 seems like a bug 17:21:06 ok, so I don't have bandiwdth to take these actions, if we don't have a volunteer this week we'll log it and try again next week 17:22:07 i can probably take a look at horizon 17:22:13 I'll take something, but it'll probably be slow going 17:22:20 same 17:22:30 I can look at scanner for Horizon 17:23:01 I have a cloud server running devstack and AppScan ready. 17:23:02 so i also need to follow up with qualys 17:23:33 #action gmurphy to look into horizon XSS scanning 17:23:58 sicarie: fancy documenting the current vulns in Horizon and the root causes? 17:24:05 Sure! 17:24:25 #action sicarie to document the root causes of existing Horizon vulnerabilities 17:24:46 ok cool 17:24:52 dg___: you here? 17:25:12 sicarie - http://openstack-security.info/ ctrl+f XSS wil probably help :-) 17:25:15 hey 17:25:18 #topic OSSN-022 17:25:18 gmurphy: I can help if needed 17:25:21 gmurphy: thanks! 17:25:31 Right, dg___ what is the review id for the OSSN? 17:25:45 https://review.openstack.org/#/c/108349 17:26:02 michaelxin - ok. should we setup an etherpad / google docs to keep notes? 17:26:17 #link https://review.openstack.org/#/c/108349 17:26:18 but I cant submit the latest changes I discussed with nkinder, for some resason git review -s has no effect 17:26:38 ok - I want agreement on this OSSN so we can get it published 17:26:51 Can you guys take a second to read the latest copy with comments please? 17:27:10 sure 17:27:11 sure, i can skype it over ot you and you can submit it if you want? 17:27:40 The comment? 17:28:22 that latest revision, nkinder and I agreed on comments, so I made the changes as discussed, but I cant submit it to gerrit 17:28:37 ok, so the latest revision is here: http://pastebin.com/tYU08QBr 17:28:59 I'd like to know how people find it regarding clarity? 17:29:30 cool, what's the best way to provide feedback on it? 17:29:40 I kind of feel like we are starting to bike shed on this one. It seems fine, imho. 17:29:53 what's bike shed? 17:29:59 I'm just looking for a general consensus 17:30:17 looks fine to me 17:30:18 http://en.wiktionary.org/wiki/bikeshedding 17:30:19 bdpayne +1 17:30:28 tmcpeak: too many cooks 17:30:36 ahh 17:30:44 you learn something new every day 17:30:51 my opinion is it's clear and complete as is 17:31:08 Ok so I have no problem with the latest iteration, dg___ maybe you can fix your git and submit it? 17:31:52 hyakuhei kk 17:31:57 yeah this looks good 17:32:02 ok cool 17:32:09 thanks dg___ 17:32:11 as an aside - anyone know how to fix git? 17:32:19 #topic Any Other Business 17:32:29 yep - swift token timeouts 17:32:31 if there's anybody who does, it's nkinder, he's the git oracle 17:32:33 the only thing that it might help to clarify is that the "Recommended Actions" could say this only applies pre-icehouse. 17:32:52 dg___ feel free to PM me about git 17:33:01 bdpayne thanks 17:33:12 Re other business, I added a new OSSN http://en.wiktionary.org/wiki/bikeshedding 17:33:17 um, scratch that link 17:33:19 one sec 17:33:20 lol 17:33:22 heh 17:33:22 hahaha 17:33:25 https://bugs.launchpad.net/keystone/+bug/1348844 17:33:26 Launchpad bug 1348844 in ossn "Keystone logs auth tokens in URLs at log level info" [Undecided,New] 17:33:27 :-) 17:33:37 Dear OpenStack - Y SO MUCH BIKESHEDDING? Thanks the OSSG. 17:33:48 LMAO 17:33:51 #link https://bugs.launchpad.net/keystone/+bug/1348844 17:34:13 bdpayne_: looks like a good candidate 17:34:18 They not backfixing it I guess? 17:34:37 requires an api change 17:34:43 and already fixed in v3 api 17:34:50 so they don't plan to fix it 17:35:01 if someone wants to fix it I don't think it would be blocked. 17:35:13 bdpayne_: yeah, this looks good for an OSSN 17:36:00 bknudson: That's not how this is supposed to work, either it can be fixed and an OSSA gets issued, or it cant be fixed in previous versions and we issue an OSSN ... 17:36:29 as the VMT doesn't issue OSSA's for issues that aren't fixed in supported versions 17:36:29 I can't think of a reason why this couldn't be fixed. 17:36:43 Which seems like the most OSSA worthy issue of all... 17:36:47 I can think of reasons why we wouldn't bother. 17:37:55 Ok well lets see if someone picks that up off the queue this week 17:38:00 Anything else? 17:38:08 swift token timeouts 17:38:12 oh yeah 17:38:18 go ahead dg___ 17:39:01 tokens are cached for 10 minutes, so if a token is revoked, you can have access for up to 10 minutes 17:39:18 dg___: is this in auth_token middleware or something else? 17:39:22 I'm not sure if this is a swift feature, or a feature of our config - was wondering if anyone else had come across it? 17:40:00 bknudson i think so, I havent dug into the code to trace it through 17:40:31 auth_token middleware has a config option for how long to cache tokens: http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token.py#n279 17:40:49 and how long to cache the revocation list revocation_cache_time 17:41:09 thanks, I'll take a look 17:41:12 -1 to disable it 17:41:21 we added a feature somewhat recently to check the revocation list for cached time: http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token.py#n321 17:41:31 check_revocations_for_cached 17:41:44 so you can shorten the cache time for the token 17:41:51 gotcha 17:42:03 you can enable check_revocations_for_cached and shorten the revocation_cache_time 17:42:07 if that's more efficient 17:42:17 thats what i was about to ask! 17:42:32 that would make sense, thanks bknudson 17:42:55 setting check_revocations_for_cached requires setting up pki on the keystone server even if you're using UUID tokens 17:43:16 because the revocation list is cms encrypted for some reason 17:43:41 ok 17:43:46 all this assumes that swift is using auth_token middleware... I only tried this with nova 17:44:08 lol I will talk to the swift folks, assuming it is, this seems like a smart way to handle it 17:44:51 ok cool, thanks bknudson dg___ 17:45:00 Anything else? 17:45:05 thanks 17:45:06 you all, make sure bay area ppl attend the meetup organized by Bryan and Preeti 17:45:26 did we have some docs for what encryption algorithms are used in different components? 17:45:33 http://www.meetup.com/Cloud-Platform-at-Symantec/events/199393922/?a=ea1_grp&rv=ea1&_af_eid=199393922&_af=event 17:45:35 sriramhere: +1, that will be a good regular meetup spot for us 17:45:52 :) 17:46:03 dg___: swift is using the auth_token middleware for keystone 17:46:09 oh yeah that, thanks sriramhere 17:46:16 :-) 17:46:33 bknudson we do, on the wiki 17:46:36 thanks notmyname 17:46:55 cool. thanks. 17:47:34 bknudson https://wiki.openstack.org/wiki/Security/Juno 17:48:08 bdpayne_: thanks for the link 17:48:35 I've got a team here where I've asked them to do a crypto audit... 17:48:49 oh great 17:48:51 if it goes well I'll see if I can get these pages updated. 17:48:56 this is on my short(ish) list too 17:49:02 I would love to see those get filled out 17:50:13 That would be really good 17:50:45 ok, I think we are good to wrap here. 17:51:03 Thanks everyone - got a few good actions down! 17:51:10 thanks! 17:51:13 thanks. 17:51:13 #endmeeting