| Available Languages: | Deutsch | English | Français | 日本語 (Nihongo) | Português | 中文 (简) (Simplified Chinese) | |
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.
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.
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
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.
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.
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.
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ücken | Antwortzeit |
|---|---|
| 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. |
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.
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.
Die obigen Schlüsselworte stimmen mit der Empfehlung des CVE überein, wie man hier nachlesen kann.
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:
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.
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.
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:
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 (c) 2001 Christoph Pfisterer, Copyright (c) 2001-2020 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 $