14:00:42 <mhayden> #startmeeting Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings
14:00:42 <zodbot> Meeting started Thu Jul  2 14:00:42 2015 UTC.  The chair is mhayden. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:51 <mhayden> #meetingname Fedora Security Team
14:00:51 <zodbot> The meeting name has been set to 'fedora_security_team'
14:01:02 <mhayden> #topic Roll Call
14:01:19 * d-caf 
14:04:30 * d-caf wondering if anyone else is here for roll call...
14:04:35 <mhayden> hah
14:04:56 <mhayden> everyone hides when i run the meeting :)
14:05:08 <mhayden> #info Participants are reminded to make liberal use of #info #link #help in order to make the minutes "more better"
14:05:09 <scorneli> i joined #fedora-meeting! (with exclamation mark) and didnt notice. embarrassing
14:05:09 <d-caf> Do they know something i don't ;-)
14:05:19 <mhayden> #topic 90-Day Challenge
14:05:33 <mhayden> #link https://ethercalc.org/90-day-challenge
14:05:39 <mhayden> #info 90-Day Challenge has a goal to close all 2014 and prior Important CVEs in Fedora
14:05:52 <mhayden> i don't have the latest stats (sorry, unprepared!)
14:06:15 <mhayden> but the python-pip BZ (1160137) moved to On_QA
14:06:21 <scorneli> :)
14:06:23 <d-caf> I'm sure we didn't hit 100%, but I had a little movement in the end to close a few.
14:06:27 <revskills> hi there
14:06:32 <mhayden> any other notable changes in the list that y'all have noticed?
14:07:03 <revskills> I need to update the fedora user/fst page with my personal email after leaving RH, so I wonder nobody wrote me and lost some answers from my tickets
14:07:36 <mhayden> revskills: ah, didn't know you left!
14:07:48 <striker> revskills: sf tkts or another system?
14:08:11 <revskills> bugzilla tickets for fst_owner I mean
14:08:16 <mhayden> if we want to talk about any specific tickets, i'll go ahead and...
14:08:18 <mhayden> #topic Outstanding BZ Tickets
14:09:51 <mhayden> i'll jump in here... the LXC templates effort is stalled a bit
14:09:51 <d-caf> So seems the people who were doing the nagios stuff have no interest in maintaing it anymore (and those tickets didn't close before the end of 90 day challenge)
14:10:04 <d-caf> LXC templates?
14:10:20 <mhayden> BZ 1132004 <- LXC template security
14:10:25 <d-caf> ah
14:10:34 <mhayden> long story short, upstream would like to see a unified method of handling user credentials
14:10:50 * mhayden digs for thread
14:11:18 <mhayden> #link https://lists.linuxcontainers.org/pipermail/lxc-devel/2015-June/011898.html
14:11:53 <mhayden> upstream prefers to 1) set no password for root 2) disable empty password logins 3) set password for user account randomly unless user specifies otherwise
14:12:04 <mhayden> and do all that via a shared shell script
14:12:18 <mhayden> that in itself isn't a big challenge but getting the distros to agree on how that should be implemented will be interesting
14:12:50 * d-caf reading this stuff now...
14:12:55 <mhayden> i'd rather see a framework (like ansible) used to configure the template, honestly
14:13:05 <mhayden> or take a baked image (perhaps one made for docker) be used
14:13:24 <mhayden> currently, Fedora/CentOS templates use a randomized password set after a yum --installroot
14:13:33 <mhayden> regular ubuntu uses debootstrap
14:13:43 <mhayden> ubuntu-cloud uses a tarred image that is normally used for docker images
14:13:58 <mhayden> and the others, like oracle and arch and gentoo, are all over the map
14:14:20 <mhayden> #link https://fedoraproject.org/wiki/LXC_Template_Security_Improvements
14:14:24 <mhayden> ^^ full summary
14:14:31 <d-caf> yeah, that does souund like it's going to be a mess to coordinate...
14:14:35 <mhayden> exactly
14:14:53 <mhayden> if i had the freedom (which i may already have) to implement something shared, it would be fairly easy to transition most images
14:14:55 <d-caf> Sorry, I haven't used this much (we do a lot of custom stuff inhouse at work)
14:14:59 <mhayden> same here
14:15:12 <mhayden> LXC templates may just need to be marked as "hey, try to use something else"
14:15:13 <mhayden> :)
14:15:52 <mhayden> luckily, Fedora/CentOS/Ubuntu-cloud all are configured pretty well from the get-go
14:15:53 <d-caf> Well, just to provide a good basic default standard that everyone gets, but are welcome to mod to the liking of their distro would help
14:16:01 <mhayden> true
14:16:06 <mhayden> it's still on my radar, but stalled
14:16:29 <mhayden> are most folks seeing unresponsive maintainers as the main barrier to getting these BZ's closed?
14:16:40 <mhayden> that's been my biggest barrier so far
14:17:07 <d-caf> The biggest barrier is maintainers that don't respond at all, or are just no longer interested in the package
14:17:44 <d-caf> in the case of the nagios stuff, it appears that many of them have moved onto other monitoring tools (and assume everyone else as as well, cough cough wrong..)
14:17:57 <mhayden> bleh
14:18:10 <mhayden> i've tried offering to co-maintain the packages but even that isn't well received
14:18:35 <mhayden> i'm not trying to call anyone out in particular, but i am having issues with unresponsive maintainers with @redhat.com addresses -- which i find unusual
14:19:01 <d-caf> I don't have that much free time (though i have interest).  But most maintaners I have actuallly made contact with are usually up to giving up the package if I find a new maintaner for them.
14:19:12 <d-caf> jsut again, lot of effort on my part to track down that community
14:19:31 <mhayden> makes sense
14:19:39 <d-caf> mhayden: yes, I have had a few redhat non-response people
14:19:47 <mhayden> i saw an email somewhere about some potential automated unresponsive maintainer processes
14:19:54 <d-caf> Though recently at least one of them has stepped up some
14:19:55 * mhayden digs for it
14:20:51 <d-caf> yes, I think jrusnack: may have been working on that?
14:21:00 * d-caf I could be very wrong on the person
14:21:49 <jrusnack> eh, probably not me
14:22:12 <d-caf> jskarvad: yeah, probably not :-)
14:22:17 <d-caf> ah
14:22:22 <jrusnack> np :)
14:22:30 <d-caf> Apparently I'm just going to tag random people...
14:22:31 <mhayden> it seems like there could be something where a flag could be placed on a package saying "unmaintained" and then it would open the door for a new maintainer to be administratively added (should one step up for it)
14:22:51 <mhayden> #topic Open floor discussion/questions/comments
14:22:58 <mhayden> since we're already in open floor :)
14:23:16 <d-caf> Fabio0live was going to look into it
14:23:22 <d-caf> http://meetbot.fedoraproject.org/fedora-meeting/2015-06-11/fedora_security_team.2015-06-11-14.00.log.html
14:23:39 <scorneli> if you have problems with @redhat.com folks, send a list and the bugs they are supposed to fix to scorneli@redhat.com and I'll try to hunt them down
14:24:03 <mhayden> scorneli: will do -- thanks for that
14:24:13 <d-caf> scorneli: Ok, thanks
14:24:28 <mhayden> #info For non-responsive maintainers at redhat.com email addresses, reach out to scorneli
14:24:51 <mhayden> #action Check in with Fabio0live about the non-responsive maintainer process automation
14:25:12 <mhayden> #info Biggest barrier to closing security bugs is non-responsive maintainers
14:25:21 * mhayden uses those #'s liberally :P
14:26:19 <mhayden> this may be a dumb question, but is provenpackager level req'd for adjusting someone else's package?
14:26:39 <scorneli> mhayden: yes, afaik
14:26:39 <d-caf> mhayden: adjusting?
14:26:46 <revskills> yep
14:26:53 <mhayden> okay thanks
14:27:02 <mhayden> does anyone in this group have that level of access?
14:27:20 <scorneli> Sparks probably
14:27:21 * mhayden wonders if we could use that to fix very high priority bugs on certain packages
14:27:23 <d-caf> There are two or three
14:27:37 <mhayden> okay, good to know
14:27:51 <d-caf> pjp also I believe
14:28:04 <mhayden> sweet
14:28:16 <mhayden> i'm still at the bottom packager level that comes with the dunce hat
14:28:29 <d-caf> mhayden: fear not, I'm well below that
14:28:45 <mhayden> we all start somewhere!
14:29:07 * mhayden remembers pushing a broken package to EPEL7 at one point :|
14:29:36 <mhayden> #idea Possibly use provenpackers in FST to tackle high priority security bugs on non-responsive maintainer packages -- needs more discussion
14:29:53 <mhayden> anything else to discuss today?
14:29:55 <d-caf> mhayden: we have done that for critical before
14:30:20 <mhayden> #info Provenpackager access has been used in the past for critical bugs (thanks d-caf)
14:31:34 <mhayden> something else security related: Dan Walsh's talk on container security at the summit was quite good
14:31:34 <d-caf> jsmith: was the one who did it for rubgem-activesupport
14:32:06 <d-caf> I still need to see that
14:32:14 <d-caf> the Dan talk
14:32:49 <mhayden> #link https://www.youtube.com/watch?v=a9lE9Urr6AQ
14:32:54 <mhayden> ^^ dwalsh's talk
14:33:11 <d-caf> mhayden: thanks, will watch it at lunch
14:33:21 <mhayden> #link Super Privileged Containers- > https://www.youtube.com/watch?v=dM2Fc53Dtd4
14:33:24 <mhayden> that was the other one
14:33:29 <mhayden> kinda in the opposite vein
14:33:42 <mhayden> he takes time to elbow me in both sessions :P
14:34:06 <mhayden> i'm eager to see what can be done with seccomp in containers
14:34:13 <scorneli> i've nothing more to add to the meeting
14:34:19 <d-caf> I do a lot of SELinux on processes/apps/vms, but haven't applied it much to containers yet
14:34:40 <mhayden> well if you have SELinux enforcing on the host, then you're good to go with SELinux for containers
14:34:42 <d-caf> I don't have much more for the meeting either
14:34:53 <mhayden> the kernel tells the container that selinux is disabled, but it's not really disabled
14:34:57 <mhayden> okay i'm done as well
14:35:04 <d-caf> setenforce isn't enough for me :-)
14:35:05 <mhayden> anyone else? speak now or forever hold your peace!
14:35:16 <mhayden> d-caf: i like the way you think, sir
14:35:21 <mhayden> 3
14:35:24 <mhayden> 2
14:35:28 <mhayden> 1
14:35:32 <mhayden> 0.5
14:35:34 <mhayden> #endmeeting