17:02:59 #startmeeting OSSG-Weekly 17:03:00 Meeting started Thu Feb 5 17:02:59 2015 UTC and is due to finish in 60 minutes. The chair is tmcpeak. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:05 The meeting name has been set to 'ossg_weekly' 17:03:12 roll call? 17:03:18 yo/ 17:03:20 o/ 17:03:21 hi! 17:03:22 o/ 17:03:22 o/ 17:03:23 o/ 17:03:23 hi 17:03:24 o/ 17:03:29 cool 17:03:31 agenda? 17:03:43 meetup 17:03:45 Bandit 17:03:47 anchor 17:03:48 book 17:03:49 Collaborative security evaluations 17:03:55 ^ that 17:04:04 (nkinder once mentioned the idea of penetration testing OpenStack projects "in the open" rather than behind closed doors) 17:04:04 any others? 17:04:07 there's a discussion on the mailing list about rootwrap 17:04:17 bknudson: oh yeah, saw that 17:04:35 there was a complaint at the cross-project meeting that they asked a "security" group to audit it... 17:04:50 cool, looks like a full schedule 17:04:51 let's get to it 17:04:53 but then they looked at it and they didn't need any help seeing what a disaster it is. 17:04:59 #topic meetup 17:05:10 everybody on/aware of the etherpad? 17:05:31 #link https://etherpad.openstack.org/p/ossg-kilo-meetup 17:05:34 yep 17:05:43 my bot-fu skills need work 17:06:03 ok 17:06:14 we've got a good group, lots of stuff to talk about 17:06:27 if you haven't expressed interest in one of the topics, or proposed another - please do so 17:06:35 HP is working on some good eats 17:06:58 I see the beer is already there 17:07:01 we should probably try to synch up on a social day too 17:07:12 ljfisher: fosho. Prerequisite 17:07:18 let's do this 17:07:43 I'll put the four days, everybody please mark which days *after* the meetup you works best for you for a gathering 17:08:42 cool 17:08:53 also, any natives that want to propose something 17:09:05 I lived in SF for a while so I have some ideas, but open to others also 17:09:31 anything else? 17:09:55 go team? 17:09:57 :-) 17:10:06 bdpayne: perfect 17:10:12 #topic Bandit 17:10:19 we still don't have a name :'( 17:10:25 :( 17:10:27 well we do, but it's in collision 17:10:36 any response from the current owners? 17:10:38 I've applied to the PyPI folks to evict the other Bandit 17:10:47 ljfisher: no, and no response from PyPI lords either 17:11:01 that's here: https://sourceforge.net/p/pypi/support-requests/466/ 17:11:06 how long is it expected to take for pypi to get back to us? 17:11:41 bknudson: unclear. There are a ton of open tickets stretching far back 17:11:44 I'm not holding my breath 17:11:58 seems easier to pick a different name. 17:12:05 I'd say we can give it another week, I'll probably write the owner one more time (bc why not) and then we can just move ahead with a new name 17:12:37 bknudson: yeah, easier for sure. Hesitancy is giving up whatever brand name we've built 17:13:14 anything else for Bandit? 17:13:32 tmcpeak: so there's a process 17:13:43 And the main thing to do is wait because Richard will contact the owners too 17:13:47 I think it may take up to a month 17:13:54 sigmavirus24: yikes 17:14:07 if it's a month I'm not sure it's worth it to wait 17:14:27 Fair enough 17:14:44 The guidelines are also published but I can't remember where at the moment 17:14:50 sigmavirus24: if Richard comments on the ticket though, we can revisit 17:15:06 (There's also one person who handles all of those) 17:15:18 ahh ok cool 17:15:27 at least this isn't unprecedented :) 17:16:06 #topic Anchor 17:16:13 tkelsey dg_ 17:16:17 yup 17:16:31 tests progressing, some outside interest :) 17:16:58 cool, what's the outside interest? 17:16:59 we got our first patch thats not from a core (as far as i know) 17:17:01 https://review.openstack.org/#/c/153050/ 17:17:19 Re Bandit name: I contacted someone who may be able to help move this along. Stay tuned. 17:17:29 bdpayne: awesome, thank you! 17:17:38 tkelsey: good stuff 17:18:03 so yeah, its moving in the right direction 17:18:07 tkelsey dg_ you guys want to do a little preso at the meetup to get people up to speed? 17:18:18 yeah sure :) 17:18:21 good idea 17:18:28 awesome 17:18:35 i'll put in the etherpad if its not already 17:18:52 I actually hope to drum up some more interest at the mid cycle 17:19:08 cool, yeah I keep meaning to be more informed about Anchor 17:19:30 I think that everything to say on it for now :) 17:19:30 thanks tmcpeak 17:19:36 cool 17:19:39 #topic Book 17:19:54 book? 17:19:56 that's me? 17:20:02 bdpayne elmiko sicarie : want to provide updates about what you guys have been doing? 17:20:18 sure 17:20:19 yeah 17:20:21 so we've been working on traiging the open bugs against the book 17:20:46 i'm also getting dangerously close to having a review up for the data processing chapter 17:20:47 cool, yeah seems like it's been picking up speed again 17:20:49 which has had the side effect of getting people to start fixing bugs again 17:20:51 which is great 17:21:03 I'm seeing a lot of activity in the channel 17:21:19 goal is to work through the existing tickets, and then to start working on identifying where we need to improve going forward 17:21:20 i do have a general question about diagrams in the book 17:21:35 ideally, putting some process in place around book updates for OS releases 17:21:48 the object store section has a nice diagram, were those graphics provided by the swift team or is there a group of gfx we can use to create more? 17:21:48 elmiko go for it 17:22:01 those were done by the doc team 17:22:13 ok, etherpad updated re Anchor 17:22:19 we drew pictures on a whiteboard 17:22:21 took a picture 17:22:22 ok, i'll hunt around those parts to ask about the sources 17:22:23 and someone made them pretty for us 17:22:23 tkelsey: great 17:22:27 ahh cool 17:22:38 you guys have a link to the book backlog? 17:22:45 elmiko I can help you track down the right person, if needed 17:22:47 yeah, one sec 17:22:49 i've been working on this, https://mimccune.fedorapeople.org/data_processing.png , as a starting point for sahara deployment 17:23:03 elmiko: what swift diagram? I can probably answer that question 17:23:07 https://bugs.launchpad.net/openstack-manuals/+bugs?field.tag=sec-guide 17:23:08 i'm curious if that will be sufficient to demonstrate a basic deployment 17:23:23 notmyname: the one right at the beginning, let me find the page 17:23:33 looks like a pretty well groomed backlog 17:23:46 notmyname: figure 9.1 at the beginning of the chapter 17:23:49 that's b/c we rock 17:23:56 bdpayne: +1 17:24:03 =) 17:24:15 suggestion: let's discuss figures on the security channel after this meeting 17:24:18 may be too "in the weeds" for the general meeting 17:24:19 elmiko: I just saw the swift reference in here. I'm not sure what book you're referring to. do you have a link? 17:24:31 notmyname: sure, i'll ping you in a /msg 17:24:33 bdpayne: definitely 17:24:37 awesome 17:24:40 great work 17:24:54 if anybody wants to pick up some work, see bdpayne's backlog link 17:25:02 indeed 17:25:19 #topic Collaborative Security Evaluations 17:25:26 what's this? 17:25:33 Ok... so, nkinder once mentioned to me the idea of 17:25:49 instead of different companies evaluating OS projects behind closed doors, collaborating on it 17:26:09 like coordinating? 17:26:10 I've talked to some people withing Cisco about it, and it'd be a new area for us, but there's some interest and possibly some HC 17:26:35 you mean evaluating like code reviews? 17:26:43 exactly... as in, instead of everyone repeating the same stuff because nobody knows what other people have covered, have a collaborative process and document the results 17:27:00 I mean like "vulnerability discovery" 17:27:04 singlethink: yeah, makes sense 17:27:18 problem is how do you ensure that the hax0rs don't use that work too :) 17:27:30 it would require some work on my part to get the company to agree to un-confidential the info. 17:27:56 yeah, hyakuhei would know more than me how HP feels about it, but I assume we'd be in favor 17:28:18 anything that makes upstream better is good for all of us 17:28:22 also, some of what we do is not useful to the community since it depends on our product. 17:28:28 Understood... there are hurdles here too but there is some executive interest. 17:28:56 we open bugs in the community for things that we need help with from community. 17:29:29 so this is kind of like a more applied version of the existing threat modeling work? 17:29:34 re h4X0rs... it may need to be more tightly controlled, like the VMT. 17:29:46 bdpayne: Yes. 17:30:07 how technical? 17:30:21 bknudson: That's Cisco's current working model as well. But, I had heard that there might be *some* interest in pooling resources. 17:30:25 more like specific weaknesses or architectural deficiencies? 17:30:33 specific weaknesses... 17:30:46 at any level, but the kind of stuff that would result in a CVE. 17:30:49 hyakuhei and I have discussed this for HP in the past, we're in favour in principal. This is particuarly something we've talked about with threat analysis, but it makes sense to do so in general 17:31:04 yeah, I'm +1 on the idea 17:31:19 I think it could be executed pretty easily 17:31:21 would just need to setup a controlled way of handling it 17:31:27 singlethink: yah it makes sense if we all can collaborate 17:31:28 so one thing that I think would help us if the community was running bandit... if the scans are good enough then we would only need to scan any new code. 17:31:33 * bdpayne envisions OTR chat 17:31:52 bknudson: agreed on bandit 17:31:54 or rather, the discussions could focus on what bandit can't do 17:32:11 yeah, seems worthy pushing forward 17:32:18 but I'm also thinking of issues that require more than syntactic analysis. Like, authorization bypasses, etc. 17:32:19 human will always find more than bandit 17:32:36 since all of us would require executive sign-off from the overlords we'll probably need some sort of formal statement 17:32:40 Agreed. A tool is only useful in the hands of a skilled artisan 17:33:14 So, is this something that we could socialize with our respective management chains and come back to the table with some ideas of what it would take to make them okay with it? 17:33:32 singlethink: yeah, that seems like a good way to kick it off 17:33:33 * bdpayne has approval already (from self) 17:33:57 * bknudson needs bdpayne-like powers. 17:34:03 Nebula's unencumbered by bureaucracy :D 17:34:07 :-) 17:34:16 Apparently bdpayne is living the dream. 17:34:29 dg_ you want to work with Rob to kick that around for HP? 17:35:02 probably best if you ping Rob, I'm out for most of next week 17:35:08 ok will do 17:35:31 and bknudson you in? 17:35:31 (I should say that, right off the bat, we should make responsible disclosure a non-negotiable and mention that when first socializing the idea.) 17:35:56 tbh, between rob and chair6, I'd say we have approval to pursue this 17:36:13 dg_: good point 17:36:22 singlethink, yes, I agree on the responsible disclosure piece 17:36:35 we should also have a brief writeup with the charter and rules of engagement 17:36:42 tmcpeak: doesn't have bdpayne-like powers, and can't guess what it'll take. 17:36:57 singlethink are you coming to the meetup? this seems like soemthign we should be able to pin down pretty quickly 17:37:11 ... if you come up with something scary enough to our execs that we'll feel left out then that would help. 17:37:18 I wish, I have important internal meetings all through that week 17:37:25 I might be able to make Hangouts though 17:37:27 yeah, meetup seems like a great place to tackle this 17:37:29 but I'm still not sure what we're talking about here. 17:37:56 I think we're talking about coordinating upstream pentesting basically 17:38:15 For example, say we do a dynamic scan of Horizon using our scan product -- do you want to see it? 17:38:19 Some people refer to it as "vulnerability analysis", "penetration testing", etc. But, take our idea of a threat model, and try to realize each threat we can imagine. 17:38:46 bknudson: if it finds vulnerabilities, then definitely :) 17:39:04 bknudson: That would be good, but I'm more interested in the logic errors or issues multiple levels deep that the scan might be missing. 17:39:05 if it finds vulnerabilities then we open bugs already. 17:39:05 Results of course. I think the key thing to share is what is happening to what, so we know what coverage we are getting 17:39:26 and so we aren't just doing the exact same thing that someone has just done 17:39:32 bknudson you may run into licensing issues releasing raw scan output 17:39:35 Take XSS for example, maybe the scan turns up none because the product is using an incomplete, but not terrible sanitization mechanism 17:39:41 ukbelch: +1 17:40:06 shoel (?) was leading a threat analysis piece for keystone 17:40:07 I'm talking about looking at the sanitization mechanisms and seeing if there are ways around them. 17:40:24 shohel02 17:40:26 this feels like it sits ata lower level than threat analysis 17:40:35 so i think we need to be clear what we want 17:40:57 is it threat modelling or penetration testing using some scan tool 17:41:13 or penetration testing the good old fashioned way 17:41:33 I wouldn't rule out the use of tools, but I think it'd be more interesting if it involved a human investigator 17:41:36 I'd call this vulnerability assessment via code review 17:41:38 things always need mulitple eyes, as no one guy finds 100% of issues even with in-depth manual analysis, we just don't need 50 eyes as that's quite a bit of reduncancy 17:41:39 (the old fashioned way) 17:42:15 also, it would be useful for people to think of if there's a partuclar project / projects that they'd want to start wtih 17:42:16 so as bknudson pointed out, when we find bugs, we file them 17:42:23 I'd propose barbican and/or anchor to get our feet wet 17:42:30 most use would come from coordinating in some way 17:42:40 so we don't all put our effort on Keystone and skip everything else 17:42:41 but if we have some idea of how many people have done different kinds of analysis on which products, and how recently, we can at least spot places that haven't had as much attention 17:42:42 bdpayne: I think those would be good candidates 17:42:46 bdpayne: that would be good idea. The only thing is it is a time/resource intensive work if we do in the code level 17:42:54 right, think about this was a way to find bugs through collaboration that would otherwise be harder to find 17:43:08 like a deep dive? 17:43:14 bdpayne anchor would be a willing target for this 17:43:55 we've seen stuff like this before - people get busy and lose interest. If we formalize some clear goals it might help 17:44:07 tmcpeak +1 17:44:18 dg_: +1 17:44:23 I think it might also be useful to time bound any given investigation... 17:44:36 there will always be more stuff to look at than time to do it in. 17:44:50 well it definitely seems like there is some good interest 17:45:04 I'd say next step would be to come up with a proposal so we know specifically what we're agreeing to :) 17:45:23 singlethink: you cool to take the lead on this? 17:45:27 sounds good... I'll take that 17:45:34 perfect 17:45:41 I'm anticipating a rathole on this next oneā€¦ 17:45:45 #topic Rootwrap 17:45:49 that will give people something more concrete to speak with their benevolent overlords about 17:46:10 singlethink: +1 17:46:26 http://lists.openstack.org/pipermail/openstack-dev/2015-February/055971.html 17:46:30 singlethink: i can also help you based on our previous year experience 17:46:48 bknudson: was it you that brought this to our attention? 17:46:56 shohel02: Noted, thanks! 17:47:15 y, just wanted to bring this up since at the cross-project meeting it was mentioned that they had asked a "security" group to audit it or something. 17:47:31 so for anybody that hasn't read the above link, it's interesting 17:47:56 and, wanted to bring the mailing list discussion to your attention since I'd expect security group to have some insights here. 17:48:03 seems like a really tough problem to solve if you have no way to enforce discipline 17:48:06 i.e., what we'd like to see. 17:48:29 my opinion was #1 the preferred option 17:48:33 is it selinux / apparmor, a separate daemon, etc. 17:48:36 we really need some good automation around it though 17:49:13 and maybe someone here has experience with a similar system that's worked for them. 17:49:20 I don't necessarily agree with the author that it isn't automatable 17:51:14 bknudson: what was your take? 17:51:39 I've got to admit I don't have a good solution... haven't been working on it. 17:51:46 luckily keystone doesn't need rootwrap 17:51:49 reading through this, I think that (1) is the only viable option 17:51:50 (2) and (3) are just... bad 17:51:56 bdpayne: +1 17:52:05 it's really important to get this right 17:52:09 I doubt that a string-based config file filter is ever going to be adequate. 17:52:17 just like the existing sudo config isn't 17:52:43 so that makes me think that a separate daemon that accepts specific commands is a better choice. 17:53:00 I think this was mentioned in a reply. 17:53:17 bknudson: again though, somebody needs chmod and that it's open season on chmod calls? 17:53:34 all it takes is a couple required usages of the big few commands and then the system is wide open anyway 17:53:38 bknudson: That would be my initial conclusion too. 17:54:03 y, but hopefully it's not chmod , hopefully the command sent to the daemon is "give authority to me on the file for " 17:54:15 so here's the thing... the openstack community has been noting this as an open problem for ages 17:54:16 so you can't chmod whatever you want. 17:54:17 no one has stepped up to offer solutions 17:54:34 right 17:54:36 it's a tough problem 17:54:49 I see this going in a direction that we don't like UNLESS perhaps if OSSG can step in with a solution 17:54:55 especially in light of a lack of consistent security review for checkins 17:55:28 maybe if there's a separate daemon it's in a project where ossg has +2. 17:55:45 perhaps 17:55:59 I think it could be good to put together a team of OSSG people to research the issue and come back with a suggestion 17:56:06 and let Thierry know that we are doing that 17:56:13 bdpayne: +1 17:56:19 to potentially delay a bad decision 17:56:32 perhaps kick it off at the meetup 17:56:33 ? 17:56:36 does that seem like something we want to try to tackle at meetup? 17:56:38 yeah, that ^ 17:57:00 bknudson: would you be interested in leading this at the meetup? 17:57:14 sure, that would give me something to do. 17:57:21 I don't want to volunteer you for work, but it seems like a good fit for you 17:57:34 awesome, throw something on etherpad? 17:57:40 will do. 17:57:47 bknudson: cool! 17:57:58 allright, time check - we've got 3 mins 17:58:02 #topic Other Business 17:58:05 anything else? 17:58:48 I'll take that as no 17:58:53 have a good week everybody :) 17:59:02 thank tmcpeak 17:59:02 #endmeeting