15:00:43 <gagehugo> #startmeeting security
15:00:43 <openstack> Meeting started Thu May 16 15:00:43 2019 UTC and is due to finish in 60 minutes.  The chair is gagehugo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:46 <openstack> The meeting name has been set to 'security'
15:00:55 <fungi> whee!
15:01:06 <gagehugo> #link https://etherpad.openstack.org/p/security-agenda agenda
15:01:08 <efried> o/
15:01:28 <gagehugo> o/
15:01:43 <efried> (kashap, interested?)
15:01:50 <efried> kashyap: typo ^
15:03:00 <gagehugo> #topic spam pinging
15:03:25 * gagehugo lost the link he was saving
15:04:03 <fungi> fwiw, i got a highlight on this buffer when you did the startmeeting, so no need to ping me .;)
15:04:12 <gagehugo> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006235.html
15:04:38 <efried> if someone can figure out how to do highlight regexes in thunderbird IRC client, let me know please.
15:04:43 <fungi> (also the remind utility lets me know when the meeting is due to start)
15:05:15 <gagehugo> the ptl tips and tricks session in Denver, it was mentioned that spamming people is bad IRC etiquette, so I'll start sending a reminder in openstack-security prior to the meeting
15:05:43 <gagehugo> and less spamming
15:05:58 * gagehugo needs to setup highlight for startmeeting
15:06:24 <gagehugo> #topic On reporting CPU flags that provide mitiation
15:06:32 <gagehugo> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006281.html
15:06:53 <gagehugo> fungi: was this you?
15:07:36 <fungi> well, i added it to the agenda because folks discussing on that ml thread wanted feedback from security-minded members of our community
15:08:53 <gagehugo> ok
15:08:55 <efried> I'll represent, since kashyap and sean-k-mooney aren't around.
15:09:32 <efried> I'll summarize the issue in terms of the bit we need security SIG's advice on.
15:10:20 <efried> CPUs that are vulnerable to spectre/meltdown (or other things) have ways you can find out about that if you're on the host. CPU flags, queries in sysfs, etc.
15:10:58 <efried> Nova has the ability to decorate resource providers with traits and then users can cause instances to be scheduled to (or avoid) hosts that have those traits.
15:11:04 <efried> So the security question is:
15:11:43 <efried> does it pose a security problem for nova to expose traits like "IS VULNERABLE" or "HAS FIX FOR VULNERABILITY" thus allowing users to say "Schedule me to a host that IS VULNERABLE" ?
15:11:59 <efried> My take on this was that it's not a whole lot worse than if you just have that host in your cloud and the user could land on it randomly.
15:12:09 <gagehugo> hmm
15:12:38 <efried> i.e. if there's a vulnerability, there's a vulnerability; you're not making it better by making it slightly harder to exploit.
15:13:02 <fungi> the only reason i can see for surfacing those cpu flags to users is operating systems/kernels which are making behavioral decisions based on their absence/presence. the linux kernel for example has specific optimizations it can perform when it sees the cpu flags which indicate patched microcode for some speculative execution flaws
15:13:23 <fungi> i don't think they're relevant to scheduling decisions
15:13:56 <efried> Yes. Or I might actually want to land on a host that has one of these flags because a) I trust my VM, and b) it gets me better performance.
15:14:16 <efried> further, if we expose the trait, security-auditing agents (outside of nova) would be able to key on it to e.g. completely disable vulnerable hosts
15:15:15 <gagehugo> If we want to ensure non-vulnerable hosts, then being able to specify would be useful
15:16:01 <fungi> maybe i'm misunderstanding, but as a user if given the option to schedule my workload to a vulnerable or non-vulnerable host, i'll always just choose the latter
15:16:21 <gagehugo> yeah
15:16:22 <fungi> unless the idea is that providers might charge more money for non-vulnerable service
15:16:57 <gagehugo> or you have the auditing agents that can check/disable IS VULNERABLE ones
15:16:59 <Tengu> or maybe wants to get better perfs for some non-important tasks, since meltdown correction slows down the perfs
15:17:14 <cdent> what Tengu said is the main thing
15:17:20 <fungi> or that for a private deployment i might select some portion of my workloads which aren't at risk of whatever a given vulnerability is and use that to distribute better
15:18:13 <fungi> but in my opinion, none of those are security-relevant choices, they're choices which just happen to be related to security-oriented information
15:18:29 <efried> point is, there are reasons to want to schedule to a "non-vulnerable" host, and there are reasons to want to schedule to a "vulnerable" host even if you're not a hacker.
15:18:59 <efried> And if you're a hacker, not having these traits exposed doesn't prevent you from being scheduled to a vulnerable host. Something else has to do that.
15:19:09 <efried> (whoah, that was a lot of negatives)
15:19:15 <gagehugo> heh
15:19:34 <gagehugo> are there any downsides to exposing those then?
15:20:46 <fungi> my only real concern in this is that we expose the appropriate flags in the guest instances so that kernels know how to operate. scheduling decisions aren't anything which i care about either way. if users want to choose to run workloads on unpatched servers and providers want to make that an option then those are the operators and users you want to hear from
15:25:57 <gagehugo> we don't want "hackers" to be able to target vulnerable systems, but they can still get scheduled to vulnerable systems anyway as is
15:27:29 <gagehugo> imo I would assume operators would typically want to use NOT VULNERABLE for most cases (outside of non-risk workloads for performance gains)
15:28:02 <fungi> yeah, if a provider doesn't want anyone scheduled to vulnerable systems, disable/patch those systems. scheduler roulette is not a security measure
15:29:08 <fungi> i hear plenty of stories from providers of malicious users spinning up batches of servers, often with some anti-affinity, to attempt to land on particular hosts
15:30:46 <efried> Cool, sounds like we have agreement.
15:31:06 <efried> fungi: would you like to be the one to address this on the thread, or would you like me to do so?
15:31:26 <fungi> i can add replying to my to do pile, but it may not happen until tomorrow
15:31:47 <efried> I've already got a response started for other pieces, I can add this if you like.
15:32:10 <fungi> oh, in that case feel free and i'll just mee-too yours ;)
15:32:11 <efried> (should have led with that, but forgot I hadn't already sent it :)
15:32:28 <efried> ight, will do. Thanks y'all.
15:34:08 <kashyap> efried: Sorry, I was (and am) stuck in conflicting meetings :-(
15:34:27 <fungi> kashyap: no worries, me too!
15:34:29 <efried> kashyap: no worries, we figured it out, stand by for ML response.
15:35:26 <kashyap> efried: Yeah, noted.  Most appreciated.  I will pay attention to the list
15:35:58 <kashyap> (Better to sort out on the e-mail these things.)  Thanks for all the responses, everyone.
15:37:44 <gagehugo> cool, I can chime in as well if needed
15:38:02 <gagehugo> #topic Summit BoF Session
15:38:34 <gagehugo> the security SIG has a BoF session at the summit, the notes from that were mailed out, but can also be found here
15:38:35 <fungi> that week was such a blur... did i show up to the bof?
15:38:37 <gagehugo> #link https://etherpad.openstack.org/p/security-sig-denver-summit
15:38:42 <gagehugo> yes haha
15:39:00 <gagehugo> I was writing on the tiny whiteboard
15:39:42 <gagehugo> #topic open discussion
15:40:12 <gagehugo> I have pangolin stickers (Security mascot) if anyone wants some, will need to figure out mailing
15:40:31 <gagehugo> reach out/ping me if you want some
15:40:37 <gagehugo> otherwise that's all I got
15:40:45 <gagehugo> fungi: anything else?
15:41:06 <fungi> nope, not from me at least
15:41:28 <gagehugo> thanks everyone!
15:41:31 <gagehugo> #endmeeting