14:03:02 <Sparks> #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings
14:03:02 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:05 <Sparks> #meetingname Fedora Security Team
14:03:05 <zodbot> The meeting name has been set to 'fedora_security_team'
14:03:08 <pjp> d-caf: Hi,
14:03:09 <Sparks> #topic Roll Call
14:03:15 * Sparks 
14:03:32 * pjp here
14:03:33 <d-caf> here
14:03:38 <bvincent> .fas bvincent
14:03:39 <zodbot> bvincent: bvincent 'Brandon Vincent' <Brandon.Vincent@asu.edu>
14:06:59 * Sparks is woefully ill-prepared this morning so we'll just keep this abbreviated.
14:07:26 <Sparks> #topic Open floor discussion/questions/comments
14:07:33 <Sparks> Anyone have anything?
14:08:09 <d-caf> Not really, just getting back into the swing of things from the new year
14:08:10 <pjp> The SSH PermitRootLogin feature has been announced,
14:08:33 <Sparks> pjp: Has that been figured out?
14:08:53 <pjp> Sparks: figured out?
14:09:08 <Sparks> pjp: The logistics around it all.
14:09:14 <d-caf> pjp: where was it announced?
14:09:23 <pjp> d-caf: devel-annouce
14:09:36 <d-caf> ok
14:10:14 <pjp> Sparks: Well, anaconda already supports creating non-root user, so is true for cloud images via libvirt,
14:10:26 <Sparks> okay
14:10:28 <bvincent> #link https://lists.fedoraproject.org/pipermail/devel-announce/2015-January/001492.html
14:10:54 <pjp> 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 <pjp> Sparks: -> https://lists.fedoraproject.org/pipermail/security/2014-December/002061.html
14:12:24 <pjp> 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 <Sparks> pjp: +1
14:12:35 <Sparks> Anyone have anything else?
14:13:42 <pjp> 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 <Sparks> That's good
14:15:25 <Southern_Gentlem> ping someone on the denyhosts bug please
14:15:38 <pjp> Southern_Gentlem: ?
14:15:39 <Southern_Gentlem> https://bugzilla.redhat.com/show_bug.cgi?id=1129747
14:15:46 * pjp clicks
14:16:25 <Southern_Gentlem> the workaround works but still needs to be fixed
14:16:44 <pjp> Southern_Gentlem: Is that a security one?
14:16:58 <Southern_Gentlem> to me it should be
14:17:21 <d-caf> Fail2ban has a similar problem with crashing from heavy load
14:18:06 <bvincent> Should we be keeping packages 8 years old?
14:18:15 <bvincent> That is the last release from upstream.
14:20:31 <bochecha> so I have a question
14:20:50 <pjp> bvincent: Well, as long as there is a maintainer for it, it's okay.
14:21:00 <bochecha> 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 <Sparks> pjp: "maintainer"
14:21:18 <bochecha> I pushed the updates out asap (pjp even helped me figure some stuff out)
14:21:28 <bochecha> that was almost a month ago
14:21:30 <pjp> Southern_Gentlem: so what's the security impact there?
14:21:41 <bochecha> it would be nice if someone from the security team could ack that the updates actually fix the issue...
14:21:56 <bvincent> It's just funny that people use DenyHosts with TCP Wrapper (which hasn't seen an upstream release since 1997).
14:22:03 <bvincent> Better solutions exist...
14:23:13 <fenrus02> bvincent, better solutions, like what?
14:23:16 <pjp> bochecha: Maybe fedora-qa folks could help? Not sure though.
14:23:28 <bvincent> fenrus02: netfilter/iptables
14:23:47 <fenrus02> bvincent, those are broken by firewalld being default.
14:24:29 <bvincent> fenrus02: I assume that is a bug in firewalld?
14:24:51 <fenrus02> bvincent, not so much a bug as an intentional design decision.  firewalld lacks the functionality entirely.
14:25:00 <bochecha> pjp, well, security team seems better place to evaluate whether a vulnerability is fixed or not
14:25:17 <Southern_Gentlem> pip Denyhosts is a watchdog service for sshd
14:25:35 <d-caf> fenrus02: if we are trying to deny a host from brute force, then fail2ban with firewalld and iptables is a solution
14:25:58 <fenrus02> d-caf, in theory sure. again, firewalld completely lacks the required ability.
14:26:11 <fenrus02> d-caf, ipt certainly has it, no question there.
14:26:28 <pjp> bochecha: True, but testing it is fairly taxing task, considering the limited bandwidth to address current issues.
14:27:04 <Southern_Gentlem> pip this is a issue fro f20  f21 everything works
14:27:11 <bvincent> fenrus02: Are you talking about firewalld handling the entire SSH brute force protection?
14:27:20 <bochecha> pjp, sure, it still seems like the responsibility of a security team
14:27:39 <fenrus02> bvincent, no.  for example - tell firewalld to allow ssh from only 5 specific ip addresses.
14:28:00 <Sparks> fenrus02: Yeah, that feature is definitely missing in firewalld.
14:28:02 <fenrus02> bvincent, or the opposite - deny ssh attempt from only 5 specific ips
14:28:32 <bvincent> 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 <fenrus02> Sparks, i'm told that is a design decision, not a bug. is that inaccurate ?
14:28:49 <pjp> bochecha: I beg to differ on that,
14:28:52 <fenrus02> bvincent, iptables rules are clobbered by firewalld intentionally.
14:29:13 <fenrus02> bvincent, this is why i said iptables certainly can, but firewalld as a default cannot.
14:29:14 <Sparks> fenrus02: I have no idea but it's a bad decision if it's a "feature".
14:29:35 <fenrus02> Sparks, fair.  that makes it a design decision.
14:29:38 <Southern_Gentlem> 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 <d-caf> 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 <bochecha> 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 <bochecha> d-caf, you're saying the security team doesn't even reproduce the security bugs they report?
14:30:37 <d-caf> bochecha: the security team isn't neccesarily the ones reporting the bugs
14:30:55 <bvincent> fenrus02: So any firewall changes made via iptables after firewalld starts running don't apply?\
14:30:56 <d-caf> bochecha: we just try to help encourage reported bugs to be fixed and help where we can
14:31:11 <fenrus02> bvincent, try it out.
14:31:27 <bochecha> d-caf, the blocker for the bugs I'm talking about have: Assigned To: 	Red Hat Product Security (edit) (take)
14:31:28 <fenrus02> bvincent, make some custom changes via iptables lines, then wait a few mins.  verify your changes are present
14:31:41 <bvincent> fenrus02: Great...
14:31:44 <pjp> 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 <fenrus02> bvincent, if you want them to really stick - you have to use firewallcmd
14:32:01 <fenrus02> bvincent, which again, is massively limited
14:32:04 <d-caf> bochecha: that's not to say I don't try and test fixes where/when I can, cause I care
14:32:11 <bvincent> fenrus02: Now I know why I write the rules myself... Thanks a lot firewalld.
14:32:34 <bochecha> pjp, you're just putting the blame on another team here... we're all fedora qa
14:32:46 <d-caf> bochecha: Red Hat Product SEcurity is not the fedora security team
14:32:46 <Sparks> bochecha: We don't really have a security QE team for Fedora.
14:33:05 <pjp> bochecha: No, I'm not blaming anyone.
14:33:10 <bochecha> Sparks, that's not what this meeting is?
14:33:18 <misc> d-caf: we are speaking of Fedora, not RH
14:33:39 <bochecha> d-caf, wait, so why do I get "Red Hat Product Security" bugs in Fedora then?
14:34:09 <bochecha> if they are not the fedora security team, then I'm entirely confused
14:34:15 <d-caf> Red Hat Product Security reported the bug, and the bug also applied to Fedora (as well as redahat products)
14:34:18 <pjp> bochecha: That's because they investigate the issue for Fedora packages too.
14:34:52 <bochecha> 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 <d-caf> bochecha: I'm on the fedora security team, but in no way a RedHat employee
14:35:05 <bochecha> second, can we get this situation to be less confusing, please?
14:35:10 <Sparks> What is Red Hat Product Security doing wrong?
14:35:15 <d-caf> bochecha: no worries, no barging or accusing
14:35:40 <bochecha> 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 <fenrus02> 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 <Sparks> fenrus02: They do look at Fedora packages... right before they get into RHEL.  :)
14:36:28 <d-caf> 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 <pjp> Sparks: +1
14:36:36 <misc> the issue i guess is around exceptation of the bug open
14:36:47 <bochecha> misc, exactly
14:36:48 <fenrus02> 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 <Sparks> fenrus02: Yep.
14:37:01 <misc> 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 <misc> so the question is how to reconcile the 2
14:37:25 <bochecha> 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 <bochecha> when in fact, I should have gone somewhere else
14:37:33 <Sparks> misc: It would be great if Fedora QA would test these fixes.
14:37:44 <bvincent> fenrus02: Looks like you're right. firewallcmd-ipset is the way to go.
14:37:53 <pjp> 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 <bochecha> Sparks, fedora QA might not even have the expertise to understand the security issue
14:37:59 <fenrus02> Sparks, to do that - the POC would need to be in the bz report. :/
14:38:06 <misc> Sparks: yeah, but you know as well as me this requires sometime specific testing skills that not everybody have
14:38:14 <bochecha> I mean, the maintainer might not have the security expertise either (I know I don't)
14:38:16 <misc> Sparks: and fedora-qa do also ask to the reporter to test the fix
14:38:19 <Sparks> misc: Agreed.
14:38:20 <misc> so back to square 1
14:38:44 <misc> ( or at least, taht's the content of the automated message I get when there is a upgrade )
14:38:45 <Sparks> misc: To be honest, there are several square 1 issues in Fedora now that we need to look at.
14:38:47 <bvincent> fenrus02: That file uses firewall-cmd. Thanks for the info.
14:39:00 <misc> Sparks: I agree numerotation is suboptimal :)
14:39:09 <bochecha> 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 <pjp> bochecha: let's see, I'll have a look at it in few days, if it's okay with you.
14:39:29 <Sparks> bochecha: I'm right here.
14:39:33 <fenrus02> 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 <bochecha> pjp, of course it is, thank you very much :)
14:40:23 <pjp> bochecha: cool!
14:41:37 <misc> 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 <misc> ( maybe that's already done, just trying to find a idea )
14:43:49 <Sparks> misc: Yes.  If the bug also exists in RHEL then QE I think puts the reproducer in the bug.
14:44:07 <jrusnack> Sparks: PST should put it in
14:44:22 <Sparks> jrusnack: +1
14:45:24 <jrusnack> 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 <pjp> jrusnack: Yes, we already do that for most part
14:47:08 <jrusnack> 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 <pjp> 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 <pjp> jrusnack: Such steps may not always be available or easily doable.
14:49:58 <jrusnack> 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 <pjp> jrusnack: Right,
14:51:16 <jrusnack> sounds good.
14:51:39 <pjp> 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 <jrusnack> pjp: your answer above. For fedora only bugs we do sanity only - check the patch was applied and package is sane.
14:53:07 <pjp> jrusnack: And investing the security implications is critical too.
14:53:56 <pjp> 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 <Sparks> Okay, anyone have anything else?
14:54:39 <jrusnack> pjp: imho not vulnerability
14:56:35 <pjp> Nothing in particular for me
14:57:14 <pjp> Ah - happy new year to all! :)
14:57:36 <Sparks> Okay, everyone have a good day.  I hope to be better prepared next week.
14:57:38 <d-caf> Happy new year to you all as well!
14:58:09 <Sparks> #endmeeting