Gentoo Logo

Zasady postępowania z błędami bezpieczeństwa w Gentoo

Spis treści:

1.  Zakres

Wspierane architektury

Gentoo Linux oferowany jest dla wielu architektur. Cześć z tych architektur posiada większą ilość deweloperów niż inne i z tego powodu zdolni są szybciej odpowiadać na nowe błędy w zabezpieczeniach, podczas gdy podstawowym celem projektu Gentoo Security jest zapewnienie poprawek bezpieczeństwa w tym samym czasie dla każdej architektury. Warto przy tym uwzględnić także fakt, że GLSA muszą być wypuszczane możliwie szybko, aby nasi użytkownicy zostali poinformowani o błędzie i mogli zabezpieczyć swoje komputery.

Z tego powodu zespół bezpieczeństwa dzieli architektury Gentoo na dwie grupy: wspierane i niewspierane.

  • Wspierane: błędy rozpoznane w tych architekturach muszą posiadać rozwiązanie zanim GLSA zostanie wydane
  • Niewspierane: użytkownicy tych architektur będą powiadamiani o nowych błędach, jednak nie będziemy czekać na rozwiązanie błędów na tych architekturach przed wypuszczeniem GLSA i zamknięciem błędu.

Poniżej znajduje się lista aktualnie wspieranych architektur:

Wspierane architektury
alpha
amd64
hppa
ppc
ppc64
sparc
x86

Każda architektura może zostać włączona do wspieranych. Istnieją dwie proste reguły, które muszą zostać spełnione, aby zostać oficjalnie wspieranym przez projekt Gentoo Security:

  • Mianować dewelopera, który jest pierwszą osobą kontaktującą się w sprawach błędów bezpieczeństwa odnośnie danej architektury. Sprawdzimy czy dana osoba jest odpowiedzialna za zagwarantowanie, że błędy bezpieczeństwa są odpowiednio traktowane na określonej architekturze.
  • Zapoznać się opublikowanymi tutaj harmonogramami testowania i oznaczania pakietów jako stabilne.

Release Engineering

Zespół Release Engineering ("releng") zatrudnia dewelopera, który będzie zajmował się koordynacją pomiędzy tym zespołem a zespołem Security.

Release Engineering informuje projekt Security kiedy będzie robiony pierwszy snapshot drzewa na potrzeby mediów instalacyjnych. W czasie pomiędzy tą datą a oficjalnym wydaniem Gentoo (okres przygotowań), osoba ta powinna być informowana (poprzez CC) o wszystkich błędach, które mają związek z bezpieczeństwem systemu.

Jądra

Jądra nie są objęte przez system GLSA. Błędy oczywiście są zgłaszane i naprawiane, ale żaden raport GLSA nie jest wydawany.

Uwaga: Ta zasada może się zmienić, gdy powstaną narzędzia do sprawdzania bezpieczeństwa kolejnych wydań jądra.

Niestabilne pakiety

Zdarza się, że błąd zostanie znaleziony w pakiecie, który nie jest częścią stabilnego drzewa. Jest to przypadek kiedy błąd jest regresją bezpieczeństwa w nowszym (~ARCH) ebuildzie, ale starszy (stabilny) pakiet nie posiada tego błędu, lub wtedy gdy w drzewie nigdy nie było stabilnego ebuilda danego pakietu. W takim przypadku błąd cały czas musi być zgłoszony, po czym zostanie naprawiony, ale nie zostanie wydany GLSA kiedy wszystko zostanie rozwiązane.

Uwaga: Polityka ta może zostać zmieniona w chwili kiedy nasze narzędzia zapewnią bardziej kompleksową aktualizację ścieżek oraz gdy dołączy wystarczająca ilość koordynatorów GLSA do zespołu bezpieczeństwa.

2.  Vulnerability feed

Opublikowane błędy

Każdy błąd w bezpieczeństwie na powinien zostać poprzedzony wprowadzeniem wpisu do Bugzilli jako produkt "Gentoo Security" i komponent "Vulnerabilities" (przypisane do security@gentoo.org). Główne listy bezpieczeństwa powinny posiadać oficjalnie wybranych ludzi przydzielonych do nich, którzy powinni dbać o wpisy do bugzilli dla wszystkich błędów w bezpieczeństwie umieszczonych na tych listach.

