openSUSE:Security Incident Handling

Het SUSE Beveiligingsteam behandelt de incidenten over beveiliging in de op SUSE Linux gebaseerde distributies.

Marcus heeft een lezing over dit onderwerp gegeven op FOSDEM2006, als u het wilt bekijken ga dan naar de pagina FOSDEM, voor dia's, video's en audio.

Kennis krijgen van het incident

Dit artikel is nog maar gedeeltelijk vertaald. Als u mee wilt helpen met vertalen lees dan Wiki vertalen naar het Nederlands.

We monitor various sources of information for security problems. These include mailinglists, both public and non public, our main contact address (security@suse.de), bugzilla, 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 reguly found by our own source code audits.

Once an incident is known, it is added to the Novell 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).

The security team also writes the security advisory for issues with higher impact.

For the other issues a summary reports is released approximately weekly.