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