Poufne błędy

Poufne błędy (czyli na przykład takie, które pochodzą z bezpośredniej wymiany informacji między deweloperami lub zastrzeżonych list vendor-sec) powinno traktować się w sposób specyficzny. Nie powinny one się pojawić jako publiczne wpisy w bugzilli, ale jedynie w zastrzeżonych mediach takich jak prywatne sekcje bugzilli lub narzędzie GLSAMaker. Powinny zostać one naprawione za pomocą prywatnych kanałów komunikacyjnych pomiędzy koordynatorem GLSA, a osobą zajmującą się pakietem.

Uwaga: Wymiana informacji dotycząca poufnych błędów powinna być odpowiednio kodowana. Należy wysyłać je do określonych członków zespołu bezpieczeństwa oraz kodować przy użyciu klucza GPG. Listę członków zespołu bezpieczeństwa znaleźć można na stronie security.gentoo.org, ich GPD ID można odnaleźć na liście deweloperów Gentoo Linux, a ich klucze na serwerze kluczy subkeys.pgp.net.

3.  Dispatch

Poziom zagrożenia

Aby zapewnić odpowiedni czas reakcji i procedury eskalacji, dla każdego błędu należy przydzielić odpowiedni poziom zagrożenia. Poziom zagrożenia musi bazować na tym jak powszechne jest narażone oprogramowanie wśród użytkowników Gentoo i jak poważne są błędy.

Możemy użyć poniższych dwóch tabel do pomocy przy przydzielaniu poziomu zagrożenia:

Jak powszechny jest dany pakiet Zagrożona konfiguracja
Pakiet systemu Domyślny lub określony A
Powszechny pakiet (występuje prawdopodobnie na co najmniej 1/20 instalacji Gentoo) Domyślny A
Określony B
Oprogramowanie marginalne (występuje przypuszczalnie na mniej niż 1/20 instalacji Gentoo) Domyślny B
Określony C
Pakiet, który nigdy nie posiadał narażonej stabilnej wersji Domyślny lub określony ~
Przewidywany rodzaj błędu Odpowiednia ważność GLSA
Całkowicie zdalny system: zdalne uruchamianie dowolnego kodu z uprawnieniami superużytkownika 0 wysoki
Zdalne aktywne ujawnienie: bezpośrednie zdalne uruchomienie dowolnego kodu z mniejszymi prawami lub prawami użytkownika na serwerze 1 wysoki
Eskalacja lokalnych zezwoleń: błąd w zabezpieczeniach pozwalający ujawnić superużytkownika kiedy posiada się lokalny dostęp 1 wysoki
Zdalne bierne ujawnienie: zdalne uruchamianie dowolnego kodu poprzez kuszenie użytkownika do odwiedzenia złośliwego serwera lub używanie złośliwych danych 2 normalny
Globalne ujawnienie usług: ataki denial of service, hasła lub wycieki baz danych, utrata danych (ataki symlink) 3 normalny
Pozostałe: Cross-Site Scripting, wyciek informacji... 4 niski

Poniżej znajduje się tabela z listą poziomów zagrożenia. Podczas zgłaszania błędu na bugzilli należy nadać jedną z tych wartości.

Poziom zagrożenia Odpowiednia ocena Opóźnienie GLSA
Blocker (Bloker) A0, B0 1 dzień tak
Critical (Krytyczny) A1, C0 3 dni tak
Major (Poważny) A2, B1, C1 5 dni tak
Normal (Normlany) A3, B2, C2 10 dni tak
Minor (Nieznaczny) A4, B3, B4, C3 20 dni ?
Trivial (Trywialny) C4, ~0, ~1, ~2, ~3, ~4 40 dni nie

Uwaga: Opóźnienie przedstawione w tej tabeli jest przedstawieniem maksymalnego czasu pomiędzy wydaniem poprawki przez dewelopera pakietu, a wydaniem stabilnego ebuildu i odpowiadającemu mu GLSA.

Odbiór zgłoszeń błędów związanych z bezpieczeństwem

