Available Languages: | Deutsch | English | Français | 日本語 (Nihongo) | Português | 中文 (简) (Simplified Chinese) |

Allgemeine Sicherheitspolitik für akzeptierte Pakete

Dieses Dokument beschreibt die Behandlung von Sicherheitslücken bei Paketen, die für Fink akzeptiert wurden. Obwohl die Hauptverantwortung für jedes akzeptierte Paket beim jeweiligen Betreuer liegt, erkennt Fink die Notwendigkeit an, eine einheitliche Politik zu erstellen, wie auf Sicherheitslücken bei Software reagiert wird, die als Fink-Paket angeboten wird. Jeder Betreuer von Fink-Paketen ist verpflichtet, sich an diese Politik zu halten.

Contents

1 Verantwortung

1.1 Wer ist verantwortlich?

Jedes Fink-Paket hat einen Betreuer. Man findet ihn, indem man das Kommando fink info packagename eingibt. Man erhält eine Liste, die in etwa so aussieht: Maintainer: Fink Core Group <fink-core@lists.sourceforge.net>. Dieser Betreuer hat die volle Verantwortung für seine Pakete.

1.2 Wen soll ich kontaktieren?

Treten bei der Software eines Fink-Pakets Sicherheitslücken auf, sollten sie den Paket-Betreuer und das Fink Core Team informieren. Die Email-Adresse des Betreuers steht im Paket-Info, die des Fink Core Team ist fink-core@lists.sourceforge.net

1.3 Im-Voraus-Benachrichtigung

Bei schwerwiegenden Sicherheitslücken kann es erforderlich sein, den Paket-Betreuer im voraus zu benachrichtigen. Da es vorkommen kann, dass der Betreuer nicht rechtzeitig erreicht wird, sollte das Fink Security Team ebenfalls im voraus benachrichtigt werden. Die Email-Adressen der Teammitglieder sind weiter unten aufgeführt. Bitte beachten sie, dass fink-core@lists.sourceforge.net eine öffentlich archivierte Mailing-Liste ist und private Im-Voraus-Benachrichtigungen deshalb nie an diese Adresse geschickt werden dürfen.

1.4 Antwort

Eingeschickte Berichte über Sicherheitslücken werden vom Fink Core Team beantwortet. Von jedem Betreuer wird von Fink verlangt, jede einzelne Sicherheitslücke zu bestätigen. In dem unwahrscheinlichen Fall, dass der Betreuer nicht erreichbar ist und der Betreuer den Bericht nicht innnerhalb von 24 Stunden bestätigt, soll eine Notiz an das Fink Core Team gehen, in dem das Team informiert wird, dass der Betreuer nicht antwortet.

In dem Fall, dass sie versuchten, den Paket-Betreuer zu erreichen, aber das Mail-System einen Fehler bei der Zustellung meldet, sollten sie sofort das Fink Core Team darüber informieren, dass der Paket-Betreuer nicht erreicht werden konnte und dass das Paket unabhängig vom Betreuer aktualisiert werden muss.

2 Antwortzeiten und sofortige Aktionen

Antwortzeiten und Aktionen hängen in großem Maße von der Schwere der Sicherheitslücke ab, das die Software in einem Fink-Paket verursacht. Das Fink Core Team wird sofort aktiv werden, wenn es zum Schluss kommt, dass die Gemeinschaft der Fink-Nutzer geschützt werden muss.

2.1 Antwortzeiten

Für jedes Paket sollte versucht werden, die folgenden Antwortzeiten einzuhalten. Bei entsprechenden Sicherheitslücken behält sich das Fink Core Team das Recht vor, sofort aktiv zu werden. In solchen Fällen wird dann ein Mitglied des Core Teams den Paket-Betreuer informieren. Beachten sie aber bitte, dass Fink ein Projekt ist, das von Freiwilligen getragen wird und deshalb letztlich keine Garantien gegeben werden können.

SicherheitslückenAntwortzeit
remote Root-Exploit

minimal: sofort; maximal: 12 Stunden.

lokaler Root-Exploit

minimal: 12 Stunden; maximal: 36 Stunden.

remote DOS

minimal: 6 Stunden; maximal: 12 Stunden.

lokaler DOS

minimal: 24 Stunden; maximal: 72 Stunden.

