Uwaga! To tłumaczenie jest przestarzałe, prosimy przejść do oryginału.
Najczęściej zadawane pytania nt. bezpieczeństwa Debiana
Poniższe pytania pojawiają się najczęściej, dlatego odpowiedzi na nie postanowiliśmy umieścić tutaj.
- Sygnatura w wiadomościach nie przechodzi poprawnie procedury sprawdzania!
- Jak obsługiwane są sprawy związane z bezpieczeństwem w Debianie?
- Dlaczego trzymacie się starej wersji danego pakietu?
- Kiedy dany pakiet pojawi się na security.debian.org?
- Co oznacza
local (remote)
? - Numer wersji pakietu wskazuje na to, że nadal posiadam podatną na błędy wersję!
- Otrzymłem powiadomienie dotyczące bezpieczeństwa, ale brakuje zbudowanej paczki dla jednej architektury.
- Jak obsługiwane są sprawy związane z bezpieczeństwem w edycji unstable?
- Jak obsługiwane są sprawy związane z bezpieczeństwem w edycji testing?
- Jak obsługiwane są sprawy związane z bezpieczeństwem w contrib i non-free?
- W zaleceniach jest informacja, że w unstable błąd został poprawiony w wersji 1.2.3-1, ale w unstable jest wersja 1.2.5-1, dlaczego?
- Dlaczego nie ma oficjalnych serwerów lustrzanych security.debian.org?
- Widziałem DSA 100 i DSA 102, a gdzie się podziało DSA 101?
- W jaki sposób mogę się skontaktować z grupą ds. bezpieczeństwa?
- Wydaje mi się, że znalazłem problem związany z bezpieczeństwem. Co mam robić?
- Co powinienem zrobić z problemem dotyczącym bezpieczeństwa w jednym z moich pakietów?
- Próbowałem ściągnąć pakiet podany w jednej z informacji nt. bezpieczeństwa, ale otrzymałem błąd
plik nie odnaleziony
. - Posiadam łatkę, czy mogę umieścić ją bezpośrednio na security.debian.org?
- Posiadam łatkę, czy mogę w takim razie umieścić ją w katalogu proposed-updates?
- Jestem pewien, że moje pakiety są w porządku. Jak mogę je umieścić na serwerze?
- W jaki sposób mogę pomóc przy obsłudze bezpieczeństwa?
- Jaki jest zakres proposed-updates?
- W jaki sposób jest formowana grupa ds. bezpieczeństwa?
- Jak długo będą dostarczane poprawki związane z bezpieczeństwem?
- Jak mogę sprawdzić integralność pakietów?
- Co mam zrobić jeżeli jakiś inny pakiet przestał działać poprawnie po zainstalowaniu poprawek bezpieczeństwa?
- Czym jest identyfikator CVE?
- Czy Debian wydaje komunikaty DSA dla każdego wpisu CVE?
- Czy Debian może tworzyć identyfikatory CVE?
Q: Sygnatura w wiadomościach nie przechodzi poprawnie procedury sprawdzania!
A: Jest to najwyraźniej problem po stronie użytkownika. Lista debian-security-announce posiada filtr dopuszczający jedynie wiadomości z poprawną sygnaturą należącą do członków grupy ds. bezpieczeństwa.
Najprawdopodobniej oprogramowanie pocztowe użytkownika zmienia wiadomość, przez co sygnatura nie jest już poprawna. Należy się upewnić, że oprogramowanie nie koduje lub dekoduje MIME jak również, że nie zamienia znaków tab na spację i vice versa.
Znanymi winowajcami są fetchamil (z włączoną opcją mimedecode), formail (tylko z procmail 3.14) i evolution.
Q: Jak obsługiwane są sprawy związane z bezpieczeństwem w Debianie?
A: Po otrzymaniu przez grupę ds. bezpieczeństwa zgłoszenia naruszenia bezpieczeństwa, jeden lub więcej członków przeanalizuje je i rozważy wpływ zdarzenia na stabilne wydanie Debiana (tj. czy jest na to zdarzenie odporne czy nie). Jeżli system nie jest odporny, rozpoczynamy prace nad poprawką do tego problemu. Kontaktujemy się także z opiekunem pakietu, o ile on nie skontaktował się pierwszy z grupą ds. bezpieczeństwa. Następnie poprawka jest testowana i przygotowywane są pakiety, które zostaną później skompilowane na wszystkie stabilne architektury i umieszczone na serwerach. Po dokonaniu powyższych kroków wydawana jest informacja nt. bezpieczeństwa dotycząca danego pakietu.
Q: Dlaczego trzymacie się starej wersji danego pakietu?
Najważniejszą zasadą podczas tworzenia nowej wersji pakietu rozwiązującej dany problem bezpieczeństwa jest dokonanie jak najmniejszej ilości zmian. Nasi użytkownicy i deweloperzy oczekują niezmiennego zachowania się pakietu po jego wydaniu, więc każda zmiana może zniszczyć czyjś system. Ma to miejsce szczególnie w przypadku bibliotek: niezależnie od tego, jak mała jest zmiana należy się upewnić, że nie zmienia się Application Program Interface (API) lub Application Binary Interface (ABI).
To oznacza, że przejście na najnowszą wersję nie jest dobrym rozwiązaniem. Zamiast tego, odpowiednie zmiany są nanoszone na starsze wersje znajdujące się w dystrybucji stabilnej. Zazwyczaj autorzy programu są chętni do pomocy, jeśli zachodzi taka potrzeba. Grupa ds. bezpieczeństwa również może być w stanie pomóc.
W niektórych przypadkach nie jest możliwe naniesienie łatki na starszą wersję. Jest tak wtedy, gdy wymagałoby to przepisania lub zmodyfikowania dużej ilości kodu. W takim przypadku może być konieczne przejście na najnowszą wersję, ale musi to być zrobione we współpracy z grupą ds. bezpieczeństwa.
Q: Kiedy dany pakiet pojawi się na security.debian.org?
A: Naruszenie bezpieczeństwa w dystrybucji stabilnej sprawia, że pakiet z poprawką pojawia się na security.debian.org. Żaden inny powód nie wchodzi w grę. Rozmiar naruszenia bezpieczeństwa nie stanowi tutaj problemu. Zazwyczaj grupa ds. bezpieczeństwa przygotowuje pakiety razem z opiekunami pakietów. Pakiet znajdzie się na security.debian.org pod warunkiem, że ktoś (zaufany) rozwiąże problem, skompiluje wszystkie wymagane pakiety i wyśle je do grupy ds. bezpieczeństwa. Nawet najbardziej oczywiste poprawki są ważne.
Uaktualnienia bezpieczeństwa służą jednemu: dostarczeniu poprawki dla problemu bezpieczeństwa. Nie są one sposobem na przemycenie dodatkowych zmian do wydania stabilnego bez przejścia przez normalną procedurę wydawniczą.
A: Zgłoszenia opisujące luki, których sposób wykorzystania nie można określić
jednoznacznie wg schematu lokalny czy zdalny. Z niektórych błędów nie da się
skorzystać zdalnie, np. nie są one powiązane z demonem nasłuchującym
na danym porcie. Jeżeli jednak można je wykorzystać poprzez specjalny plik
dostarczony przez sieć w przypadku gdy podatna usługa nie jest stale podłączona
do sieci, w takim przypadku piszemy local (remote)
.
Tego typu luki znajdują się gdzieś pomiędzy lukami lokalnymi a zdalnymi. Często dotyczą one np. załączników, które można przesłać przez sieć, np. załącznik do wiadomości pocztowej lub archiwum pobrane ze strony internetowej.
Q: Numer wersji pakietu wskazuje na to, że nadal posiadam podatną na błędy wersję!
A: Zamiast uaktualniać pakiet do najnowszej wersji, nanosimy poprawki do wersji pakietu, która została dostarczona razem z dystrybucją stabilną. Powodem takiego działania jest zapewnienie, by wydana dystrybucja zmieniła się w jak najmniejszym stopniu, dzięki czemu nic się niespodziewanie nie zmieni czy też przestanie działać w wyniku zaaplikowania łatki. Możesz sprawdzić, czy posiadasz bezpieczną wersję pakietu przez przejrzenie pliku zmian danego pakietu lub porównując jego dokładną wersję z wersją podaną w informacji Debiana na temat bezpieczeństwa danego pakietu.
A: Zazwyczaj Zespół ds. Bezpieczeństwa wydaje informację z poprawionymi pakietami dla wszystkich wspieranych przez Debiana architektur. Jednak niektóre z nich są wolniejsze od pozostałych i może się zdarzyć, że poprawiony pakiet jest dostępny tylko dla części architektur. Mniej popularne architektury reprezentują niewielki ułamek naszych użytkowników. W zależności od potrzeb wydawniczych możemy zdecydować o natychmiastowej publikacji powiadomienia. Brakujące pakiety będą udostępnione jak tylko będą dostępne, ale nie będzie osobnego powiadomienia o tym fakcie. Oczywiście nigdy nie wydajemy powiadomień jeżeli nie są dostępne pakiety dla architektur i386 oraz amd64.
Q: Jak obsługiwane są sprawy związane z bezpieczeństwem w edycji unstable?
A: Sprawy związane z bezpieczeństwem w edycji niestabilnej (unstable) są obsługiwane głównie przez opiekunów pakietów, a nie przez Zespół ds. Bezpieczeństwa Debiana. Mimo że członkowie zespołu mogą wysyłać poprawki dotyczące bezpieczeństwa, gdy zauważą brak aktywności ze strony opiekunów, wsparcie dla edycji stabilnej będzie zawsze na pierwszym miejscu. Jeżeli potrzebny jest bezpieczny (i stabilny) serwer, mocno zachęcamy do pozostania przy edycji stabilnej.
Q: Jak obsługiwane są sprawy związane z bezpieczeństwem w edycji testing?
A: Edycja testowa, jeżeli chodzi o sprawy związane z bezpieczeństem, korzysta z całego projektu dla edycji niestabilnej. Jednak występuje tutaj minimum dwudniowy poślizg przy migracji, a czasami poprawki mogą być wstrzymane przy przejściu pakietu do edycji testowej. Zespół ds. Bezpieczeństwa stara się obsłużyć takie wstrzymane migracje, aby wysłane poprawki przeszły do edycji testowej, ale nie zawsze jest to możliwe i mogą pojawić się opóźnienia w migracji. Zwłaszcza miesiące po wydaniu nowej edycji stabilnej, kiedy to wiele nowych wersji zostało wysłanych do edycji niestabilnej, poprawki bezpieczeństwa do edycji testowej mogą pozostać w tyle. Jeżeli potrzebny jest bezpieczny (i stabilny) serwer, mocno zachęcamy do pozostania przy edycji stabilnej.
Q: Jak obsługiwane są sprawy związane z bezpieczeństwem w contrib i non-free?
A: Odpowiedź jest krótka: nie są obsługiwane. Contrib i non-free nie są oficjalnymi częściami dystrybucji Debiana, nie są one wydawane i z tego powodu nie są obsługiwane przez grupę ds. bezpieczeństwa. Niektóre pakiety non-free są dystrybuowane bez źródeł lub licencji zezwalającej na dystrybucję zmodyfikowanych wersji. W takich przypadkach nie ma nawet możliwości, by pisać poprawki bezpieczeństwa. Jeżeli jest możliwe naprawienie błędu, a opiekun pakietu lub ktoś inny dostarczy odpowiednio zaktualizowane pakiety, wtedy zespół ds. bezpieczeństwa zajmie się tym i wyda odpowiednie zalecenia.
A: Staramy się podać pierwszą wersję w unstable, która ma poprawiony dany błąd. Czasami, w międzyczasie, opiekun zamieści nowszą wersję. Należy porównać wersję z unstable z wersją podaną przez zespół. Jeżeli jest ona taka sama lub wyższa, wtedy program jest wolny od podanego błędu.
Q: Dlaczego nie ma oficjalnych serwerów lustrzanych security.debian.org?
A: Prawdę mówiąc są. Istnieje kilka oficjalnych serwerów lustrzanych, skonfigurowanych poprzez aliasy DNS. Celem security.debian.org jest dostarczenie poprawek bezpieczeństwa tak szybko i prosto jak to tylko jest możliwe.
Zachęcanie do używania nieoficjalnych serwerów lustrzanych skomplikowałoby sprawę, co zazwyczaj nie jest potrzebne, a mogłoby powodować frustrację w przypadku, gdyby serwery lustrzane nie były aktualne.
Q: Widziałem DSA 100 i DSA 102, a gdzie się podziało DSA 101?
A: Wielu dystrybutorów (głównie GNU/Linux, ale też pochodne BSD) koordynuje informacje na temat bezpieczeństwa dla pewnych zagrożeń i ustalają pewien przedział czasowy, aby wszyscy dostawcy mogli wydać te informacje w jednym czasie. Umówiono się tak, aby nie dyskryminować dostawców, którzy potrzebują więcej czasu (np. gdy dostawca musi przeprowadzić pakiety przez długi proces testów QA lub obsługuje wiele architektur czy binarnych dystrybucji). Nasza grupa ds. bezpieczeństwa również przygotowuje zawczasu informacje na temat bezpieczeństwa. Czasami inne zdarzenie muszą być obsłużone zanim te informacje zostaną wydane. Stąd zdarzają się luki w numerach informacji.
Q: W jaki sposób mogę się skontaktować z grupą ds. bezpieczeństwa?
A: Informacje na temat bezpieczeństwa mogą być wysyłane na adres [email protected], lub na [email protected]. Obie listy dyskusyjne są czytane przez członków grupy ds. bezpieczeństwa.
Jeśli jest taka potrzeba, list może być zaszyfrowany przy użyciu klucza Debian Security Contact (key ID 0x0D59D2B15144766A14D241C66BAF400B05C3E651). Klucze PGP/GPG poszczególnych członków grupy są dostępne na serwerze keyring.debian.org.
Q: Wydaje mi się, że znalazłem problem związany z bezpieczeństwem. Co mam robić?
A: Jeśli wiesz o istnieniu problemu związanego z bezpieczeństwem w dowolnym pakiecie zawsze skontaktuj się z odpowiednią grupą ds. bezpieczeństwa. Jeśli debianowa grupa potwierdzi podatność na dany błąd, i wydaje się, że inni dostawcy też mogą być nim dotknięci, grupa kontaktuje się z tymi dostawcami. Jeśli znaleziony błąd nie został jeszcze upubliczniony, grupa ds. bezpieczeństwa stara się skoordynować informacje na temat bezpieczeństwa z innymi dostawcami, by wszystkie znaczące dystrybucje wydały je w tym samym czasie.
Jeżeli znaleziony błąd został już upubliczniony, prosimy o przesłanie
raportu do Debian BTS i oznaczenie go tagiem security
.
Jeśli jesteś deweloperem Debiana, patrz niżej.
Q: Co powinienem zrobić z problemem dotyczącym bezpieczeństwa w jednym z moich pakietów?
A: Jeśli dowiesz się o problemie dotyczącym bezpieczeństwa w pakiecie Twoim lub innej osoby zawsze skontaktuj się z grupą ds. bezpieczeństwa, dostępną pod adresem [email protected]. Grupa śledzi zaległe problemy bezpieczeństwa, może pomóc opiekunom z problemami lub też sama naprawi dany problem. Grupa jest też odpowiedzialna za wysyłanie informacji na temat bezpieczeństwa i zarządzanie security.debian.org.
Developer's Reference zawiera kompletne instrukcje co i jak w takim przypadku robić.
Ważne jest, żebyś nie umieszczał pakietu w innej dystrybucji niż niestabilna bez wcześniejszej zgody grupy ds. bezpieczeństwa, ponieważ ominięcie jej spowoduje zamieszanie i więcej pracy.
A: Gdy tylko nowa wersja pakietu zastępuje starszą na security.debian.org, zazwyczaj stary pakiet jest usuwany zanim nowy zostaje tam umieszczony. Stąd ten błąd. Nie chcemy dystrybuować pakietów ze znanymi błędami bezpieczeństwa dłużej niż jest to wymagane.
Używaj pakietów z najnowszych informacji nt. bezpieczeństwa,
które są rozsyłane za pomocą listy dyskusyjnej debian-security-announce. Najlepiej uruchomić
apt-get update przed aktualizacją pakietu.
Q: Posiadam łatkę, czy mogę umieścić ją bezpośrednio na security.debian.org?
A: Nie, nie możesz. Archiwum na security.debian.org jest zarządzane przez grupę ds. bezpieczeństwa, która musi zatwierdzić wszystkie pakiety. Zamiast tego powinieneś wysyłać łatki lub odpowiednie pakiety źródłowe do grupy ds. bezpieczeństwa na adres [email protected]. Przesłane pliki zostaną przejrzane i prawdopodobnie umieszczone na serwerze z pewnymi zmianami lub bez.
Developer's Reference zawiera kompletne instrukcje co i jak w takim przypadku robić.
Q: Posiadam łatkę, czy mogę w takim razie umieścić ją w katalogu proposed-updates?
A: Technicznie możesz, ale nie powinieneś, ponieważ kłóci się to z pracą grupy ds. bezpieczeństwa. Pakiety z security.debian.org są automatycznie kopiowane do katalogu proposed-updates. Jeśli pakiet z tym samym lub wyższym numerem wersji znajduje się już w tym archiwum, uaktualnienie bezpieczeństwa zostanie odrzucone przez system obsługi archiwum. W ten sposób dystrybucja stabilna zostaje pozbawiona uaktualnienia bezpieczeństwa dla tego pakietu, chyba że "zły" pakiet zostanie odrzucony z katalogu proposed-updates. Dlatego zamiast powyższego, skontaktuj się z grupą ds. bezpieczeństwa i dołącz wszelkie szczegóły dotyczące błędu lub dziury w bezpieczeństwie. Do listu dołącz również pliki źródłowe (tj. pliki diff.gz i dsc).
Developer's Reference zawiera kompletne instrukcje co i jak w takim przypadku robić.
Q: Jestem pewien, że moje pakiety są w porządku. Jak mogę je umieścić na serwerze?
A: Jeśli jesteś całkowicie pewien, że Twoje pakiety niczego nie zepsują,
że nadany numer wersji jest rozsądny (tj. większy od wersji
w dystrybucji stabilnej i mniejszy niż w dystrybucji testowej/niestabilnej),
że nie zmieniłeś zachowania się pakietu, poza częścią związaną z problemem
bezpieczeństwa, że skompilowałeś go dla odpowiedniej dystrybucji
(tj. dla oldstable-security lub stable-security),
że pakiet zawiera oryginalne źródła w przypadku gdy jest on nowy na
security.debian.org, że możesz stwierdzić, że łatka względem najnowszej
wersji pakietu jest poprawna i zmienia tylko dany problem z bezpieczeństwem
(sprawdź to przy użyciu interdiff -z i dwóch plików
.diff.gz), że sprawdziłeś łatkę przynajmniej trzy razy
oraz że debdiff nie znajduje żadnych zmian, to wtedy możesz
umieścić pliki bezpośrednio w katalogu incoming w
ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue na serwerze
security.debian.org. Wyślij również zawiadomienie ze wszystkimi szczegółami
i odnośnikami na adres [email protected].
Q: W jaki sposób mogę pomóc przy obsłudze bezpieczeństwa?
A: Przyjrzyj się dobrze każdemu problemowi przed jego zgłoszeniem na [email protected]. Jeśli jesteś w stanie dostarczyć łatki, to znacznie to przyspieszy cały proces. Nie przekazuj po prostu listów z bugtraq, ponieważ my też je otrzymaliśmy — ale za to wysyłaj nam dodatkowe informacje o zgłoszonych na bugtraq problemach.
Dobrym sposobem na rozpoczęcie prac związanych z bezpieczeństem jest pomoc przy Debian Security Tracker (instrukcje).
Q: Jaki jest zakres proposed-updates?
A: Ten katalog zawiera pakiety, które mają wejść do następnej rewizji dystrybucji stabilnej. Za każdym razem, gdy opiekun umieszcza na serwerze pakiety dla dystrybucji stabilnej, lądują one w katalogu proposed-updates. Ponieważ dystrybucja stabilna ma być stabilna, nie ma żadnych automatycznych uaktualnień. Grupa ds. bezpieczeństwa umieści na serwerze poprawione pakiety wspomniane w informacjach nt. bezpieczeństwa dla dystrybucji stabilnej, ale najpierw znajdą się one w katalogu proposed-updates. Co kilka miesięcy Menedżer Wydań Stabilnych sprawdza listę pakietów w katalogu proposed-updates i decyduje czy pakiet nadaje się do dystrybucji stabilnej czy nie. Są one zestawiane w następną rewizję stabilną (np. 2.2r3 czy 2.2r4). Pakiety, które nie pasują, prawdopodobnie będę odrzucone i usunięte w katalogu proposed-updates.
Zauważ, że pakiety umieszczone przez opiekunów (a nie przez grupę ds. bezpieczeństwa) w proposed-updates/ nie są obsługiwane przez grupę ds. bezpieczeństwa.
Q: W jaki sposób jest formowana grupa ds. bezpieczeństwa?
A: W grupach ds. bezpieczeństwa Debiana znajduje się kilku oficerów i sekretarzy. Sama grupa ds. bezpieczeństwa powołuje ludzi do wstąpienia do grupy.
Q: Jak długo będą dostarczane poprawki związane z bezpieczeństwem?
A: Grupa ds. bezpieczeństwa stara się dostarczać poprawki do stabilnej dystrybucji przez rok po wydaniu następnej, poza sytuacjami gdy inna dystrybucja jest wydana w tym samym roku. Jest praktycznie niemożliwe, by dostarczać poprawki dla trzech dystrybucji; obsługa dwóch jednocześnie jest już wystarczająco trudna.
Q: Jak mogę sprawdzić integralność pakietów?
A: Proces ten wymaga porównania sygnatury pliku Release z kluczem publicznym użytym do archiwizacji. Plik Release zawiera sumy kontrolne do plików Packages and Sources, które zawierają sumy kontrolne plików binarnych i źródeł. Szczegółowe informacje o tym jak sprawdzić integralność pakietów można znaleźć na stronie Debian Securing Manual.
A: Po pierwsze należy sprawdzić dlaczego pakiet jest uszkodzony i jaki to ma związek z aktualizacją dotyczącą bezpieczeństwa. Następnie należy skontaktować się z grupą ds. bezpieczeństwa (jeżeli jest to poważny problem), lub z menedżerem wydań stabilnych (jeżeli jest to mniej ważny problem). Mówimy tutaj o różnych pakietach, które przestały działać po zainstalowaniu aktualizacji dotyczącej bezpieczeństwa innego pakietu. Jeżeli nie wiesz co poszło źle, ale masz rozwiązanie - również skontaktuj się z grupą ds. bezpieczeństwa. Możesz zostać przekierowany do menedżera wydania stabilnego.
Q: Czym jest identyfikator CVE?
A: Projekt "The Common Vulnerabilities and Exposures" przypisuje unikalne nazwy, zwane identyfikatorami CVE, do konkretnych błędów związanych z bezpieczeństwem, aby ułatwić jednoznaczne odniesienie się to konkretnego błędu. Więcej informacji znajduje się na stronie Wikipedii.
Q: Czy Debian wydaje komunikaty DSA dla każdego wpisu CVE?
A: Zespół ds. Bezpieczeństwa Debiana śledzi wszystkie wpisy CVE, sprawdza czy są one powiązane z pakietami i szacuje ich wpływ w kontekście Debiana - fakt, że jakiejś sprawie został przypisany identyfikator CVE nie musi oznaczać, że dany problem jest poważnym zagrożeniem w systemie Debian. Informacje są śledzone przy użyciu Debian Security Tracker, a dla problemów, które zostaną uznane za poważne, zostanie wydany odpowiedni komunikat DSA (Debian Security Advisory).
Problemy o niskiej ważności, które nie kwalifikują się do ogłoszenia DSA, mogą być poprawione w następnym wydaniu Debiana, w następnej aktualizacji bieżącej stabilnej lub przestarzałej dystrybucji lub być włączone do DSA, kiedy zostanie ono opublikowane dla poważniejszych zgłoszeń.
Q: Czy Debian może tworzyć identyfikatory CVE?
A: Ponieważ Debian ma status CVE Numbering Authority, może tworzyć identyfikatory które, zgodnie z plityką CVE, mogą dotyczyć tylko błędów jeszcze nieznanych. Aby otrzymać identyfikator do nieopisanego jeszcze błędu w oprogramowaniu w Debianie, należy skontaktować się z Zespołem ds. Bezpieczeństwa Debiana. W przypadku, gdy dany błąd został już opublikowany, zalecamy skorzystać z procedury opisanej w CVE OpenSource Request HOWTO.