18:00:26 #startmeeting OpenStack Security Group 18:00:27 Meeting started Thu Dec 5 18:00:26 2013 UTC and is due to finish in 60 minutes. The chair is bdpayne. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:31 The meeting name has been set to 'openstack_security_group' 18:00:40 Hi OSSG 18:00:43 hi 18:00:45 Let's start with a rollcall 18:00:53 #topic rollcall 18:01:01 hey 18:01:06 Paul Montgomery, Rackspace (new guy in OSSG from Project Solum) 18:01:21 welcome paulmo 18:01:38 Thanks; glad to see the great security guide provided. :) 18:02:01 anyone else here today? 18:02:01 does new project require update to security guide? 18:02:30 ok, small group today 18:02:31 I'm still reviewing the guide but I suspect Solum may have some addition requirements. 18:02:49 bknudson I think that's a strong "it depends" 18:02:55 #topic today's agenda 18:03:08 I'm here 18:03:11 So I'm recovering from both Thanksgiving and being sick this week :-) 18:03:17 So I don't have too much news to report 18:03:31 Anything specific that others would like to discuss today? 18:03:56 I have a few topics. 18:04:14 nkinder sure, please go ahead and list them here and we can get to them in turn 18:04:23 One quick one is that I have an OSSN ready for a glance issue, but wanted to know if anyone else from OSSG needs to review it 18:04:41 best to have at least two other people review 18:04:53 The other is an effort to get a cross-project set of security guidelines established. 18:04:55 just to keep quality high and check for random typos and such 18:05:08 +1 nkinder 18:05:17 great, I'll add that to the agenda 18:05:25 anything else? 18:05:41 not from me 18:05:41 I have a few questions but I'm not sure if this is the right forum 18:06:07 sure, sounds like it's a quiet day... perhaps we can field some questions at the end? 18:06:14 Sure; sounds great! 18:06:15 we typically run for 30 min 18:06:33 ok... 18:06:38 #topic OSSG news 18:06:57 So the main news I have to report this week is that we have three people signed up to be book editors 18:07:36 the team is Ben DeBont, Sriram Subramanian and David Mortman 18:07:52 clearly anyone is encourage to edit the book 18:08:09 it's as simple as doing a PR against the docbook source for the book 18:08:10 great! Are they dividing up chapters to review? 18:08:31 but, these three people will be taking the lead on moving foward with the overall improvements to the book 18:08:41 I'm not sure how they are splitting it up or approaching it 18:08:43 is editing fixing typos or is it also to make content clearer? 18:08:55 bknudson, all of the above 18:09:28 nothing on my end… I'll have soem update to the book to publish in the new few weeks 18:09:33 so I've asked them to take the lead on this, and I'll ask them to check in here at the meetings and on the mailing list periodically 18:10:07 elo sounds good, perhaps you can sync with the book editing team wrt to your updates 18:10:28 Will do. 18:10:31 I did submit a few bugs when reading through it 18:10:47 #topic cross project security guidelines 18:10:51 take it away nkinder 18:11:37 I'd like to have our group help to establish a set of cross-project security guidelines. 18:11:52 This needs to come from all of the projects as well as us 18:12:17 I floated the idea on the dev list, and there was interest from som eof the Solum folks (one reason paulmo is here) 18:12:33 I've talked with some of the keystone devs as well, and there is interest there. 18:13:01 Basically, I think we need a security representative from each of the core projects so we can brainstorm and come up with the guidelines. 18:13:03 yeah, this sounds like a good idea 18:13:19 I was going to reach out to the PTLs in their meeting next monday 18:13:19 perhaps would be a good place to collaborate with some of the OWASP people too? 18:14:05 sure, makes sense 18:14:19 Would the goal be to make security requirements or guidelines? 18:14:47 paulmo: well, eventually a bit of both would be good IMHO 18:14:54 my take... would be that we start with guidelines 18:15:02 I don't think we're currently really in a position to dictate requirements. 18:15:07 bdpayne: +1 18:15:19 and then set a low bar with turning some into requirements... complete with CI that enforces it, if possible 18:15:26 and then slowly dial it up 18:15:32 Sounds like a good plan to me. 18:15:48 If we can get a general consensus from representatives on the projects, it shoudln't be hard to have them be spoken guidelines. 18:15:53 sorry, requirements 18:15:58 bdpayne: +1 18:16:17 so this sounds nice 18:16:25 are these guidelines like the length of keys and ciphers? 18:16:41 validating inputs 18:16:44 I know that there was some talk about security testing before the summit... might be nice to check in with those guys and see if/how that's coming along 18:17:02 this could certainly go in many directions 18:17:10 did you have specific ideas for the guidelines nkinder? 18:17:16 use of random number generators 18:17:18 bknudson: yes, I think that sort of thing, plus general developer best practice (zeroing memory that stores passwords/keys, etc.) 18:17:29 encrypting passwords in Keystone's SQL backend :( 18:17:45 perhaps examples of good security patterns (and ones to avoid) 18:18:02 perhaps encouragement to use common security sensitive code (e.g., OSLO rootwrap) 18:18:06 bdpayne: I have ideas about areas that should be addressed, but I expect many folks from the projects will have ideas too. 18:18:09 stuff like that 18:18:16 yeah 18:18:34 so I envision a massive, distributed brainstorm 18:18:34 nkinder: I'm willing to help out on this 18:18:43 and then perhaps a small team to make sense of it all and make some proposals 18:18:52 paulmo: Great! I have your name down on my list already. :) 18:19:12 nkinder I'd be willing to help as well 18:19:36 bdpayne: ok, great. Let me see what interest I get from the PTLs next week, and we'll go from there. 18:20:10 sounds good 18:20:13 This will also help identify areas where things should be improved. 18:20:23 where we don't meet guidelines, etc. 18:20:35 #topic open discussion / questions 18:20:43 paulmo you had some questions? 18:20:54 also, anything else people want to discuss? 18:21:15 Sure! I see that there is a SecurityImpact Gerrit tag, are there any code comment formats for potential security issues that devs can put in their code? 18:21:49 right now it is just free form 18:21:52 (I'd like the team to be able to mark potential issues for research later while they are coding rather than trying to find them later if possible. Just seeing if there is an OpenStack or OSSG guide for that.) 18:21:53 paulmo: I've never seen one. 18:22:05 so devs can use the tag, and that sends an email to the openstack-security list 18:22:15 and then someone from OSSG (ideally) will go to review the code 18:22:25 so any other details could just be placed as part of the commit msg 18:22:48 Ok, we'll make up a comment tag for Solum and use SecurityImpact for reviews. 18:23:01 sounds good 18:23:03 bdpayne: It'd be nice to have some way to sign off that the OSSG has reviewed an issue. 18:23:19 yeah, not sure if gerrit supports that 18:23:41 Next - Has anyone discussed a method of identifying confidential data in Oslo logging? This seems to be a source of credential leaks lately. 18:23:46 that being "if securityimpact tag, then require +1 from OSSG to merge" 18:24:09 so there has been an effort lately to cleanup the logs 18:24:20 this goes beyond oslo and includes pretty much all of the projects 18:24:27 and by cleanup, I mean remove things like passwords from them 18:24:41 paulmo: there's code in oslo-logging that checks for "password", I think. 18:24:44 I think that people are generally relying on manual inspection at this point 18:24:52 I would like to find that information. We have a blueprint in solum to try to head this issue off early: https://blueprints.launchpad.net/solum/+spec/logging 18:25:08 but, yeah, that would be good to automate some more 18:25:25 it's worth noting that this has been a cause of disagreement 18:25:32 Would this team make recommendations or would I go work with Oslo folks directly? 18:25:46 I've seen people arguing for having security sensitive stuff (tokens, passwords, etc) in debug level logs 18:25:57 I personally disagree with that approach, but hey 18:26:04 when keystone is configured for debug it does insecure things. 18:26:49 paulmo I think that if the security guideance stuff comes together, that could be nice place for this 18:26:59 bdpayne: +1 18:27:04 I was thinking of a boil the frog approach. Mark confidential data (and exceptions, espcially database exceptions) in the log with a tag (basically a list of dictionaries) to hold confidential data. Then filter it on the backend so users don't see it. 18:27:46 I think I'd need more context to comment on that specific approach 18:27:54 perhaps a good disucssion for the ML 18:28:18 Yes, sorry, just an elevator pitch. I can discuss more when ready or ML. :) 18:28:19 any other questions? 18:28:33 I think that is all for now. Thanks for letting me take the floor for so long. 18:28:34 Anyone care to review my OSSN so I can publish it? :) - https://bugs.launchpad.net/ossn/+bug/1226078 18:28:36 Launchpad bug 1226078 in ossn "Glance allows user to create images and add other tenants as members (CVE-2013-4354)" [Medium,In progress] 18:28:46 nkinder I'll take a look later today 18:28:52 bdpayne: thanks 18:29:15 ok, so that's all for today 18:29:19 see everyone next week 18:29:26 #endmeeting