remote Datenverlust

minimal: 12 Stunden; maximal: 24 Stunden.

lokaler Datenverlust

minimal: 24 Stunden; maximal: 72 Stunden.

2.2 Erzwungene Aktualisierungen

Ein Mitglied des Fink Core Team kann entscheiden, dass ein Paket aktualisiert werden muss, ohne dass eine Reaktion des Paket-Betreuers abgewartet wird. Dies wird erzwungenge Aktualisierung genannt. Wird die maximale Antwortzeit für eine bestimmte Sicherheitslücke in einem Fink-Paket überschritten, führt dies ebenfalls zu einer erzwungengen Aktualisierung.

3 Quellen für Sicherheitslücken

3.1 Akzeptierte Quellen für Sicherheitslücken

Wer eine Sicherheitslücke für ein Fink-Paket meldet, muss auch sicher stellen, dass die Sicherheitslücke auch auf Mac OS X existiert. Es ist die Pflicht des Melders, von einer der folgenden Quellen eine Bestätigung der Sicherheitslücke einzuholen.

  1. AIXAPAR: AIX APAR (Authorised Problem Analysis Report)
  2. APPLE: Apple Security Update
  3. ATSTAKE: @stake security advisory
  4. AUSCERT: AUSCERT advisory
  5. BID: Eintrag auf der Security Focus Bugtraq ID Datenbank
  6. BINDVIEW: BindView security advisory
  7. BUGTRAQ: Posting in der Bugtraq Mailing-Liste
  8. CALDERA: Caldera security advisory
  9. CERT: CERT/CC Advisories
  10. CERT-VN: CERT/CC vulnerability note
  11. CIAC: DOE CIAC (Computer Incident Advisory Center) bulletins
  12. CONECTIVA: Conectiva Linux advisory
  13. CONFIRM: URL zum Hersteller, der die Sicherheitslücke bestätigt
  14. DEBIAN: Debian Linux Security Information
  15. EEYE: eEye security advisory
  16. EL8: EL8 advisory
  17. ENGARDE: En Garde Linux advisory
  18. FEDORA: Fedora Project security advisory
  19. FULLDISC: Full-Disclosure Mailing-Liste
  20. FreeBSD: FreeBSD security advisory
  21. GENTOO: Gentoo Linux security advisory
  22. HERT: HERT security advisory
  23. HP: HP security advisories
  24. IBM: IBM ERS/BRS advisories
  25. IMMUNIX: Immunix Linux advisory
  26. INFOWAR: INFOWAR security advisory
  27. ISS: ISS Security Advisory
  28. KSRT: KSR[T] Security Advisory
  29. L0PHT: L0pht Security Advisory
  30. MANDRAKE: Linux-Mandrake advisory
  31. MISC: generelle Referenz zu einer URL
  32. MLIST: generelle Referenz für verschiedene Mailing-Listen
  33. NAI: NAI Labs security advisory
  34. NETECT: Netect security advisory
  35. NetBSD: NetBSD Security Advisory
  36. OPENBSD: OpenBSD Security Advisory
  37. REDHAT: Security advisories
  38. RSI: Repent Security, Inc. security advisory
  39. SEKURE: Sekure security advisory
  40. SF-INCIDENTS: Posting in der Security Focus Incidents Mailing-Liste
  41. SGI: SGI Security Advisory
  42. SLACKWARE: Slackware security advisory
  43. SNI: Secure Networks, Inc. security advisory
  44. SUN: Sun security bulletin
  45. SUNALERT: Sun security alert
  46. SUNBUG: Sun bug ID
  47. SUSE: SuSE Linux: Security Announcements
  48. TRUSTIX: Trustix Security Advisory
  49. TURBO: TurboLinux advisory
  50. VULN-DEV: Posting in der VULN-DEV Mailing-Liste
  51. VULNWATCH: VulnWatch Mailing-Liste
  52. XF: X-Force Vulnerability Databank
  53. CVE: CVE Candidates

Die obigen Schlüsselworte stimmen mit der Empfehlung des CVE überein, wie man hier nachlesen kann.

4 Sicherheitsaktualisierungen

4.1 Sicherheitsrelevante Aktualisierungen durchführen

