14:03:02 #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings 14:03:02 Meeting started Thu Jan 8 14:03:02 2015 UTC. The chair is Sparks. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:03:05 #meetingname Fedora Security Team 14:03:05 The meeting name has been set to 'fedora_security_team' 14:03:08 d-caf: Hi, 14:03:09 #topic Roll Call 14:03:15 * Sparks 14:03:32 * pjp here 14:03:33 here 14:03:38 .fas bvincent 14:03:39 bvincent: bvincent 'Brandon Vincent' 14:06:59 * Sparks is woefully ill-prepared this morning so we'll just keep this abbreviated. 14:07:26 #topic Open floor discussion/questions/comments 14:07:33 Anyone have anything? 14:08:09 Not really, just getting back into the swing of things from the new year 14:08:10 The SSH PermitRootLogin feature has been announced, 14:08:33 pjp: Has that been figured out? 14:08:53 Sparks: figured out? 14:09:08 pjp: The logistics around it all. 14:09:14 pjp: where was it announced? 14:09:23 d-caf: devel-annouce 14:09:36 ok 14:10:14 Sparks: Well, anaconda already supports creating non-root user, so is true for cloud images via libvirt, 14:10:26 okay 14:10:28 #link https://lists.fedoraproject.org/pipermail/devel-announce/2015-January/001492.html 14:10:54 Sparks: even for users who do not wish to create non-root users, it is fairly easy to enable remote root login %post install via kickstart file 14:11:30 Sparks: -> https://lists.fedoraproject.org/pipermail/security/2014-December/002061.html 14:12:24 I guess the approach could differ slightly as per the tool used to create such images, but shouldn't be difficult or impossible, 14:12:28 pjp: +1 14:12:35 Anyone have anything else? 14:13:42 Many of the bugs that I had pinged last month have been closed, though there are others that need to be pinged again 14:15:16 That's good 14:15:25 ping someone on the denyhosts bug please 14:15:38 Southern_Gentlem: ? 14:15:39 https://bugzilla.redhat.com/show_bug.cgi?id=1129747 14:15:46 * pjp clicks 14:16:25 the workaround works but still needs to be fixed 14:16:44 Southern_Gentlem: Is that a security one? 14:16:58 to me it should be 14:17:21 Fail2ban has a similar problem with crashing from heavy load 14:18:06 Should we be keeping packages 8 years old? 14:18:15 That is the last release from upstream. 14:20:31 so I have a question 14:20:50 bvincent: Well, as long as there is a maintainer for it, it's okay. 14:21:00 recently, the security team opened bugs to one of my package, libhtp, in all fedora versions: https://bugzilla.redhat.com/show_bug.cgi?id=1173608 14:21:02 pjp: "maintainer" 14:21:18 I pushed the updates out asap (pjp even helped me figure some stuff out) 14:21:28 that was almost a month ago 14:21:30 Southern_Gentlem: so what's the security impact there? 14:21:41 it would be nice if someone from the security team could ack that the updates actually fix the issue... 14:21:56 It's just funny that people use DenyHosts with TCP Wrapper (which hasn't seen an upstream release since 1997). 14:22:03 Better solutions exist... 14:23:13 bvincent, better solutions, like what? 14:23:16 bochecha: Maybe fedora-qa folks could help? Not sure though. 14:23:28 fenrus02: netfilter/iptables 14:23:47 bvincent, those are broken by firewalld being default. 14:24:29 fenrus02: I assume that is a bug in firewalld? 14:24:51 bvincent, not so much a bug as an intentional design decision. firewalld lacks the functionality entirely. 14:25:00 pjp, well, security team seems better place to evaluate whether a vulnerability is fixed or not 14:25:17 pip Denyhosts is a watchdog service for sshd 14:25:35 fenrus02: if we are trying to deny a host from brute force, then fail2ban with firewalld and iptables is a solution 14:25:58 d-caf, in theory sure. again, firewalld completely lacks the required ability. 14:26:11 d-caf, ipt certainly has it, no question there. 14:26:28 bochecha: True, but testing it is fairly taxing task, considering the limited bandwidth to address current issues. 14:27:04 pip this is a issue fro f20 f21 everything works 14:27:11 fenrus02: Are you talking about firewalld handling the entire SSH brute force protection? 14:27:20 pjp, sure, it still seems like the responsibility of a security team 14:27:39 bvincent, no. for example - tell firewalld to allow ssh from only 5 specific ip addresses. 14:28:00 fenrus02: Yeah, that feature is definitely missing in firewalld. 14:28:02 bvincent, or the opposite - deny ssh attempt from only 5 specific ips 14:28:32 fenrus02: Sorry I meant to use iptables in conjunction with something like fail2ban. I thought you were suggesting that manual iptables entries were getting removed or changed due to firewalld. 14:28:38 Sparks, i'm told that is a design decision, not a bug. is that inaccurate ? 14:28:49 bochecha: I beg to differ on that, 14:28:52 bvincent, iptables rules are clobbered by firewalld intentionally. 14:29:13 bvincent, this is why i said iptables certainly can, but firewalld as a default cannot. 14:29:14 fenrus02: I have no idea but it's a bad decision if it's a "feature". 14:29:35 Sparks, fair. that makes it a design decision. 14:29:38 pip i use denyhosts to allow only 5 ips to be able to ssh into my box the rest are moved to hosts.deny and i go on my merry way 14:29:49 bochecha: other than setting up my own personal lab at home, the security team doesn't have any testing resources that I know of (qa has those) 14:29:56 pjp, well, it seems a bit easy to open bug reports, ask a volunteer to fix something as quickly as possible, and then refuse to give him a hand testing the fix, especially when the volunteer isn't sure of the fix 14:30:14 d-caf, you're saying the security team doesn't even reproduce the security bugs they report? 14:30:37 bochecha: the security team isn't neccesarily the ones reporting the bugs 14:30:55 fenrus02: So any firewall changes made via iptables after firewalld starts running don't apply?\ 14:30:56 bochecha: we just try to help encourage reported bugs to be fixed and help where we can 14:31:11 bvincent, try it out. 14:31:27 d-caf, the blocker for the bugs I'm talking about have: Assigned To: Red Hat Product Security (edit) (take) 14:31:28 bvincent, make some custom changes via iptables lines, then wait a few mins. verify your changes are present 14:31:41 fenrus02: Great... 14:31:44 bochecha: I understand, though as said testing it is taxing task to do for all such bugs, fedora-qa folks already do that, 14:31:47 bvincent, if you want them to really stick - you have to use firewallcmd 14:32:01 bvincent, which again, is massively limited 14:32:04 bochecha: that's not to say I don't try and test fixes where/when I can, cause I care 14:32:11 fenrus02: Now I know why I write the rules myself... Thanks a lot firewalld. 14:32:34 pjp, you're just putting the blame on another team here... we're all fedora qa 14:32:46 bochecha: Red Hat Product SEcurity is not the fedora security team 14:32:46 bochecha: We don't really have a security QE team for Fedora. 14:33:05 bochecha: No, I'm not blaming anyone. 14:33:10 Sparks, that's not what this meeting is? 14:33:18 d-caf: we are speaking of Fedora, not RH 14:33:39 d-caf, wait, so why do I get "Red Hat Product Security" bugs in Fedora then? 14:34:09 if they are not the fedora security team, then I'm entirely confused 14:34:15 Red Hat Product Security reported the bug, and the bug also applied to Fedora (as well as redahat products) 14:34:18 bochecha: That's because they investigate the issue for Fedora packages too. 14:34:52 ok, so first of all, my apologies for barging in here and accusing you (fedora security team) for the wrongdoings of the redhat security team :) 14:35:04 bochecha: I'm on the fedora security team, but in no way a RedHat employee 14:35:05 second, can we get this situation to be less confusing, please? 14:35:10 What is Red Hat Product Security doing wrong? 14:35:15 bochecha: no worries, no barging or accusing 14:35:40 Sparks, well, I'd rather not continue polluting this meeting with this, now that I realize I'm in the wrong place :) 14:35:55 Sparks, wrong? nothing afaict. just their scope doesnt include fedora packages by policy. it's nice to have them look at fedora packages though 14:36:21 fenrus02: They do look at Fedora packages... right before they get into RHEL. :) 14:36:28 bochecha: fine place to bring up wanting your thing tested, and maybe we can find a way to help get it tested 14:36:32 Sparks: +1 14:36:36 the issue i guess is around exceptation of the bug open 14:36:47 misc, exactly 14:36:48 Sparks, exactly. simply awesome would be to expand that group into looking at all fedora + rhel packages, but that costs real money 14:36:58 fenrus02: Yep. 14:37:01 while they are open as FYI type of bug, it seems bochecha has a different expectation regarding getting help to make sure they are fixed 14:37:12 so the question is how to reconcile the 2 14:37:25 finding a bug opened in Fedora packages, assigned to a « security team », I thought they were from the fedora security team (which is why I'm here) 14:37:32 when in fact, I should have gone somewhere else 14:37:33 misc: It would be great if Fedora QA would test these fixes. 14:37:44 fenrus02: Looks like you're right. firewallcmd-ipset is the way to go. 14:37:53 misc: IIUC, bochecha wants to confirm if the update he pushed fixed the issue, which seems like what fedora-qa could do. 14:37:57 Sparks, fedora QA might not even have the expertise to understand the security issue 14:37:59 Sparks, to do that - the POC would need to be in the bz report. :/ 14:38:06 Sparks: yeah, but you know as well as me this requires sometime specific testing skills that not everybody have 14:38:14 I mean, the maintainer might not have the security expertise either (I know I don't) 14:38:16 Sparks: and fedora-qa do also ask to the reporter to test the fix 14:38:19 misc: Agreed. 14:38:20 so back to square 1 14:38:44 ( or at least, taht's the content of the automated message I get when there is a upgrade ) 14:38:45 misc: To be honest, there are several square 1 issues in Fedora now that we need to look at. 14:38:47 fenrus02: That file uses firewall-cmd. Thanks for the info. 14:39:00 Sparks: I agree numerotation is suboptimal :) 14:39:09 but again, I thought I asking the reporter here, and it turns out I'm not, so I'm going to go and complain to the red hat security team, now ;) 14:39:14 bochecha: let's see, I'll have a look at it in few days, if it's okay with you. 14:39:29 bochecha: I'm right here. 14:39:33 bvincent, anyhow - back on track. true that denyhosts / tcpwrappers have not been updated in years - but there is no viable replacement today given the defaults. 14:39:35 pjp, of course it is, thank you very much :) 14:40:23 bochecha: cool! 14:41:37 Sparks: for example, I know that not all reproducer can be shared, but some can, so adding a way to verify the problem could alleviate the problem ? 14:42:05 ( maybe that's already done, just trying to find a idea ) 14:43:49 misc: Yes. If the bug also exists in RHEL then QE I think puts the reproducer in the bug. 14:44:07 Sparks: PST should put it in 14:44:22 jrusnack: +1 14:45:24 so trouble are fedora-only bugs that are missing analysis from PST, which makes verification impossible. pjp talked about this in past, that FST should do analysis, right ? 14:46:05 jrusnack: Yes, we already do that for most part 14:47:08 pjp: so, if we do analyse the bug, it should have steps to reproduce. So in theory if it does, bochecha would not complain. Plus it would be FST responsiblitity (do I understand correctly) ? 14:48:48 jrusnack: Oh, by analysis I meant whether a given bug could have security implications, why and if the patch fixes it. Steps to reproduce it quite different IMO. 14:49:26 jrusnack: Such steps may not always be available or easily doable. 14:49:58 pjp: well that is enought too. If we confirm patch fixes it, then verifying patch was applied equals to testing if it was fixed. 14:50:23 jrusnack: Right, 14:51:16 sounds good. 14:51:39 jrusnack: What bochecha seeks to confirm is, after the patch is applied, how do we confirm that the new build is not vulnerable. 14:52:14 pjp: your answer above. For fedora only bugs we do sanity only - check the patch was applied and package is sane. 14:53:07 jrusnack: And investing the security implications is critical too. 14:53:56 jrusnack: for ex. -> BZ#1129747 mentioned above, the implications are not readily clear, the bug is also not tagged as security one, 14:54:36 Okay, anyone have anything else? 14:54:39 pjp: imho not vulnerability 14:56:35 Nothing in particular for me 14:57:14 Ah - happy new year to all! :) 14:57:36 Okay, everyone have a good day. I hope to be better prepared next week. 14:57:38 Happy new year to you all as well! 14:58:09 #endmeeting