Ktoś powinien odpowiednio zareagować na każde zgłoszenie jakie pojawia się na Bugzilli, oto jak powinien postępować:

  • Wyszukiwanie duplikatów: jeśli jakiś wpis opisuje błąd, który został już zgłoszony powinien zostać on rozwiązany jako DUPLICATE (duplikat)
  • Sprawdzanie poprawności komponentu (component): jeżeli błąd nie jest słabym punktem komponent powinien zostać odpowiednio zmieniony
  • Sprawdzanie czy błąd jest rzeczywiście słabym punktem i czy narażony jest pakiet z dystrybucji Gentoo Linux, w przeciwnym wypadku należy rozwiązać błąd jako INVALID.

W czasie tego procesu może być konieczne zapytanie o szczegóły zgłaszającego błąd. Błąd posiada status NEW (nowy) tak długo jak to będzie konieczne. Kiedy błąd przejdzie testy poprawności (sanity tests) powinien zostać zaakceptowany, a osoby zajmujące się utrzymaniem porządku na bugzilli (bug wranglers) powinno postępować w sposób opisany poniżej:

  • Zmiana nazwy błędu tak, aby zawierał wpis kategoria/nazwa-pakietu (na przykład: "net-mail/clamav: DoS using RAR files")
  • Ocena i przydzielenie poziomu ważności (patrz wyżej)
  • Ustawić status jako ASSIGNED
  • Zmienić pole statusu na poprawny kod ważności i statusu
  • Dodać cc do opiekunów pakietu zgodnie z plikiem metadata pakietu
  • Ustawić pole URL do raportu błędu upstream
  • Wyszukać zarezerwowane lub przypisane identyfikatory CVE i dodanie ich do tytułu raportu, a w przypadku braku prośba o przyznanie CVE
  • Opcjonalnie można przydzielić koordynatora GLSA dla danego błędu poprzez dodanie nazwiska koordynatora do pola statusu.

Ostrzeżenie: Nie należy zmieniać poziomu ważności błędu jeśli został on już przyznany. Jeżeli chcemy zwrócić uwagę deweloperów, należy użyć pola Priority.

Rama czasowa i procedury kopii zapasowej

Poprawka (dispatch) powinna zostać wykonana w czasie jak najkrótszym od zgłoszenia błędu, tak aby zagwarantować jak najkrótsze opóźnienia dla poważnych błędów i równocześnie, aby okazać wdzięczność dla osoby zgłaszającej błąd. Docelowym opóźnieniem jest 12 godzin. Security bug wrangler musi dostarczyć listę możliwych koordynatorów GLSA z preferowanymi obszarami ekspertyz. Aby zapewnić trwałą poprawkę, osoba zajmująca się sprzątaniem bugzilli z błędów związanych z bezpieczeństw (security bug wrangler), powinna wykonywać odpowiednie kopie zapasowe.

4.  Korekcja błędów oraz szkic GLSA

Rola koordynatora GLSA

Koordynator GLSA odpowiada za następujące zadania:

  • Wyznaczyć co należy zrobić, aby zamknąć błąd (przykładowo zidentyfikować poszukiwaną wersję zawierając poprawkę)
  • Jeżeli nie jest dostępna poprawka, należy upewnić się, że błąd jest poprawnie zgłoszony do autora programu, pole statusu ustawić na upstream
  • Jeśli poprawka jest już dostępna należy zaangażować opiekuna pakietu do stworzenia i zaakceptowania ebuilda zawierającego daną łatkę oraz ustawienia pola statusu na ebuild
  • Kiedy ebuild zostanie już zaakceptowany należy ocenić jakie słowa kluczowe (keywords) potrzebne są dla załatanego ebuilda, zespoły poszczególnych architektur powinny je przetestować i oznaczyć je jako stabilne na danej architekturze (zespoły architektur [arch-teams] powinny znajdować się na liście CC błędu), a na koniec należy oznaczyć pole statusu jako stable
  • Opiekuni architektur (arch-maintainers) powinni oznaczyć ebuild jako stabilny jeśli poprawiony ebuild nie posiada już błędów z poprzedniej wersji
  • Równolegle, należy napisać szkic GLSA używając GLSAMaker tool
  • Kiedy poprawny ebuild jest gotowy dla wszystkich wspieranych architektur należy ustawić pole statusu na glsa.

