17:00:38 #startmeeting OpenStack Security Group 17:00:39 Meeting started Thu Aug 14 17:00:38 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:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:43 The meeting name has been set to 'openstack_security_group' 17:00:59 hi 17:01:01 Hey all 17:01:02 Afternoon 17:01:08 Greetings! 17:01:11 Greetings! 17:01:28 o/ 17:01:30 hi 17:01:39 So we'll give people a minute to filter in and then get started :D 17:02:42 hi all 17:03:18 ok, so agenda items? 17:03:21 XSS update 17:03:23 OSSN Move 17:03:26 what elese? 17:03:38 I'd like to add a topic to discuss keystone under apache httpd and SELinux 17:03:41 gmurphy: thanks again for making the time to join us, I know it's a difficult timeone for you. 17:03:44 Great 17:04:04 hyakuhei np. 17:04:32 ok great 17:04:41 gmurphy: you happy to take us through the XSS progress? 17:05:01 #topic Horizon XSS update 17:05:02 sure i can provide an update 17:06:04 so i spent a bit of time this week sifting through the typical things that lead to xss flaws 17:06:12 my notes are available here - https://etherpad.openstack.org/p/dashboard_xss_analysis 17:06:39 the analysis in the etherpad is great 17:06:41 excellent work btw. 17:06:42 i read through those earlier today, after seeing your post to the mailing list .. very, very useful 17:07:00 i think pauls email pretty much sums up what needs to happen tbh 17:07:05 definately extensive analysis 17:07:22 y, but it had to be taken to the analysis phase... 17:07:36 and find actual places in the code 17:08:04 sure. i think we also had a couple of web app scanners being run too? 17:08:15 but i'm not sure of the results of those. 17:08:27 So for those here who struggle to keep up with the email lists, what can the OSSG do to help out? 17:08:32 yeah, paul's e-mail seems like the right way to move towards 17:08:42 +1 17:09:04 maybe we can also flag things like autoescape off & | safe in hacking rules? 17:09:24 i'm not sure where we are at with that? 17:09:41 hyakuhei - add Bandit update to the agenda? 17:09:42 Should be easy to catch a bunch of these issues. 17:09:48 sicarie: yeah 17:10:07 ok so everyone, read the mail thread - it's very interesting! 17:10:12 Thanks gmurphy 17:10:18 #topic OSSN move 17:10:32 nkinder: Want to fill us in on the who, where, why? 17:10:46 Sure 17:11:04 The OSSNs have been moved to the security-doc repo (where the security guide lives) 17:11:25 The old repository will be "going away" this weekend during the Gerrit outage 17:11:34 going away == moved to openstack-attic 17:11:53 All of the old content has been moved over, so new notes should be proposed against the new repo. 17:11:57 the new repo is there already? 17:12:05 bknudson: yep, link coming... 17:12:21 http://git.openstack.org/cgit/openstack/security-doc/ 17:12:27 you beat me... :) 17:12:38 does it get published already, too? 17:12:54 bknudson: publishing is manual (same as before) 17:12:55 I think i pushed one in between chages 17:13:14 but, we can now work on auto-publishing 17:13:35 There was one note in flight (OSSN-0020) whose review I blocked and re-proposed against the new repo 17:13:37 add it to your watch list in gerrit. 17:13:42 https://review.openstack.org/#/settings/projects 17:13:52 This is an issue that Priti was working on, but it's stalled out. 17:14:09 I plan to take it over, as it seems like she's not going to get back to it soon. 17:14:24 nkinder: i am talking about 0024 17:14:36 Priti said she should have more time for it now 17:14:47 hyakuhei: yes, you can just propose the review against the new repo 17:14:53 but I'd like to see that move along so collaborating on the changes might be the way forward 17:15:44 ok cool, thanks nkinder 17:15:50 hyakuhei: yep, I'll help it along tomorrow if she hasn't updated it 17:16:07 Great, I'll look out for the review update 17:16:16 shohel02: You can mark your old review as abandoned once you propose 0024 against the new repo. 17:16:42 okey 17:16:45 bknudson: what did you want to discuss re keystone? 17:17:01 OK... maybe some people here are familiar with SELinux 17:17:06 and how it's used with OpenStack 17:17:34 My understanding is that keystone-all (running under eventlet) typically has SELinux in an unbounded context 17:17:35 Yep 17:17:44 now we've suggested running keystone in httpd 17:17:51 Yeah, but httpd_t will be used with mod_wsgi 17:17:57 #topic Keystone SELINUX HTTPD 17:18:02 so to do that it logically means that now httpd is unbounded 17:18:10 no, it doesn't 17:18:18 it means that keystone runs as httpd_t 17:18:33 ...which requires extending some things 17:18:55 the ports you use for Keystone need to be labelled as httpd_t for one 17:19:03 you can use semanage to do this 17:19:43 there are some httpd selinux booleans you man need to set too 17:20:07 I think keystone-all is unbounded due to connecting to database or memcached, or ldap, or whatever. 17:20:15 in particular, there is an httpd_can_network_connect (sp?) that would be needed to allow it to make outgoing connections to things like LDAP 17:20:56 bknudson: keystone-all (eventlet) will run as unconfined_t IIRC, as the process doesn't have any special transition to a confined context 17:22:06 nkinder: ok, so some people I was talking to here were concerned about it, and I wasn't able to tell them much due to not knowing much about selinux 17:22:20 bknudson: so are you trying to make keystone run unconfined with httpd, or you want to extend httpd_t to allow Keystone to work? 17:22:26 the latter is the right approach 17:22:38 nkinder: y, the concern was that we'd have to run unconfined. 17:22:51 extending httpd_t is what we'd like to do. 17:22:59 bknudson: As a FYI, I'm working on getting the base OS policy extended to allow Keystone to just work (that will take a bit of time) 17:23:00 and it sounds like it's possible 17:23:06 bknudson: ok, it's definitely possible 17:23:16 bknudson: I've written policy before, so reach out to me if needed 17:23:22 nkinder: alright, thanks! 17:23:48 Great 17:23:57 bknudson: worst case, it just requires a customer seliux policy module to be written to extend httpd (though most of what you need is possible with setsebool and semanage AFAIK) 17:24:02 we can take the rest of the discussion out of the meeting. 17:24:05 s/customer/custom/ 17:24:10 Yep. 17:24:13 chair6: Got a second to talk about Bandit? 17:24:39 sure 17:24:41 #topic Bandit 17:24:51 bandit is still at https://github.com/chair6/bandit 17:24:55 Great so what's the latest and how / when can people contribut? 17:25:00 it has Apache 2.0 licensing as of 2 weeks ago 17:25:03 :) 17:25:08 i've been out on vacation since then, so minimal progress :) 17:25:15 Ah right 17:25:21 on my current to-do list, which i plan to spend some time on shortly: 17:25:28 - Rework configuration (JSON, perhaps) to support global and per-check scope 17:25:30 So the XSS stuff would be interesting to add, as would putting it into Stackforge 17:25:31 - Build out support for additional AST node types 17:25:34 - Consider additional helper functions that could make writing tests simpler 17:25:51 yes, i want to at least add a check for the mark_safe() calls 17:25:58 makes sense 17:25:59 I think a high priority is to add support to ignore lines 17:26:12 that's needed to start adding gate jobs 17:26:25 good call nkinder, i'll add that to the list 17:26:42 Also, were there still "hacking" style tests that we wrote that haven't been converted to bandit? 17:26:44 Yeah 17:27:10 Plenty of work to go around, when would it be ready for us to port those tests? 17:27:18 any time I think 17:27:43 chair6: Don't take it all on yourself. I'd recommend you write up an e-mail to the security list and say what needs to be done 17:27:54 sounds like a plan, will do 17:27:54 We can then divy work up 17:28:07 +1 17:28:17 I'd like to contribute 17:28:22 porting tests will help point out areas where the bandit framework should be extended to make writing tests easier too 17:28:22 same here 17:28:30 * sicarie volunteers too 17:28:38 I'd like for people besides me and chair6 to port tests 17:28:41 tkelsey gets volunteered too :) 17:28:48 * sweston jumps on the volunteer bandwagon 17:28:54 We're already done it, so we need input from others on the process 17:28:56 Heh sure :-) 17:28:58 :D 17:29:02 i'll send out a mail to the list and we can work from there 17:29:03 Ok great 17:29:23 #action chair6 to mail a list of todo / collaboration items to the ML re: Bandit 17:29:24 I'd also like to help with this 17:29:47 Once we have some of this done, we can look at adding them to the gate as non-voting for Keystone maybe 17:30:02 I would like that working before the Summit 17:30:29 we could have a design summit session about it if we're far enough along (and if there's a security track) 17:31:16 Yeah 17:31:24 When do the design summit proposals open? 17:32:13 hyakuhei: hasn't been announced yet AFAIK 17:32:28 Ah that's ok then :) 17:33:06 tmcpeak asked me to bring up stevedore 17:33:16 #topic Stevedore 17:33:50 Travis is plannign on reviewing it, but wanted to see what research anyone here has done on it 17:34:13 In particular, I think he wants to identity any concerns others might have about stevedore so he knows what to look for when reviewing it 17:34:27 I haven't really looked into it myself personally 17:34:31 Lots of people volunteered to look 17:34:33 I haven't 17:35:38 Travis' main concerns center around malicious extensions 17:35:55 They can possible money patch things, get at sensitive data, etc. 17:36:17 Given that these are plug-ins, there is some level of trust involved 17:36:23 that makes sense... an extension can do whatever it wants 17:36:27 Yep 17:36:27 this is python 17:36:48 similar to dynamic loading of .sos in linux 17:36:53 This is where things like signed extensions and such help (like signed jars in Java) 17:38:09 Ok, well it sounds like nobody here has researched stevedore in depth, so we'll see what Travis uncovers and discuss it more in the future. 17:38:24 Sounds good 17:38:35 #topic Design Summit Sessions 17:38:51 Now that summit sessions are in, what about design sessiosn? 17:39:07 an obvious one is a horizon session 17:39:10 The OSSG one went down well last time 17:39:19 Horizon security session would be good 17:39:24 Bandit would be good 17:39:31 Yeah, a catch-all OSSG one would be good. 17:39:46 Bandit and extending gate jobs across projects would be good as well 17:40:09 +1 17:40:13 those might be merged. I guess it depends on what topics we want to cover in the catch-all session 17:40:20 I might suggest getting some attention on Neutron security, depending on how folks feel about that 17:40:30 * sweston possibly opens up a can of worms 17:40:30 OSSG session last time had about two times too much content 17:40:31 bknudson: for Horizon, are you thinking of the XSS stuff that Paul brought up? 17:40:37 nkinder: yes 17:40:38 sweston: good idea 17:40:43 you guys should have some security 17:40:49 hyakuhei: suggestions for topics? 17:40:50 :) 17:40:57 hehe 17:41:03 Limits of Neutron security capabilities? 17:41:39 sounds broad 17:41:48 What about the Neutron advanced services? There is a lot around SSL there for LBaaS and VPNaaS lately. 17:41:59 better 17:42:17 Is there anything that the OSSG can help with there? 17:42:46 good suggestions! let me see if I can open up a discussion with the ptl 17:43:02 anything else? 17:43:07 I'm sure some of the Barbican guys would be interested in that discussion as well 17:43:17 yeah 17:43:42 is it possible to get a threat modeling exercise going on one project at the summit? 17:43:53 it might not fit in well to a normal design session (not enough time) 17:44:22 or perhaps it can be split into 2 sessions (there was a double session for something at the last summit) 17:44:57 yah, it could around how projects wants to see threat model report 17:45:05 discussion around that 17:45:50 Yeah, good place to introducte threat analysis more 17:46:02 we can invite PTL's/cores from projects we want to target 17:46:45 I'd like to get SSL gate jobs running too, which might be worthy of discussion in a session 17:46:54 Sure 17:46:55 this might fit into a generic OSSG catch-all 17:47:04 nkinder: what would SSL gate jobs entail? 17:47:15 the patches for devstack are out there, so it's just getting them put into place for tests 17:47:39 I know viraptor has been doing some work in that space too 17:47:51 hyakuhei: devstack can deploy nova, neutron, swift, cinder, glance, keystone, and horizon with SSL using stud or native SSL 17:48:13 Yeah but my understanding was that didn't really work 17:48:13 https://review.openstack.org/98854 17:48:16 it does 17:48:27 We've been looking to provide our ephemeral PKI stuff there 17:48:31 once that patch lands. One of my engineers has been getting it in shape 17:48:38 Fantastic news :D 17:48:51 #topic any other business 17:49:37 I have one small thing. i was going to try and get people to use the SecurityImpact tag for OSSA fixes. The aim would be to get more eyes on the reviews and to watch out for incomplete fixes. 17:49:49 More of a FYI 17:50:16 or any complaints? 17:50:24 I'm fine with that but imo we are not very good at acting on the SecurityImpact tag 17:50:36 I +1 your proposal though 17:51:09 well, OSSA are often private security 17:51:30 This would be when we are trying to push the fix through and publish the advisory. 17:51:31 so I can't look at the patch until it's proposed & ready to merge 17:51:42 I thought you meant those in gerrit, which is normally those publicly disclosed 17:52:06 Le 17:52:23 Well I guess in the past I've had trouble finding reviewers to +1 +2 things so we can issue the advisory. 17:53:00 are you talking about public ones? 17:54:14 How would SecurityImpact notify us if the bug is private? 17:54:17 the -security mailing list gets emails about security bugs 17:54:27 public ones. 17:54:30 No. Nothing gets pushed to gerrit until bug becomes public. 17:54:38 ah, yes 17:54:52 So if you're just saying that public fixes to OSSA's should have security impact tags set 17:54:55 of course they should :D 17:55:03 that makes sense, though I expect we're in a rush to get the fix out at that point 17:55:14 I've got to admit I forgot to do that on the revocation events patches. 17:55:33 once we lift an embargo, it's usually full steam ahead, right? 17:55:33 you would have seen a lot of email because it was a lot of patches 17:56:01 nkinder - well. that would be plan yes. 17:56:06 We might not have time to provide much useful feedback at that point before releasing the update. 17:56:22 It still sees right to add SecurityImpact though 17:56:26 s/sees/seems/ 17:56:47 even looking at the patch after it's been merged can be useful, since it can be reverted or amended 17:57:27 Yeah 17:57:38 Also useful for stats and retrospective reviews later on 17:58:22 Ok, any last minute things before we wind this up? 17:59:21 folks, 1 min left 17:59:30 #endmeeting