8:19 a.m.
With the current plans to merge Fedora Core and Extras, we need to create a
unified security team to handle the various security flaws that emerge
within the distribution. I've been thinking about this quite a bit, and I
think the goal that needs to be kept in mind is "Keep Fedora users secure".
That goal is fairly vague on purpose. Here's how I'm thinking this can be
done.
Initially, we're going to ignore embargoed issues. Every time a security
conversation comes up, people start creating overly complex processes to
handle them. Once there is a concrete team and process, this can be
investigated. In the meantime, we'll just deal with issues once they're
public.
I think we should handle security flaws in a logical and sensible manner.
There are a lot of packages to support, and unless we prioritize the load
in a sensible manner, things will get out of hand. The first thing to
understand is that there is not enough time or manpower to fix every single
security flaw we see. I wish there was, but the truth of the matter is
that we can't fix it all. Based on that idea, I think it's important to
fix things in a prioritized manner. The way I see this is that it makes
more sense to invest extra time working on getting a Firefox critical
update out before say a minor lha temporary file flaw. I don't think the team
should ever tell someone not to work on something, but we should also not
obsess over less severe issues and packages when there are more important
things.
This makes me think the security team should view Fedora in a light where
we place extra priority based on the most used packages. How can we
determine what are the most used packages? I'd say initially we can trust
that anything shipped on the install media is used more heavily than things
that are not, but also using common sense. If there is a flaw that affects
Firefox and lynx in the same way, I'd say Firefox would deserve a first
look as it's obviously used more than lynx. We would of course want to fix
lynx, but given limited manpower, that fix may be delayed a day or two.
Other factors such as "does an exploit exist" and "how likely is it this
flaw
will be exploited" should be considered. Right now Red Hat fixes flaws by
severity alone. The Fedora Security Response Team will probably have to
classify flaws by risk, which takes severity into account, but isn't the sole
category. This definite of risk will need to be defined and no doubt will
evolve over time.
I'm also not a fan of being an exclusive group. I think letting anyone
help who wants to is the way to go. We already have a public list.
Bugzilla is available to anyone who has a login. We should welcome and
encourage outsiders to help file bugs, triage issues, and find patches.
Obviously, when we handle embargoed issues, we would have a backchannel
communication method with trusted individuals. The more transparent we
make our security process, the less it can be scrutinized. We should never
have anything to hide.
Right now the Red Hat Security Response Team handles Fedora Core issues,
while Extras is mostly ignored due to missing infrastructure to properly
handle security flaws. The tracking of the flaws that affect only Fedora Core
and Red Hat Enterprise Linux is a considerable task currently. The workload
is nearly one full time person per week simply to determine which flaws affect
what is shipped. Once Extras and Core are merged, this load is going to go up
substantially for Fedora. Handling the pace of incoming flaws will prove to
be a challenge.
I suspect there are members of the Red Hat Security Response Team who will
want to work with Fedora as the success of Fedora is in our best interest.
There will also be some overlap on tasks. If we're investigating a flaw for
Red Hat Enterprise Linux that also affects Fedora, it would be silly not to
also conduct the Fedora investigation. This brings me to the next topic:
how to make this all work.
The biggest missing puzzle piece is the lack of tools. I'm currently working
on some tools to more easily track CVE ids via a clever bugzilla interface. I
have some notes on how I plan to do this elsewhere. I can post them at a
later date if anyone is interested. The bigger tool I'm looking for is the
package release tool. It's likely that the security team will want to view
the text of all security updates and edit it if needed. I've mailed lmacken
requesting this ability, he has informed me that the functionality is there.
I'm of the impression that as long as the team has the right tools, we can
operate very efficiently and handle the current inflow of issues.
If you think I've missed something here, please let me know. I'm certain
that this transition will be a bit bumpy, but should work out in the end as
long as everyone cooperates.
Thanks.
--
JB