Uwaga: Jeżeli widoczny jest postęp w naprawie błędu, a przydzielony koordynator GLSA nie reaguje, pozostali członkowie zespołu bezpieczeństwa mogą pomagać poprzez uaktualnianie statusu.

Rama czasowa i procesy eskalacji

Jeżeli chcemy poznać docelowe opóźnienie w rozwiązaniu błędu, została zdefiniowana liczba procedur eskalacji. Zawierają one:

  • Kiedy błąd jest w fazie początkowej należy zwrócić na niego szczególną uwagę oraz należy zmienić pole statusu na odpowiednik ze znakiem "+": upstream+, ebuild+, stable+ and glsa+
  • Jeżeli nie jest dostępna poprawka (status upstream+), musi zostać podjęta decyzja o zamaskowaniu pakietu: zespół bezpieczeństwa może zamaskować pakiet, który nie jest zależny sam od siebie, jednak należy posiadać zezwolenie administratora TLP, aby zamaskować pakiet, który nie jest samodzielny
  • Jeżeli opiekun nie stworzy ebuilda w 48 godzin po zgłoszeniu (status ebuild+), zespół bezpieczeństwa sam powinien próbować stworzyć odpowiedniego ebuilda
  • Jeżeli testowanie i przechodzenie pakietu do wersji stabilnej trwa zbyt długo (status stable+) zespół bezpieczeństwa poprosi na kanałach IRC oraz na liście gentoo-dev o większą ilość testerów. Ebuild zostanie oznaczony jako stabilny przez nich samych jednak w przypadku gdy występują problemy z stabilnością należy go zamaskować
  • Jeżeli koordynator nie zainteresuje się i nie naszkicuje GLSA (status glsa+), wtedy inny członek zespołu bezpieczeństwa powinien naszkicować GLSA i udostępnić go do recenzji dla innych.

Dobre zwyczaje dla błędów bezpieczeństwa

Błędy bezpieczeństwa różnią się od innych błędów tym, że sposób aktualizacji musi zostać przedstawiony użytkownikom poprzez GLSA jak najbardziej prosto. Dlatego opiekunowie pakietów i koordynatorzy GLSA powinni zastosować się do poniższych dobrych rad:

  • Ebuild zawierający poprawkę bezpieczeństwa powinien posiadać swój własny numer tak, aby uruchomił się w normalnym procesie aktualizacji systemu
  • Ebuild zawierający łatkę bezpieczeństwa powinien posiadać wyższy numer niż poprzednio wydana wersja tak, aby prosty sposób aktualizacji mógł zostać zaproponowany użytkownikowi
  • W przypadku poprawki, powinna ona zostać zaaplikowana jedynie do ostatniej wersji. Nie ma potrzeby zmiany numeru wersji dla wszystkich ebuildów z poprawką
  • Wersje posiadające błędy i słabe punkty powinny pozostać w drzewie dopóki błąd nie otrzyma statusu stable, aby poprawnie ocenić jakie słowa kluczowe są potrzebne dla poprawionej wersji.

Czasowe GLSA

Jeśli błędy typu blocker, critical lub major nie mogą zostać całkowicie naprawione z docelowym opóźnieniem, należy napisać wcześniejsze ostrzeżenie GLSA z informacją. Ta wersja GLSA zostanie zastąpiona finalną kiedy tylko ostateczna poprawka będzie dostępna.

Jeżeli powszechny pakiet (typ A lub B) zamaskowany jest z powodów bezpieczeństwa, powinien zostać wydany czasowy GLSA dla wyjaśnienia przyczyn, dlaczego w danej chwili pakiet jest niedostępny i/lub dlaczego użytkownicy powinni odinstalować obecną wersję. Ta wersja GLSA zostanie zastąpiona wersją finalną w chwili gdy poprawka będzie dostępna i pakiet zostanie odmaskowany.

5.  Proces publikacji GLSA

Recenzowanie

Kiedy GLSA jest już gotowe, powinno się wysłać je do recenzji. Przynajmniej dwóch członków zespołu bezpieczeństwa musi zatwierdzić szkic GLSA. Kiedy już szkic przejdzie ten proces powinien zostać mu przydzielony oficjalny numer GLSA.

