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