Sicherheitsrelevante Aktualisierungen sollen nur angewandt werden, wenn sie vom ursprünglichen Autor, der die Software erstellt hat, bestätigt werden. Vor einer Aktualisierung müssen folgende Bedingungen erfüllt sein:

4.2 Verschieben von unstable nach stable

Sicherheitsrelevante Aktualisierungen für ein bestimmtes Paket werden zuerst im unstable Baum durchgeführt. Nach einer Wartezeit von weniger als 12 Stunden werden die .info und .patch Dateien des Pakets auch in den stable Baum kopiert. Die Wartezeit soll für eine Überprüfung genutzt werden, ob das aktualisierte Paket funktioniert und die Sicherheitsaktualisierung keine neuen Probleme mit sich bringt.

5 Benachrichtigungen verschicken

Manche Nutzer aktualisieren ihre Software nicht sehr häufig. Damit möglichst schnell alle Nutzer aktualisierte Versionen der Pakete mit Sicherheitslücken installieren und benutzen, kann ein Paketbetreuer darum bitten, dass eine entsprechende Ankündigung über die Mailing-Liste "Fink announcement" verschickt wird.

5.1 Wer darf verschicken?

Diese Ankündigung darf nur vom Fink Security Team verschickt werden. Meistens wird das von dmalloc@users.sourceforge.net erledigt und einem PGP-Schlüssel mit folgender Signatur:

Das obige ist absichtlich nicht als Link formatiert.

Weitere autorisierte Mitglieder des Teams sind: (fügen sie hier ihre Email-Adresse und den öffentlichen Schlüssel ein.)

peter@pogma.com signiert durch einen PGP-Schlüssel mit der Signatur:

ranger@befunk.com signiert durch einen PGP-Schlüssel mit der Signatur:

5.2 Wie ankündigen?

Damit sicher gestellt ist, dass Sicherheitsankündigungen ein einheitliches Aussehen haben, müssen sich alle an die folgende Vorlage halten.

 ID: FINK-YYYY-MMDD-NN
 Reported: YYYY-MM-DD
 Updated:  YYYY-MM-DD
 Package:  package-name
 Affected: <= versionid
 Maintainer: maintainer-name
 Tree(s): 10.3/stable, 10.3/unstable, 10.2-gcc3.3/stable,10.2-gcc3.3/unstable
 Mac OS X version: 10.3, 10.2
 Fix: patch|upstream
 Updated by: maintainer|forced update (Email)
 Description: A short description describing the issue.
 References: KEYWORD (see above)
 Ref-URL: URL

Ein Beispielsbericht könnte so aussehen:

 ID: FINK-2004-06-01
 Reported:         2004-06-09
 Updated:          2004-06-09
 Package:          cvs
 Affected:         <= 1.11.16, <= 1.12.8
 Maintainer:       Sylvain Cuaz
 Tree(s):          10.3/stable, 10.3/unstable, 10.2-gcc3.3/stable,10.2-gcc3.3/unstable
 Mac OS X version: 10.3, 10.2
 Fix:              upstream
 Updated by: forced update (dmalloc@users.sourceforge.net)
 Description: Multiple vulnerabilities in CVS found by Ematters Security.
 References: BID
 Ref-URL:    http://www.securityfocus.com/bid/10499
 References: CVE
 Ref-URL:    http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0414
 References: CVE
 Ref-URL:    http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0416
 References: CVE
 Ref-URL:    http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0417
 References: CVE
 Ref-URL:    http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0418
 References: FULLDISCURL
 Ref-URL:    http://lists.netsys.com/pipermail/full-disclosure/2004-June/022441.html
 References: MISC
 Ref-URL:    http://security.e-matters.de/advisories/092004.html

Beachten sie bitte, dass sich das Schlüsselwort Affected auf alle Versionen der Software bezieht, die Sicherheitslücken aufweisen, nicht nur auf die, für die es Fink-Pakete gibt. Das Beispiel zeigt dies sehr deutlich.


Copyright Notice

Copyright (c) 2001 Christoph Pfisterer, Copyright (c) 2001-2015 The Fink Project. You may distribute this document in print for private purposes, provided the document and this copyright notice remain complete and unmodified. Any commercial reproduction and any online publication requires the explicit consent of the author.


Generated from $Fink: sec-policy.de.xml,v 1.1 2015/02/24 00:08:32 k-m_schindler Exp $