Wydanie GLSA

Kiedy GLSA przejdzie proces weryfikacji (po upewnieniu się, że ebuild znalazł się już w stabilnej gałęzi drzewa) koordynator GLSA powinien zatwierdzić plik XML GLSA w repozytorium CVS Gentoo. Kiedy tak zrobi GLSA automatycznie pojawi się na oficjalnej stronie GLSA i w RDF.

Publikacja GLSA

Wersja tekstowa GLSA musi zostać opublikowana w następujący sposób:

Oficjalna lista mailingowa Gentoo Linux gentoo-announce@lists.gentoo.org
Bugtraq security mailing-list bugtraq@securityfocus.com
Full-disclosure security mailing-list full-disclosure@lists.grok.org.uk
Linuxsecurity.com advisories service security-alerts@linuxsecurity.com
Gentoo Linux announcement forum http://forums.gentoo.org/viewforum.php?f=16

Powinna zostać wysłana jedna wiadomość elektroniczna, z poniższymi danymi:

  • Pole To: musi zostać ustawione na gentoo-anounce
  • Pole Cc: musi zawierać pozostałe adresy poczty elektronicznej
  • Pole From: i Return-Path: musi zostać ustawiony adres koordynatora GLSA w domenie @gentoo.org
  • Pole Subject: musi wyglądać następująco "[ GLSA XXXXYY-ZZ ] Twój błąd"
  • Treść powinna zawierać jedynie wersję tekstową GLSA
  • Wiadomość musi zostać podpisana przy użyciu klucza GPG koordynatora GLSA.

Uwaga: Klucze identyfikacyjne deweloperów można znaleźć na liście deweloperów Gentoo Linux. Wszystkie klucze GPG zespołu bezpieczeństwa opublikowane są na publicznych serwerach kluczy, włączając w to subkeys.pgp.net.

Uwaga: Aby zminimalizować ryzyko błędów w procesie publikacji, publikacja na forum jest wykonywana automatycznie kiedy tylko automat dostanie zawiadomienie.

Kiedy GLSA zostanie opublikowane odpowiadający mu błąd powinien zostać rozwiązany jako FIXED z numerem GLSA w sekcji komentarzy danego błędu.

Errata GLSA

Zdarzają się sytuacje kiedy podczas procesu recenzji przez innych koordynatorów prześliźnie się błąd i zostanie opublikowane błędne wydanie GLSA. W zależności od ważności błędu, należy stosować następującą politykę erraty:

Typ erraty GLSA Zalecane działania
Typ: prezentacja, gramatyka lub literówka. Nie robimy nic.
Błąd w tytule: tytuł odnosi się do innego pakietu lub nie opisuje błędu w poprawny sposób. Powinna zostać opublikowana errata GLSA, zastępując błędną.
Błąd w opisie: problem nie jest opisany odpowiednio. Kod XML w GLSA powinien być jedynie poprawiony bez wydawania nowego GLSA.
Pominięcie: GLSA jest poprawne, ale niekompletne. Trzeba zaktualizować inny pakiet, aby zabezpieczyć się przed danym błędem. Oddzielne wydanie GLSA powinno zostać opublikowane dla innego pakietu zawierającego błąd.
Błąd w dotkniętym/niedotkniętym numerze wersji, jednak ludzie używający stabilnych pakietów i ci, którzy zastosowali się do instrukcji z GLSA są chronieni. Kod XML w GLSA powinien zostać jedynie poprawiony bez wydawania nowego GLSA.
Błąd w dotkniętym/niedotkniętym numerze wersji, użytkownicy stosujący instrukcje zawarte w GLSA nie są chronieni Powinna zostać opublikowana errata GLSA, zastępująca błędną


Drukuj

Zaktualizowano 14 kwietnia 2009

Podsumowanie: Ten dokument opisuje zasady postępowania z błędami zawartymi w pakietach wchodzących w skład Gentoo Linux, które zostały udostępnione jego użytkownikom.

Thierry Carrez
Autor

Sune Kloppenborg Jeppesen
Autor

Matthias Geerdsen
Autor

Robert Buchholz
Autor

Damian Kuras
Tłumacz

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.