17:01:15 <hyakuhei> #startmeeting openstack security group
17:01:16 <openstack> Meeting started Thu Jun 19 17:01:15 2014 UTC and is due to finish in 60 minutes.  The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:20 <openstack> The meeting name has been set to 'openstack_security_group'
17:01:26 <hyakuhei> Hey everybody!
17:01:27 <malini2> greetings!
17:01:34 <tmcpeak> hey!
17:01:35 <hyakuhei> malini2: In the house!
17:01:43 <hyakuhei> Roll Call if you please!
17:01:47 <nkinder_> hey all!
17:01:52 <dg_> Hey
17:01:56 <tmcpeak> happpy Thursday
17:02:16 <hyakuhei> o/
17:02:23 <hyakuhei> Quiet one today…
17:02:23 <CristianF> hi everyone
17:02:35 <hyakuhei> Hey CristianF
17:02:53 <bdpayne> hi
17:03:02 <hyakuhei> Hey bdpayne, glad you could make it
17:03:07 <bdpayne> :-)
17:03:12 <hyakuhei> Ok we’ve got a few people here now.
17:03:25 <hyakuhei> Welcome chair6
17:03:29 <chair6> hi!
17:03:35 <hyakuhei> Ok, so - Agenda Items….
17:03:37 <dg_> hi mate
17:03:48 <hyakuhei> OSSG Meetup
17:04:00 <hyakuhei> Security Review Collaboration
17:04:05 <hyakuhei> … what else?
17:04:25 <bdpayne> finding more hours in the week for me? :-)
17:04:33 <nkinder_> ooh, me too!
17:04:37 <hyakuhei> bdpayne: I got loads of hours going free
17:04:40 <sriramhere> hello all, sorry i am little late, this is sriram
17:04:46 <hyakuhei> I keep them in the vault next to my unicorn stables.
17:04:50 <hyakuhei> Hey sriramhere
17:05:00 <chair6> i call dibs on hyakuheis mystical minutes
17:05:09 <hyakuhei> #topic OSSG Meetup
17:05:16 <nkinder_> #link https://etherpad.openstack.org/p/ossg-juno-meetup
17:05:28 <hyakuhei> So as you all should know we’ve got a meetup planned, and it’s in Seattle so even sriramhere can make it!
17:05:49 <sriramhere> i am indebted! thanks <hyakuhei>
17:06:03 <hyakuhei> A few people have put their names down to lead topics but haven’t put descriptions with them
17:06:17 <bdpayne> I think the location in that etherpad is wrong?
17:06:24 <bdpayne> should be at 7th and Pike?
17:06:43 <hyakuhei> Yeah that’s _wrong_
17:06:50 <hyakuhei> 7th n Pike
17:06:52 <hyakuhei> is correct
17:06:55 <bdpayne> also, I believe the westin listed is wrong
17:07:03 <bdpayne> just an fyi for people making travel arangements
17:07:21 <hyakuhei> bdpayne: you missed your true calling as a travel agent!
17:07:25 <bdpayne> lol
17:07:27 <tmcpeak> haha
17:07:35 <chair6> i'll update that address
17:07:41 <hyakuhei> chair6: I know you’re super busy but as you work in those offices / the city, can you quickly go through and verify please ?
17:07:43 <hyakuhei> ^^ ty :D
17:07:44 <bdpayne> staying in Bellevue would just make the whole trip very frustrating
17:07:51 <hyakuhei> haha indeed
17:08:29 <sriramhere> yup, not bellevue, is it 701 Pike?
17:08:44 <bdpayne> looks like someone is updating the etherpad now
17:08:49 <chair6> yup, updated
17:08:54 <nkinder_> chair6: thx
17:08:57 <chair6> i'll add more details over the next few days
17:09:13 <hyakuhei> We’ve got a couple of suggested topics with no leaders and not much interest, namely Security Anti Patterns and Library Audit - Would anyone like to work/lead these? If not I’ll trim them from the agenda...
17:09:41 <bdpayne> I vote to trim
17:09:44 <bdpayne> we have lots of topics
17:09:46 <sriramhere> Rob, looks like we have a whole lot to cover
17:09:50 <hyakuhei> That would be my preference
17:09:57 <nkinder_> +1, we have too much already
17:09:58 <sriramhere> let us try to schedule the ones for now, then add these two if time permits
17:09:59 <tmcpeak> yeah, we should have more than enough to cover four days
17:10:06 <sriramhere> +1 to trim
17:10:07 <hyakuhei> but I’m giving people who desperately want to do these things but have been shy thus far the opportunity to speak up
17:10:26 <hyakuhei> sriramhere: what do you want to do about Fuzz Testing?
17:10:59 <tmcpeak> I'm interested in fuzz testing, I've done some before
17:11:09 <tmcpeak> we could just get a basic API fuzzer going
17:11:12 <hyakuhei> It’s there as an agenda item at the moment
17:11:15 <sriramhere> actually, gate test makes more sense than fuzz. i had introduced to add on what is happening at GSOC/ Mark's efforts
17:11:28 <hyakuhei> With the same number of ‘interested’ people as the other things that we are about to trim
17:11:48 <sriramhere> we can prioritize gate testing over fuzzing, since GSOC project may not be ready for adding on to,yet
17:12:24 <tmcpeak> sounds good, I'm going to try to do some good homework so we'll be ready to hit the ground running as much as possible on the gate testing
17:12:40 <sriramhere> tmcpeak, we have other efforts going on now reg fuzzing. API fuzzing is what happenieng over there. a GSOC proj and a BP in submission
17:12:41 <hyakuhei> Ok, I’ll get trimming after this meeting.
17:12:49 <tmcpeak> ahh ok
17:12:51 <sriramhere> we could ge the BP going if there is enough interest
17:12:56 <sriramhere> or focus on gate tests
17:13:01 <sriramhere> i am fine either way
17:13:02 <bdpayne> a lot of these are relelated... if we trim some I suspect the group on the trimmed items may be interested in focusing on the remaining items
17:13:05 <hyakuhei> I’ll email round about confirming you’re coming to the meeting later
17:13:12 <hyakuhei> bdpayne: +1
17:14:29 <hyakuhei> Ok
17:14:42 <hyakuhei> Anything else related to the meetup people would like to discuss?
17:14:59 <sriramhere> it would be good to have a schedule or agenda
17:15:00 <tmcpeak> is everybody planning to stay at Westin?
17:15:02 <hyakuhei> Who’s up for an organised social event of some sort (not sure if it would be sponsored)
17:15:05 <tmcpeak> would be pretty cool if we all stay close
17:15:21 <hyakuhei> sriramhere: sure, after we decide what stays and goes we’ll put the schedule together
17:15:25 <sriramhere> are we doing 1 project at a time, or many at a time with people diveided in grps
17:15:34 <sriramhere> thanks Rob
17:15:47 <tmcpeak> I'm up for a social event
17:15:53 <hyakuhei> sriramhere: 2-3 parallel tasks depending on percieved interest and improtance.
17:15:57 <hyakuhei> *importance
17:16:00 <sriramhere> ok
17:16:06 <nkinder_> tmcpeak: yeah, me too
17:16:17 <bdpayne> +1 on social
17:16:26 <hyakuhei> ok, not sure what to do, chair6 thoughts?
17:16:39 <bdpayne> 50 mile bike ride? :-)
17:16:45 <malini2> +1 social
17:17:00 <hyakuhei> bdpayne: That’s a lot, 25 mile mountain bike ride instead?
17:17:00 <tmcpeak> I'll supervise the bike ride
17:17:11 <chair6> i'll update the etherpad with some social event options
17:17:18 <sriramhere> neat - want a place to hang out, or bike ride, or sightseeing?
17:17:18 <hyakuhei> Sweet, thanks!
17:17:21 <sriramhere> what do u want?
17:17:30 <hyakuhei> Hang out / sight seeing I imagine
17:17:40 <hyakuhei> sriramhere: can you work with chair6 to come up with some nice options please?
17:17:45 <sriramhere> sure
17:17:47 <malini2> sight seeing +1
17:17:58 <CristianF> question referring to gate testing, is static analysis (such as pylint) an option to be analyzed?
17:18:10 <sriramhere> i assume this is out of pocket (not like those evening events at the summit :) )
17:18:15 <tmcpeak> I'm not familiar with Pylint, but I'd like to analyze all options
17:18:30 <hyakuhei> CristianF: yes, if we can do smart things regarding false positives
17:18:33 <bknudson> if pylint for security analysis?
17:18:41 <hyakuhei> Though I think the PEP/Flake stuff does similarish checks
17:18:52 <sriramhere> is pylint a bar :-)
17:18:59 <malini2> what about penetration testing?
17:19:30 * tmcpeak loves penetration testing, but would we have enough time?
17:19:42 <CristianF> yes, pylint has some security test
17:19:43 <viraptor_> CristianF: for other projects? nova already defines pylint in tox.ini
17:19:55 <hyakuhei> It’s a pretty drawn out process, we have some pentesters kicking stuff already
17:20:01 <hyakuhei> we == ‘hp’
17:20:17 <dg_> it would be hard to add pen testing as an automated gate
17:20:34 <tmcpeak> oh, as a gate?
17:20:48 <sriramhere> do u guys want to combine pen testing/ fuzz testing?
17:20:53 <bknudson> seems like anyone could do pen testing and set up CI for it
17:21:05 <bknudson> external CI
17:21:09 <tmcpeak> what's CI?
17:21:19 <dg_> Continuous Integration
17:21:24 <tmcpeak> oh, that CI :)
17:21:25 <bknudson> the continuous integration and testing
17:21:51 <tmcpeak> a good pentest is pretty hard to automate
17:21:52 <hyakuhei> Ok, lets keep this to Automated gate testing atm, discussion of fuzzing/pentesting can follow
17:21:52 <CristianF> viraptor_: is pylint a required test for nova commits? or just optional?
17:22:04 <hyakuhei> no such thing as an automated pentest imho
17:22:17 <tmcpeak> oh viraptor_ I need to pick your brain later :)
17:22:31 <sriramhere> +1 for separating pen test from gates
17:22:54 <hyakuhei> ok, what else on gate tests etc?
17:23:18 <tmcpeak> I'm going to try to get a blueprint for that, would appreciate feedback once I get one going
17:23:38 <viraptor_> CristianF: I believe it's run but the results are ignored at the momen but I may be wrong
17:24:12 <hyakuhei> Someone fancy taking an action to verify that ?
17:24:46 <viraptor_> pylint? I can check later
17:25:36 <hyakuhei> Thanks viraptor_
17:25:41 <bknudson> gate-nova-pylint SUCCESS in 18m 26s (non-voting)
17:25:58 <bknudson> looks like they run it but it's not voting... and it's successful so far
17:26:02 <hyakuhei> non-voting checks
17:26:05 <hyakuhei> That’s the ticket :D
17:26:21 <malini2> The cinder file permissions bug -- OSSN  would be nice if we could add a test "warn"/report it until such time as fixed and ensure it never comes back accidentally.
17:26:24 <tmcpeak> cool, so I'll look into Pylint capabilities
17:26:27 <viraptor_> there you go :)
17:26:29 <bknudson> looks like they have a lot of exceptions
17:26:32 <malini2> bknudson :-) thanks!
17:27:14 <bknudson> Is pylint looking for security issues?
17:27:14 <hyakuhei> malini2: Regression checks are a good idea in general, shuld be added as a code check in the test package for cinder though I think
17:27:31 <nkinder_> hyakuhei: +1
17:28:33 <viraptor_> bknudson: not specifically as far as I know, but it does flag stuff that could become a security problem in some cases (like not exact None checks, etc.)
17:28:48 <viraptor_> mostly it's coding /style issues though
17:29:06 <hyakuhei> Can we add checks easily?
17:29:20 <bknudson> ok, there was some question about whether even the new hacking was a good thing to add at this point in the release
17:29:47 <hyakuhei> bknudson: can you elaborate please?
17:29:55 <tmcpeak> we could try for Juno and push to K if there is too much pushback
17:30:10 <bknudson> I'll see if I can find the discussion on -dev
17:30:14 <hyakuhei> To my mind we need to build checks, test them a lot first
17:30:27 <hyakuhei> and then, when we are happy, work with infra to understand how/where they go
17:30:35 <tmcpeak> hyakuhei: +1
17:30:36 <hyakuhei> indeed each team may elect to bring them in or ignore them
17:30:44 <bknudson> http://lists.openstack.org/pipermail/openstack-dev/2014-June/037784.html
17:30:51 <hyakuhei> that being the case we’ll pick a few of the more security-centric teams to start off with
17:31:20 <hyakuhei> bknudson: Thanks for digging that out
17:31:22 <bknudson> of course pep8 is a voting job so pylint was added nonvoting then that might be ok
17:31:25 * bdpayne leaves for his 10:30 meeting
17:31:29 <bdpayne> cheers!
17:31:37 <tmcpeak> later bdpayne
17:31:37 <hyakuhei> cya bdpayne
17:31:49 <hyakuhei> So long as we are moving in the right direction I’m happy. The anticipation is that our checks will be non voting almost always
17:31:54 <hyakuhei> at least in the first iterations
17:32:18 <bknudson> the tool we ran here (RATS or YASCA or a combo of them) looked for stuff like calling .random()
17:32:44 <hyakuhei> We could ideally do with a quick review of tooling available.
17:32:54 <hyakuhei> I might have someone who can do that.
17:32:55 <bknudson> but it also had a ton of false positives because it flagged any call to .compile (e.g., re.compile
17:33:08 <malini2> BTW, ChristianF and I attended a meeting yesterday where we learned of two devops etherpads, one for keystone: https://etherpad.openstack.org/p/juno-keystone-devops and https://etherpad.openstack.org/p/juno-summit-ops-enterprise
17:33:23 <tmcpeak> hyakuhei: +1, if you know somebody who knows what is available, I'd love to hear that first
17:33:45 <hyakuhei> Ok, I’ll see if I can get half a day of his time to write up some summaries
17:33:56 <hyakuhei> Though Tbh I see some simpler checks coming first
17:33:59 <tmcpeak> sounds good
17:34:02 <malini2> some of them are security aspects that could modify BP priorities or toss in new ones, while others have documentation element for security book
17:34:08 <hyakuhei> one that raises a flag each time Shell=True
17:34:18 <hyakuhei> each cPickle.loads()
17:34:19 <hyakuhei> etc
17:34:22 <tmcpeak> chmod 777
17:34:28 <hyakuhei> exactly
17:34:29 <bknudson> we could provide hacking checks for those
17:34:37 <hyakuhei> Clever tooling is nice but slow going
17:34:39 <CristianF> here is a list of the issues that pylint may detect: http://pylint-messages.wikidot.com/all-messages
17:34:45 <hyakuhei> and noisy
17:34:47 <malini2> +1 .. the anti-pattern tests
17:34:51 <hyakuhei> Lets start with the most basic
17:35:08 <bknudson> was the thought to do this in hacking?
17:35:32 <hyakuhei> I’m not sure where the most appropriate place would be
17:35:36 <hyakuhei> Is that ‘hacking’?
17:36:02 <bknudson> hacking has a lot of infrastructure and examples so might be easiest
17:36:10 <viraptor_> hacking as in code hacking - these are existing extensions for flake8.... so yeah,  checks for 777 would probably belong there
17:36:28 <bknudson> http://git.openstack.org/cgit/openstack-dev/hacking/tree/hacking/checks
17:37:00 <nkinder_> yeah, hacking is probably appropriate
17:37:03 <viraptor_> I believe tmcpeak is going to write something about that in his blueprint
17:37:47 <tmcpeak> viraptor_: yep, although I'm a little behind on what the options all are, so if we can get a good list, I'd be happy to try to implement a basic check in each to provide options and show how easy or hard they are
17:38:07 <viraptor_> good idea
17:38:16 <tmcpeak> so I've got Pylint, hacking, .. others?
17:38:20 <tmcpeak> is PEP the same?
17:38:31 <malini2> could the hacking list be used across all projects, like an include file?
17:38:34 <bknudson> the pep8 check calls hacking
17:38:43 <tmcpeak> oh ok cool, and same for flake?
17:38:48 <viraptor_> flake8/hacking, pylint, pep8 is part of flake8
17:38:59 <tmcpeak> gotcha
17:39:03 <tmcpeak> so Pylint, hacking,...
17:39:11 <bknudson> right it's all kind of the same thing... openstack-dev/hacking are the openstack additions
17:39:19 <tmcpeak> homegrown script?
17:39:25 <tmcpeak> grep
17:40:31 <hyakuhei> for line in readlines() :P
17:40:39 <tmcpeak> +1
17:40:48 <viraptor_> just for comparison? why not. but flake8 has a line-by-ilne interface which understands logical lines - so strictly better than grep
17:41:00 <tmcpeak> ok cool
17:41:42 <tmcpeak> do you think this would be a good topic for a ML discussion?
17:41:49 <tmcpeak> maybe other people have some viable options too
17:41:53 <hyakuhei> Yeah I think so
17:42:00 <hyakuhei> Though probably -dev with the [OSSG] tag
17:42:13 <tmcpeak> ok cool
17:42:36 <tmcpeak> I'll take a todo item to get out a little blurb on dev about what we're trying to do to solicit some ideas
17:43:34 <hyakuhei> #action tmcpeak to kick off a thread on -dev regarding basic gate tests
17:43:52 <tmcpeak> cool
17:44:31 <hyakuhei> #topic Security Collaboration
17:44:51 <hyakuhei> A few days back I sent an email to -dev about Security and how we need to start working together
17:45:15 <hyakuhei> #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/037413.html
17:45:56 <nkinder_> hyakuhei: so you are looking for a few things here as I understand it...
17:45:57 <tmcpeak> oh cool, this looks good
17:46:02 <nkinder_> 1 - sharing any existing work
17:46:06 <hyakuhei> I’ve had conversations with Rackspace and Redhat, both are interested in working together more openly. Can any of you take this back to your respective organisations and tryto get mrore buy in
17:46:12 <nkinder_> 2 - coordinating on future efforts in public
17:46:17 <hyakuhei> 1 - Share anything you’re willing to
17:46:30 <tmcpeak> I'll kick it around Symantec
17:46:41 <hyakuhei> 2 - Absolutely, starting with Threat Modelling and looking at setting up test systems for combined pentests etc
17:47:23 <hyakuhei> tmcpeak: Thanks :)
17:47:30 <hyakuhei> Ok, so that’s pretty much all I had
17:47:37 <hyakuhei> #topic Any other business ?
17:47:39 <nkinder_> hyakuhei: it might be a good idea to get something like a "bug squash day" or "test day" approach going for threat modelling work
17:47:58 <tmcpeak> nkinder_: +1
17:48:11 <hyakuhei> Potentially yeah, I’m a bit concerned that the threat analysis stuff isn’t moving fast enough
17:48:13 <nkinder_> hyakuhei: regularly scheduled days where we pick a project and try to get folks to pitch in at the same time
17:48:29 <hyakuhei> Could be good to do on a Lync/Hangout or something
17:48:41 <hyakuhei> We need good architecture diagrams for the service being examined though
17:49:08 <tmcpeak> yeah, we encountered some difficulty when trying to do Keystone Threat Modeling
17:49:17 <tmcpeak> because of lack of architectural understanding
17:49:27 <tmcpeak> it's very difficult to find good diagrams for how it works
17:49:49 <tmcpeak> /s/difficult/impossible
17:49:56 <hyakuhei> Oh yeah, you need domain experts in the room
17:50:10 <nkinder_> tmcpeak: it's not impossible if you read the code.. ;)
17:50:23 <nkinder_> basically, domain experts are needed as hyakuhei says
17:50:36 <hyakuhei> bknudson: You’re up -
17:50:42 <hyakuhei> 10 minutes, keystone review, lets go!
17:50:55 <hyakuhei> ….no ? … ok then :)
17:50:59 <nkinder_> there are also many ways to set each service up (especially with keystone), which may affect that threat modelling finds
17:50:59 <bknudson> seems like most of the issues lately are about trusts
17:51:17 <CristianF> agreed, for the work I started on Nova threat modelling either, I should collect information to get at least a high level/up to date overview of the module
17:51:23 <bknudson> keystone is a pretty simple arch compared to for example nova
17:51:28 <bknudson> it's only got the one service that runs
17:51:48 <hyakuhei> True
17:51:52 <bknudson> there's different plugins for the backends which complicates things
17:51:52 <chair6> is anyone else looking at the Code Spaces and Bonsai annoucements about AWS takeovers in the last 24 - 48 hours with bad brokenness resulting?
17:51:59 <hyakuhei> So it’s IAM and it’s Simple, thats a good place to start
17:52:05 <hyakuhei> chair6: Scary stuff
17:52:17 <hyakuhei> Though at least in the case of CS not really a cloud specific issue
17:52:54 <hyakuhei> So some dev got their creds owned and they were used to take down their infrastructure, I mean, I’m personally amused that it was AWS but I don’t think there’s really much blame to be laid at Amazon’s door…
17:53:18 <chair6> yeah, but some good questions to be asked about what we could to to prevent
17:53:42 <hyakuhei> +1
17:53:48 <tmcpeak> chair6: I read an article about that
17:53:53 <chair6> in code spaces case, they had a window of time before bad shit was done .. what about a 'read-only' flag that immediately locks web/API admin access on a per-tenant or other basis?
17:54:23 <chair6> that's just one thought that came to mind so far..
17:54:53 <hyakuhei> chair6: Yeah, a big-red button for non-destructive actions
17:55:06 <hyakuhei> Could be abused itself of course but perhaps not in such an agressive way.
17:55:27 * viraptor_ is out, hotspot battery dying
17:55:30 <hyakuhei> I suppose the only way to do it would be to augment the keystone token somehow
17:55:32 <nkinder_> I think requiring stronger credentials to get keystone tokens is one good step to help here.
17:55:45 <tmcpeak> "While Code Space claims that the attacker did not have access to the computers at the firm, they did have a number of backup login details for the company’s Amazon EC2 account. When Code Spaces tried to change the passwords for EC2, the attacker used these backup login credentials to delete artifacts from the control panel. The company managed to regain control of the panel after a while, but not before most of the service’s data, backups,
17:56:57 <nkinder_> limiting tokens could also help in case a token is intercepted
17:57:24 <nkinder_> I recently wrote up some ideas about this - https://blog-nkinder.rhcloud.com/?p=101
17:57:30 <hyakuhei> I can see another blog post
17:57:32 <hyakuhei> oh nvm
17:57:34 <nkinder_> heh
18:00:27 <nkinder_> ok, time's up
18:01:28 <aignatov> Hello, Saharians, are you here? :)
18:01:37 <elmiko> yo!
18:01:41 <nkinder_> #endmeeting