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

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:

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.

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.

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.

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:

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.

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.

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.

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:

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.

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:

Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike.