10:36 a.m.
It has been awhile since I have done much here. Got lots of questions.
Wow, this mail is a lot of questions. I'll do my best to answer the ones I
have ideas for.
My concern here is how does someone new to this process come about
fairly easily and quickly knowing the status of any given vulnerability?
And how does someone know where to pitch in?
We'll have to figure this one out moving forward. I think the best way
will be to have an easy to understand and very public task list. A new
person could then easily identify orphaned things that need some attention.
How many security issues might we have that could be open at the same time?
I think the answer to this is "as many as there are". Ideally, there won't
be any open, but realistically, this number will probably be larger than
any of us will want.
In order for any kind of orderly work to get done, a diverse and
geographically-spread team would need to know what area of work needs
the most work, and how to find out what issues are ones that they can
work on, plus some way of flagging issues so someone else five minutes
later signing on the the system to do some work won't start working on
the very same thing (avoiding duplication of effort, if possible).
If we have, for example, people identifying issues -- how do we make it
so a team of three identifiers don't identify the same issue three
times? (Or is that not a problem?) Do we have a quick 'n dirty way of
telling Joe Blow, a fellow scanning the Internet for vulnerabilities,
that CVE-2007-yyyy is already in the database and needs triage (which I
assume means "prioritization" = do we worry about this flaw today,
tomorrow, or next Wednesday)? Or of telling John Q. Public that
CVE-2007-xxxx has been triaged and now needs patches to be found and
published somewhere for Jim-Billy Bobb to go into the package CVS and
build a new package? How do we know when who does what and who has
access to which information where to get work done?
This is where some tools can come in handy. I'm still working on getting
things in order, but here is the basics of what I'm thinking.
There is a queue in bugzilla called "Security Response". The plan is to
have one bug for each CVE id we have any sort of interest in. This would
then be a place we can add comments regarding an issue and track what's
affected.
We will then have product bugs for everything that needs one (Fedora, RHEL,
anything else that needs a bug). The product bugs will then be child bugs
of our CVE bug. This means that in order to determine what a given CVE id
affects, you'll have to look at the child bugs for each CVE bug. This
would be silly for a person to do, which is why we'll have a pretty web
page with it listed for us. I envision each CVE bug having an owner. The
tasks that aren't being worked on will be orphaned, and obviously up for
grabs. Here is a bad ASCII picture for those of you confused by my
gibberish.
CVE-XXXX-0001 <-- parent bug describing a flaw
|
+ Bug 12345 <-- filed against xpdf in Fedora
|
+ Bug 12346 <-- filed against cups in Fedora
|
+ Bug 12348 <-- filed against xpdf in RHEL
So obviously we'd have a tool that would make this very obvious as trolling
around bugzilla wouldn't be. The biggest advantage to this is that since
the various package developers use bugzilla for tracking their tasks, our
issue database is also the same place the developers look for what needs to
be fixed.
The only way this can work is with some tools. I'm currently working on
some python libraries to parse all this nicely. Once I have a basic
working prototype, I'll put the code in the fedora CVS then other can lend
a hand.
And how does the QA process fit in with all of this? Er, do we have
some kind of package QA process for security vulnerabilities? Would
community members be welcome to pitch in on this if there is a QA
process in place?
Right now we let the Fedora developers handle the package updates, which
also involve some amount of QA. I think we'll leave the QA bits up to the
developer and any QA groups that form. I think we should keep a somewhat
narrow focus on security updates. It's easy to get sidetracked and this is
a path that would likely have no end for this group.
A good start might be a breakdown for those of us here who don't know --
who *now* does what for Core packages and for extras packages? What
does a security issue look like walked through the entire process, from
identifying the vulnerability to the release of a fixed package? What
does the process *now* look like and how do Red Hat people envision
opening up the process to let others in? How is information going to be
shared outside of the Security Response Team so it will be able to be
efficiently known about by your community contributors (excluding
embargoed issues, of course, for now)? And are embargoed issues for
former core packages now going to be ignored until the embargo is
lifted, or are they going to be able to be worked on by trusted
individuals inside Red Hat while embargoed, just as they are now?
I'd start by taking a look at this message:
https://www.redhat.com/archives/fedora-security-list/2007-January/msg0003...
It's a pretty good description of our current process. I'm not really
interested in letting people into the current Red Hat process. I'm
interested in letting Red Hat into the Fedora process. Since we don't
really have a Fedora process, we get to make it up :)
If today I wanted to start being a security bug watcher, where do I
report them? Bugzilla? Or is there a person or a group of people that
already does this as a paid job inside of Red Hat?
I don't think I understand this question. Right now all security bugs
should be in bugzilla yes. There are people inside Red Hat, the Red Hat
Security Response Team that look for and deal with security bugs, but the
focus of this team is on Fedora Core and Red Hat Enterprise Linux. Once
Fedora 7 is out, I foresee some members of the team joining the Fedora
Security Response Team. There will be some task overlap, so I think it
just makes sense.
Does the Fedora Security Team maintain a database (or "flat file")
stored out in a Fedora CVS server somewhere that indicates status of any
given CVE issue? If it is there, is the "how to use it" documented
anywhere? Is manipulating this flat file the best way to get security
bugs "into the system" for review?
See my above comments about tools.
If there are things that people know tacitly how to do, I would be more
than happy to help document current processes.
We should probably start some wiki pages to capture all this information.
I honestly don't even remember what's all on the wiki about security
things. I wouldn't complain if someone could take the lead on handling the
documentation of questions and answers along with tool and process plans.
I don't expect to have time to look into this myself until I have my
prototype python library done.
Is there any estimate of an ideal level of manpower doing things? And
what levels of expertise are needed for each of the security tasks,
especially when dealing with former Core packages by community members?
I think the ideal level of manpower is as many people as are willing to
help :)
There isn't really a minimal competency level for this stuff. Obviously
some things require a certain level of expertise, but as those issues
arise, we'll have people around to handle those. I'm a believer in the
idea that everyone is at the bottom of the ladder at some point and time,
so if you're willing learn, we should be willing to teach.
--
JB