openSUSE:Security Incident Handling
Marcus has given a lecture on this topic on FOSDEM 2006, if you want to look at it check out the FOSDEM page, for slides, videos and audio.
Getting knowledge of the incident
We monitor various sources of information for security problems.
These include various security mailinglists, public and non public, our main contact address (security@suse.de), SUSE Bugzilla (and other vendor bugtracking systems), package version updates, and the Mitre and NVD CVE databases, and other distribution vendors advisories. Those sources overlap intentionally to ensure that we do not miss any incident.
Also problems are regularly found by our own source code audits.
Once an incident is known, it is added to the SUSE Bugzilla. (As bug usually
not visible to the public.) If you want to see samples of those bugs and
our handling, check this link.
The bugreport contains:
- description and where we got the report from
- possible patches (if any)
- possible exploits (if any)
- disclosure timelines
- any CVE / CERT VU# ids (if any)
It is then assigned to the packager . (The security team itself fixes the packages only rarely themselves, because the packagers knows his package and the surrounding community best.)
Packager
The packager takes the patches (or creates them) and applies them to packages in all old supported distributions.
He communicates with the upstream developers if necessary.
He updates the current development tree usually with the new upstream version that is released after security problems.
When he is done, he submits the packages to the checkin staging directories of the affected distributions.
We usually only backport the security fix to old versions of the package to avoid
interaction with existing parts of the system. SDB:Backports is a good article on that topic.
Buildsystem inclusion
The buildsystem team reviews the submitted packages (to avoid bugs during package work, bugs in the fixes or similar) and checks in the packages into the buildsystem.
The buildsystem then builds the package automatically.
The buildsystem team also checks in a metapatch information into the system, which then generates a set of YOU patch sources for QA. This set is a fixed set of binaries which will be delivered exactly like this to all customers.
QA
The QA team takes those generated patch sources and tests the update like the customer would see it:
- Integration test
- If the update works correctly and the program works afterwards.
- Regression test
- The testcases existing for the package are run and checked for regressions.
- Security test
- The exploit (if any) is tested before and after the update. It must be reproducable before,
- and not reproducable afterwards.
If everything has passed, QA approval of the update is given.
Release
The security team gives approval to release the update (honoring disclosure timelines).
Automated mechanisms then post update notices to mailinglists, to SUSE Customer Center, and also to the update notices index page.