14:00:23 <Sparks> #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings
14:00:23 <zodbot> Meeting started Thu Nov 20 14:00:23 2014 UTC.  The chair is Sparks. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:26 <Sparks> #meetingname Fedora Security Team
14:00:26 <zodbot> The meeting name has been set to 'fedora_security_team'
14:00:29 <Sparks> #topic Roll Call
14:00:31 * Sparks 
14:01:04 <D-Caf> Here
14:01:12 * jrusnack here
14:01:41 <mhayden> howdy
14:02:34 * Sparks welcomes everyone
14:02:41 <bvincent> here
14:03:14 <pjp> H,
14:03:15 <pjp> Hi
14:04:48 <Sparks> Okay, lets get started.
14:04:55 <Sparks> #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better"
14:05:08 <Sparks> #topic Follow up on last week's action items
14:05:21 <Sparks> #action Sparks to follow up with fenrus02 (via the security list) on checksec and checksec2.
14:05:27 <Sparks> One day I'll do this.  Maybe today.
14:05:34 <Sparks> #topic Next week's meeting
14:05:39 <Sparks> #info US Holiday next Thursday
14:06:05 <Sparks> So, I'm thinking that we should just cancel next week's meeting.  I'll be on the road and likely not in front of a computer this time next week.
14:06:35 <jrusnack> sure, np with me
14:07:07 <pjp> Does everyone have holiday next Thursday?
14:07:07 <D-Caf> Understood, I'll be busy with family
14:07:16 * mhayden is out next thursday
14:07:55 <Sparks> pjp: It's US Thanksgiving.
14:07:58 <jrusnack> pjp: Sparks said its US holiday, so no
14:08:10 <pjp> Sparks: jrusnack Right,
14:08:59 <Sparks> #agreed Cancel next week's meeting.
14:09:02 <pjp> I was wondering if we should have the meeting if there are folks who don't have holiday. But it seems majority of the participants have holidays.
14:09:22 <Sparks> I mean, you guys can meet if you like.  I have no problem with that.
14:10:18 <pjp> Sparks: yes, that's what, just that someone else would have to conduct it. Which would have been manageable, if there were participants.
14:10:37 <Sparks> pjp: You want to run in so that folks can come if they are available?
14:10:43 <Sparks> #undo
14:10:43 <zodbot> Removing item from minutes: AGREED by Sparks at 14:08:59 : Cancel next week's meeting.
14:11:13 <Sparks> FWIW, I have no problem if other people want to run the meetings.  :)
14:11:42 <pjp> Sparks: Sure, okay
14:12:09 <Sparks> #agreed pjp will run next week's meeting
14:12:10 <Sparks> :)
14:12:34 <Sparks> Okay, that's simple enough.
14:12:39 <Sparks> Now lets do the numbers.
14:12:43 <Sparks> #topic Outstanding BZ Tickets
14:12:49 <Sparks> #info Wednesday's numbers: Critical 1, Important 47, Moderate 391, Low 161, Total 600, Trend +33
14:12:55 <Sparks> #info Current tickets owned: 196 (~33%)
14:13:00 <Sparks> #info Tickets closed: 168
14:13:10 <Sparks> So, just a word regarding the trends.
14:13:24 <Sparks> There has been an influx of cases the past two weeks.
14:13:42 <Sparks> Most of these have been in the moderate category.
14:13:51 <pjp> Sparks: these 168 closed are counted in the total 600?
14:13:59 <Sparks> The team continues to pick up the cases, just not as fast as they are coming in.
14:14:05 <Sparks> pjp: No
14:14:15 <Sparks> pjp: That's a cumulative number
14:14:22 <pjp> Sparks: Okay, 600 open tickets?
14:14:28 <Sparks> Yes
14:14:51 <D-Caf> I have to apologize, I've been in active last few weeks due to work load and family, holding to pick it up some this weekend.
14:15:05 * Sparks notes those aren't Wednesday's numbers but rather they are Thursday's numbers.
14:15:32 <Sparks> D-Caf: No worries.  I haven't been able to grab as many as I would have liked.
14:15:59 <pjp> Sparks: I'm writing a tool to automate non-responsive maintainer policy, so was looking at total Fedora trackers with keywords: Security, SecurityTracking, it showed up to be about 300.
14:16:28 <Sparks> pjp: Yeah, that's not surprising.
14:16:38 <Sparks> Sad, but not surprising.
14:17:11 <pjp> Sparks: no, so the total 600 is surprising,
14:17:25 <jrusnack> Sparks: could we push for faster "irresponsible maintainer " policy ?
14:17:47 <jrusnack> one thing is maintainer who doesn`t care to update, another is leaving package vulnerable
14:17:54 <jrusnack> we should make it super quick
14:18:18 <Sparks> jrusnack: For critical and Important, I'd agree with that.  Moderate and lows... maybe not.
14:18:41 <jrusnack> Sparks: why ?
14:19:16 <pjp> jrusnack: Sparks so the tool currently would automatically ping bugs that are unattended for > 90 days, that no activity on a bug for 3 months
14:19:40 * jsmith joins late, due to a work meeting
14:20:04 <pjp> After 2 such ping notifications, in the 3rd week one of us would have to take a look or invite folks to  pick those
14:20:06 <Sparks> jrusnack: Moderate and lows are... well, very much less important.  I suspect upstream hasn't been looking at them very closely.  If we get to the point of only having moderate and lows then yeah, lets grab a shovel and dig in.  :)
14:20:24 <Sparks> jsmith: Welcome
14:20:40 <pjp> jsmith: Hi,
14:20:50 <jrusnack> Sparks: I mean, that policy applies when problem is on packagers side, not upstream`s
14:21:02 <Sparks> jrusnack: I'm not saying that we shouldn't be pinging on these tickets.
14:21:37 <Sparks> jrusnack: Yes, if there is an update available from upstream we should definitely be harping on the maintainer to do the fix.
14:22:04 <pjp> jrusnack: true, I recently pushed updates to one of the python package, for which maintainer did not bother to push an update.
14:22:26 * pjp had to request co-maintainership of the package,
14:22:49 <Sparks> pjp: jsmith can probably do that for you as a super packager
14:23:07 <pjp> Sparks: Yes, today I too became one :)
14:23:11 <jrusnack> pjp: that is sad, and probably does not scale - would we co-maintain everything after some time ?
14:23:38 <pjp> jrusnack: nope, that is where super packager play a role,
14:24:05 <Sparks> pjp: Woot!
14:24:28 <pjp> Maybe I can add all super packager's email in the list who would be requested to look at pending security bugs
14:27:08 <Sparks> pjp: I really think releng needs to look at the packages we're having to apply bandages to.  We can't keep doing the packager's work for them.
14:27:37 <pjp> Sparks true, in the long run I hope to hand over the tool to releng
14:27:40 <jrusnack> Sparks: +1
14:28:18 <Sparks> pjp: Maybe give them a list of packages we're having to do the work on.
14:29:17 <pjp> Sparks: yes, we'll regularly publish a list of pending security bugs that are > 90 days old.
14:30:02 <jrusnack> I like that idea - publish cumulative days of exposure for each packager
14:30:54 * Sparks counts 58 Critical and Important bugs that are older than 90 days
14:30:55 <pjp> We'll publish a report about the ones which were fixed too.
14:31:29 <pjp> Boy, 58 critical!!
14:31:54 <Sparks> pjp: Well, there's only one critical.
14:32:28 <pjp> Oh okay, together with important, still...boy! ;)
14:32:32 <Sparks> Yes
14:35:33 <Sparks> Okay, I'm going to start a couple non-responsive maintainer issues today.  I'll try to get some of these things in process.
14:36:26 <Sparks> Anything else on the discussion of the bugs?
14:36:34 <pjp> Sparks: to confirm, you are looking at the same bugs list that is linked from the security team wiki page, right?
14:36:53 <Sparks> pjp: Yes
14:37:10 <pjp> Sparks: Okay.
14:37:23 <Sparks> pjp: I just modified the search for just bugs older than 90 days
14:37:36 <pjp> Sparks: right,
14:37:42 <Sparks> #topic Open floor discussion/questions/comments
14:37:50 <Sparks> Okay, does anyone have anything?
14:39:08 <jtaylor90> all set here
14:39:26 <Sparks> Okay... well, if there is nothing else...
14:39:36 <pjp> Does it make sense for us to look at default Fedora configurations, like not allowing remote root login via ssh?
14:39:55 <pjp> currently sshd allows it,
14:40:35 <bvincent> pjp: Really?
14:40:42 <pjp> bvincent: yes,
14:40:56 <Sparks> Yeah, this has bothered me for a while but I understand the rationale.
14:40:57 <bvincent> pjp: I've been using lsh a little too long.
14:41:05 <Southern_Gentlem> pjp you are looking at something 10% of the install might use
14:41:23 <pjp> Southern_Gentlem: 10% of install?
14:41:29 <Southern_Gentlem> installs
14:41:44 <pjp> Southern_Gentlem: all Fedora installs would have it, no?
14:42:00 <Southern_Gentlem> most installs are done with lives nowadays so ssh is blocked by default on those installs
14:42:03 <Sparks> You know, I'd like to have a hardening script that went through and helped you setup proper authentication and fixed your fw and all that when you do the install.
14:42:08 <pjp> bvincent: you need to set PermitRootLogin=no in sshd_config
14:42:28 <bvincent> pjp: I know. It's just I'm not use to installing a daemon, and not checking the settings.
14:42:29 <pjp> Southern_Gentlem: I see
14:42:34 <bvincent> Well in all fairness, the installer reminds you to set a strong root password.
14:42:40 <jrusnack> Sparks: that should be default imo
14:42:57 <bvincent> The ability to log in as root only becomes a problem when your password is weak.
14:43:06 <Sparks> jrusnack: What if you're doing a remote install and don't have access any other way?
14:43:09 <bvincent> A weak user password + sudo is no better.
14:43:28 <Southern_Gentlem> i really hope there is a wiki page telling do this to harden your install
14:43:30 <bvincent> Thus, wouldn't logic dictate the use of keys only?
14:44:10 <Sparks> keys++
14:44:22 <jrusnack> Sparks: I meant hardened config should be default, not opt in. You can configure during install time otherwise
14:44:33 <D-Caf> I've done many an install remote that required root access to begin with
14:44:38 <Sparks> jrusnack: Well, you might be able to.
14:44:38 <pjp> Southern_Gentlem: that's the idea, to come up with such configurations which eventually could become default in the long run
14:44:47 <Southern_Gentlem> bvincent,  most people are not going to use keys in their local network (homes) yes i can see that in a production environment
14:45:19 <pjp> +1
14:45:20 <Sparks> jrusnack: Bring it up on devel@ and see what people say.  I'd be all for it but I think there are some use cases that is causing us to not fix it.
14:45:25 <D-Caf> It is disabled soon after the initial install, once a user account is. Created.
14:45:27 <bvincent> Southern_Gentlem: I'm not saying that this should be default. I'm just saying that a weak user password plus sudo access is worse then leaving root access enabled.
14:46:08 <jrusnack> Sparks: I think pjp is expressing the same thing more clearly than I am :)
14:46:11 <D-Caf> But I don't think for server installs we can assume a user account account is always setup.
14:46:27 <bvincent> D-Caf: True. I've seen environments where the only local account is root.
14:47:23 <pjp> bvincent: same here, lot of folks use computer as root users,
14:47:51 <Sparks> that's just crazy talk
14:47:57 * pjp thinks not allowing remote root would encourage non-root user usage
14:47:58 <bvincent> Perhaps, one should look at the OpenSSH hardening portion of the NSA guide for RHEL 5.
14:47:59 <Sparks> that doesn't really actually happen... right?
14:48:03 <bvincent> #link https://www.nsa.gov/ia/_files/os/redhat/nsa_rhel_5_guide_v4.2.pdf
14:48:09 <D-Caf> bvincent: yes, often in my work that a how it goes
14:48:25 <pjp> Sparks: it does
14:48:42 * Sparks curls up in a ball and lays on the floor.
14:48:48 <pjp> Heh..:)
14:49:09 <jrusnack> bvincent: that is somewhat old. I believe openscap rules are based on it, but updated
14:49:36 <bvincent> jrusnack: Do you have a link to the openscap rules?
14:49:46 <D-Caf> root is usually saved for emergency use only, but enables with keys or insane passwords.
14:49:46 <jrusnack> google does, a sec
14:50:23 <bvincent> jrusnack: The version of OpenSSH shipped with RHEL has a lot of older ciphers, so an updated resource would be appreciated.
14:51:51 <jrusnack> bvincent: http://scap-securityguide.rhcloud.com/RHEL6/output/table-rhel6-nistrefs-common.html
14:51:59 <jrusnack> seems like general description of rules
14:52:15 <jrusnack> I`m pretty sure they are packaged in RPM, so you can install and view them locally
14:52:30 <jrusnack> I`m also pretty sure there`s a GUI you can use
14:53:09 <bvincent> jrusnack: I hate to say this, but there must be a reason that RHEL doesn't install out of the box like this.
14:54:07 <jrusnack> bvincent: there was work on anaconda installer to enable scap scanning prior to system being installed
14:54:19 <bvincent> jrusnack: Some of these settings can be a little extreme for a home system, but RHEL is for enterprise usage.
14:54:22 <jrusnack> not sure if its done yet
14:54:23 <Sparks> jrusnack: Yeah, I was excited by that feature
14:54:31 <Sparks> jrusnack: But it was rejected for Fedora
14:54:45 <jrusnack> Sparks: on what merit ?
14:55:01 <bvincent> I use to set all these things manually... The tool is nice.
14:55:18 <Sparks> jrusnack: Well, the discussion went sideways with folks not actually understanding what was being asked.  Once the train was off the tracks there was no getting it back upright.
14:55:45 <jrusnack> Sparks: seems like another long-term action item for us
14:56:30 <pjp> We need to audit default configurations of other services/programs too.
14:57:49 <Sparks> Okay, we are running out of time.
14:57:57 <Sparks> jrusnack: Care to move this discussion to the list?
14:58:27 <jrusnack> Sparks: I`ll let pjp do that if he agrees, I was bad at explaining this anyway
14:58:41 <pjp> jrusnack: Sparks okay
14:59:00 <Sparks> Okay,anything else?
14:59:13 <Sparks> Going once
14:59:16 <Sparks> Goine twice
14:59:17 <Sparks> ...
14:59:18 <Sparks> ..
14:59:19 <Sparks> .
14:59:24 <Sparks> #endmeeting