Advarsel! Denne oversættelse er for gammel, benyt venligst originalen.

Debians sikkerheds-OSS

Jeg modtog en DSA-mail via debian-security-announce, hvordan opgraderer jeg de sårbare pakker?
Signaturen på jeres bulletiner kan ikke verificeres korrekt!
Hvordan håndteres sikkerhed i Debian?
Hvorfor roder i med en gammel version af den pakke?
En pakkes versionsnummer indikerer at jeg stadig kører med den sårbare version!
Jeg har modtaget en bulletin, men der lader til at mangle en opbygning til en processorarkitektur.
Hvordan håndteres sikkerhed i unstable?
Hvordan håndteres sikkerhed i testing?
Hvordan håndteres sikkerhed vedr. contrib og non-free?
Bulletinen siger at unstable er rettet i version 1.2.3-1, men unstable har 1.2.5-1, hvorfor?
Hvorfor har security.debian.org ingen officielle filspejle?
Jeg har set DSA 100 og DSA 102, men hvor er DSA 101?
Hvordan kontakter jeg sikkerhedsteamet?
Jeg har vist fundet et sikkerhedsproblem, hvad gør jeg?
Hvad skal jeg gøre ved et sikkerhedsproblem i en af mine pakker?
Jeg prøvede at hente en pakket listet i et af jeres sikkerhedsbulletiner, men fik fejlmeddelelsen filen findes ikke.
Jeg har en fejlrettelse, kan jeg uploade direkte til security.debian.org?
Jeg har en fejlrettelse, kan jeg uploade den til proposed-updates i stedet?
Jeg er ret sikker på at mine pakker er i orden, hvordan uploader jeg dem?
Hvordan kan jeg hjælpe med sikkerhed?
Hvad er omfanget af proposed-updates?
Hvem består sikkerhedsteamet af?
I hvor lang tid vil sikkerhedsopdateringer blive stillet til rådighed?
Hvordan kontrollerer jeg en pakkes integritet?
Hvad gør jeg hvis en tilfældig pakke holder op med at virke efter en sikkerhedsopdatering?
Hvad er en CVE-identifikation?
Udgiver Debian en DSA for hver CVE-id?
Kan Debian tildele CVE-identifikationer?
Har Debian en regel om at offentliggøre sårbarheder?
Hvad betyder lokal (fjern)?

Sp: Jeg modtog en DSA-mail via debian-security-announce, hvordan opgraderer jeg de sårbare pakker?

Sv: Som DSA-mailen siger, bør du opgradere de pakker, som er påvirket af den offentliggjorte sårbarhed. Det kan du gøre ved blot at opgradere (efter at have opdateret listen over tilgængelige pakker med apt-get update) alle pakker på dit system med apt-get upgrade eller ved at opgradere kun en bestemt pakke med apt-get install pakkenavn.

Annonceringsmailen nævner kildekodepakken, hvori sårbarheden blev fundet. Derfor bør du opgradere alle de binære pakker, som dannes ud fra den pågældende kildekodepakke. For at finde ud af hvilke binære pakker, der skal opdateres, kan du besøge https://packages.debian.org/src:kildekodepakkenavn og dér vælge [show ... binary packages] ([vis ... binære pakker]) ud for den distribution, du opdaterer.

Det kan også være nødvendigt at genstarte en tjeneste eller kørende proces. Kommandoen checkrestart, som installeres via pakken debian-goodies, kan være en hjælp til at finde ud af hvilke, det drejer sig om.

Sp: Signaturen på jeres bulletiner kan ikke verificeres korrekt!

Sv: Dette skyldes højst sandsynligt et problem hos dig. Der er et filter på postlisten debian-security-announce, der gør at kun breve med en korrekt signatur fra medlemmerne af sikkerhedsteamet kan udsendes.

Sandsynligvis ændrer et postprogram hos dig brevene en smule og ødelægger dermed signaturen. Sørg for at dit postprogram ikke foretager nogen form for ind- eller udpakning med MIME, eller konverterer tabulerings- eller mellemrumstegn.

Kendte syndere er fetchmail (med mimedecode-indstillingen slået til) og formail (kun fra procmail 3.14) og evolution.

Sp: Hvordan håndteres sikkerhed i Debian?

Sv: Når sikkerhedsteamet har modtaget besked om en hændelse, kigger et eller flere medlemmer den igennem og overvejer hvad det betyder for den stabile udgivelse af Debian (med andre ord om den er sårbar eller ej). Hvis vores system er sårbart, vil vi gå i gang med at fremstille en rettelse til problemet. Pakkevedligeholderen kontaktes også, hvis vedkommende ikke allerede har kontaktet sikkerhedsteamet. Slutteligt testes rettelsen og der forberedes nye pakker, som kompiles på alle stabile arkitekturer og dernæst uploades. Når alt det er gjort udsendes et sikkerhedsbulletin.

Sp: Hvorfor roder i med en gammel version af den pakke?

Sv: Den vigtigste retningslinie når man laver en ny pakker som retter et sikkerhedsproblem, er at foretage så få ændringer som muligt. Vore brugere og udviklere er afhængige af at en udgave opfører sig på en bestemt måde, når den er udgivet, så enhver ændring vi foretager kan måske få en eller andens system til at holde op med at virke. Dette især noget som sker i forbindelse med biblioteker: sørg for aldrig at ændre et biblioteks Application Program Interface (API) eller dets Application Binary Interface (ABI), uanset hvor lille ændringen end måtte være.

Dette betyder at et skifte til en ny opstrømsversion ikke er en god løsning, i stedet bør de relevante ændringer føres tilbage. Generelt er opstrømsvedligeholdere villige til at hjælpe om nødvendigt, hvis ikke kan Debians sikkerhedsteam måske hjælpe.

I nogle tilfælde er det ikke muligt at tilbageføre en sikkerhedsrettelse, for eksempel når store mængder kildekode skal ændres eller omskrives. Hvis det sker, er det måske nødvendigt at skifte til en ny opstrømsversion, men det skal koordineres med sikkerhedsteamet på forhånd.

Sp: En pakkes versionsnummer indikerer at jeg stadig kører med den sårbare version!

Sv: I stedet for at opgradere til en ny version, fører vi fejlrettelser tilbage til den version som var indeholdt i den stabile udgivelse. Vi gør det for at sikre os at en ny version ændrer så lidt som muligt, så ting ikke uventet ændrer sig eller holder op med at virke på grund af en sikkerhedsrettelse. Du kan finde ud af om du kører en sikker version af en pakke, ved at kigge i pakkens ændringslog (changelog), eller ved at sammenligne dens præcise versionsnummer med den version som er angivet i Debians sikkerhedsbulletin.

Sp: Jeg har modtaget en bulletin, men der lader til at mangle en opbygning til en processorarkitektur.

Sv: Generelt udgiver Sikkerhedsholdet en bulletin med opbygninger af de opdaterede pakker til alle arkitekturer, som Debian understøtter. Dog er nogle arkitekturer langsommere end andre og der kan forekomme situationer hvor opbygningerne til de fleste arkitekturer er klar, mens nogle stadig mangler. Disse mindre arkitekturer repræsenterer en lille del af alle vores brugere. Afhængigt af et problems vigtighed, kan vi beslutte at frigive en bulletin med det samme. De manglende opbygninger vil blive stillet til rådighed så snart de bliver tilgængelige, men der vil ikke blive informeret yderligere herom. Selvfølgelig vil vi aldrig udgive en bulletin, hvor opbygningerne til i386 eller amd64 ikke er til stede.

Sp: Hvordan håndteres sikkerhed i unstable?

Sv: Sikkerhed i unstable håndteres primært af pakkevedligeholderne, ikke af Debian Security Team. Dog kan sikkerhedsholdet uploade meget vigtige opdateringer kun indholdende sikkerhedsrettelser, når der bemærkes at en vedligeholder ikke er aktiv, men understøttelse af stable har altid den højeste prioritet. Ønsker man have have en sikker (og stabil) server, opfordres man kraftigt til at benytte stable.

Sp: Hvordan håndteres sikkerhed i testing?

Sv: Sikkerhed i testing drager nytte af hele projektets sikkerhedsarbejde i unstable. Dog vil der som minimum være en migreringsforsinkelse på to dage, og nogle gange kan sikkerhedsrettelser blive forsinket af transitioner. Security Team hjælper med at få fremdrift i de transitioner, som forsinker vigtige sikkerhedsuploads, men det er ikke altid muligt og forsinkelser kan opstå. Særligt i månederne efter en ny udgivelse af stable, hvor mange nye versioner uploades til unstable, kan sikkerhedsrettelser til testing halte bagefter. Ønsker man have have en sikker (og stabil) server, opfordres man kraftigt til at benytte stable.

Sp: Hvordan håndteres sikkerhed vedr. contrib og non-free?

Sv: Det korte svar er: Det håndteres ikke. Contrib og non-free er ikke officielle dele af Debian-distributionen og udgives ikke, og derfor understøttes de ikke af sikkerhedsteamet. Nogle pakker i non-free distribueres uden kildekode eller uden en licens, der tillader distribution af ændrede udgaver. I disse tilfælde kan der slet ikke foretages sikkerhedsrettelser. Hvis det er muligt at rette problemet og pakkevedligeholderen eller en anden leverer korrekt opdaterede pakker, så vil sikkerhedsteamet generelt behandler dem og udsende en bulletin.

Sp: Bulletinen siger at unstable er rettet i version 1.2.3-1, men unstable har 1.2.5-1, hvorfor?

Sv: Vi forsøger at angive den første version i unstable, hvor problemet var løst. Nogle gange har vedligeholderen i mellemtiden uploadet en endnu nyere version. Sammenlign versionen i unstable med det nummer, vi angiver. Hvis det er det samme eller højere, skulle du være beskyttet mod den pågældende sårbarhed. Hvis du vil være sikker, kan du kontrollere pakkens changelog med apt-get changelog pakkenavn og kigge efter den forekomst, som fortæller om rettelsen.

Sp: Hvorfor har security.debian.org ingen officielle filspejle?

Sv: Det er der faktisk. Der er flere officielle filspejle implementeret gennem DNS-aliaser. Formålet med security.debian.org er at gøre sikkerhedsopdateringer tilgængelige så hurtigt og nemt som muligt.

Opfordring til anvendelse af uofficielle filspejle vil medføre ekstra kompleksitet som normalt ikke er nødvendig og kan give frustrationer hvis disse filspejle ikke holdes ajour.

Sp: Jeg har set DSA 100 og DSA 102, men hvor er DSA 101?

Sv: Flere leverandører (primært af GNU/Linux, men også af BSD-varianter) koordinerer sikkerhedsbulletiner i forbindelse med visse hændelser og er blevet enige om en bestemt tidsplan, så alle leverandørne er i stand til samtidig at udsende et bulletin. Det har man besluttet for ikke at diskriminere nogle leverandører, som har brug for mere tid (for eksempel hvis leverandøren først skal have pakkerne igennem nogle længere kvalitetskontroller eller hvis der understøttes flere arkitekturer eller binære distributioner). Vores eget sikkerhedsteam gør også bulletiner klar på forhånd. Ind i mellem er andre sikkerhedsproblemer blevet løst før det afventende bulletin kan udsendes, og dermed opstår der midlertidigt huller i rækkefølgen.

Sp: Hvordan kontakter jeg sikkerhedsteamet?

Sv: Sikkerhedsoplysninger kan sendes til security@debian.org eller team@security.debian.org, som begge læses af medlemmer af sikkerhedsteamet.

Eventuelt kan du kryptere din e-mail med Debians sikkerhedskontaktnøgle (nøgle-id 0x0D59D2B15144766A14D241C66BAF400B05C3E651). De individuelle teammedlemmers PGP-/GPG-nøgler kan ses på nøgleserveren keyring.debian.org.

Sp: Jeg har vist fundet et sikkerhedsproblem, hvad gør jeg?

Sv: Hvis du bliver opmærksom på et sikkerhedsproblem, enten i en af dine egne pakker eller i en andens, så kontakt venligst altid sikkerhedsteamet. Hvis Debians sikkerhedsteam bekræfter sårbarheden og andre leverandører også formodes at være sårbare, vil teamet normalt også kontakte andre leverandører. Hvis sårbarheden endnu ikke er offentligt kendt, vil teamet prøvet at koordinere sikkerhedsbulletinerne med de andre leverandører, så alle store distributioner reagerer samtidig.

Hvis sårbarheden allerede er offentlig kendt, så sørg for at indsende en fejlrapport til Debians fejlsporingssystem og giv den mærket security.

Hvis du er Debian-udvikler, så se nedenfor.

Sp: Hvad skal jeg gøre ved et sikkerhedsproblem i en af mine pakker?

Sv: Hvis du bliver opmærksom på et sikkerhedsproblem, enten i dine pakker eller i en andens, så kontakt altid sikkerhedsteamet via engelsksproget e-mail til adressen team@security.debian.org. De holder styr på sikkerhedsproblemer som ikke er løst, kan hjælpe vedligeholdere med sikkerhedsproblemer eller selv rette problemer, de er ansvarlige for at udsende sikkerhedsbulletiner og vedligeholde security.debian.org.

Udviklernes opslagsbog indeholder udførlige oplysninger om hvad der skal gøres.

Det er specielt vigtigt at du ikke uploader til andre distributioner, end unstable, uden forudgående aftale med sikkerhedsteamet, fordi det vil skabe forvirring og mere arbejde, at gå udenom sikkerhedsteamet.

Sp: Jeg prøvede at hente en pakket listet i et af jeres sikkerhedsbulletiner, men fik fejlmeddelelsen filen findes ikke.

Sv: Når en nyere fejlrettelse erstatter en ældre pakke på security.debian.org, er der stor sandsynlighed for at den gamle pakke vil blive fjernet samtidig med at den nye installeres. Derfor vil du få fejlmeddelelsen filen findes ikke. Vi ønsker ikke distribuere pakker med kendte sikkerhedsfejl længere end absolut nødvendigt.

Benyt venligst pakkerne fra de seneste sikkerhedsbulletiner, som distribueres gennem postlisten debian-security-announce. Det er bedst blot at køre apt-get update før pakken opgraderes.

Sp: Jeg har en fejlrettelse, kan jeg uploade direkte til security.debian.org?

Sv: Nej, det kan du ikke. Arkivet på security.debian.org vedligeholdes af sikkerhedsteamet, som skal godkende alle pakker. Du skal i stedet sende dine rettelser (patches) eller kildekode-pakker til sikkerhedsteamet til team@security.debian.org. De vil blive gennemgået af sikkerhedsteamet og slutteligt uploadet, enten med eller uden rettelser.

Udviklernes opslagsbog indeholder udførlige oplysninger om hvad der skal gøres.

En måde måde at komme i gang med sikkerhedsarbejde på, er at hjælpe til på Debians Security Tracker (vejledning).

Sp: Jeg har en fejlrettelse, kan jeg uploade den til proposed-updates i stedet?

Sv: Rent teknisk kan du godt. Men du bør ikke gøre det, da påvirker sikkerhedsteamets arbejde i høj grad. Pakker fra security.debian.org bliver automatisk kopieret til mappen proposed-updates. Hvis en pakke med det samme eller et højere versionsnummer allerede er overført til arkivet, vil sikkerhedsopdateringen blive afvist af arkivsystemet. På den måde vil den stabile distribution ende med, i stedet at mangle denne sikkerhedsopdatering, med mindre den forkerte pakke i mappen proposed-updates blev afvist. Kontakt venligst sikkerhedsteamet i stedet, vedlæg alle oplysninger om sårbarheden og vedhæft kildekoden (dvs. diff.gz- og dsc-filer) til din mail.

Udviklernes opslagsbog indeholder udførlige oplysninger om hvad der skal gøres.

Sp: Jeg er ret sikker på at mine pakker er i orden, hvordan uploader jeg dem?

Hvis du er meget sikker på at du dine pakker ikke ødelægger noget, at versionsnummeret er fornuftigt (dvs. større end versionsnummeret i stable og mindre end versionsnummeret i testing/unstable), at du ikke har ændret på hvordan pakken opfører sig, på trods af det tilsvarede sikkerhedsproblem, og at du har oversat pakken til den rigtige distribution (dvs. oldstable-security eller stable-security), at pakken indeholder den originale kildekode hvis den er ny på security.debian.org, at du kan bekræfte at rettelsen (patch'en) er i orden ved at kontrollere den mod den seneste version og at der kun rørers ved det pågældende sikkerhedsproblem (kontroller med interdiff -z og begge .diff.gz-filerne), at du har gennemgået rettelsen mindst tre gange, og at debdiff ikke viser nogen ændringer, kan du overføre filerne direkte til mappen incoming ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue på security.debian.org. Send også en besked med alle oplysninger til team@security.debian.org.

Sp: Hvordan kan jeg hjælpe med sikkerhed?

Sv: Gennemgå hvert problem før du rapporterer det til secturity@debian.org. Hvis du har mulighed for at levere rettelser, så vil det gøre processen hurtigere. Videresend ikke bare e-mails fra bugtraq, dem modtager vi allerede — men giv gerne flere oplysninger om ting der rapporteres på bugtraq.

Sp: Hvad er omfanget af proposed-updates?

Sv: Denne mappe indeholder pakker som det er forslået skal med i den næste revision af den stabile Debian-distribution (stable). Når en pakke bliver uploadet af en vedligeholder, til den stabile distribution, havner de i mappen proposed-updates. Da stable skal være stabil, sker der ingen automatiske opdateringer. Sikkerhedsteamet uploader rettede pakker nævnt i deres sikkerhedsbulletiner til stable, men pakkerne vil først blive placeret i proposed-updates. Med nogle måneders mellemrum gennemgår den ansvarlige for den stabile udgivelse listen over pakker i proposed-updates og diskuterer hvorvidt en pakke er egnet til stable eller ej. Dette bliver til en ny udgivelse af Debians stabile distribution (f.eks. 2.2r3 eller 2.2r4). Pakker som ikke opfylder kriterierne, vil formentlig blive afvist og også fjernet fra proposed-updates.

Bemærk, at pakker uploadet af vedligeholdere (ikke sikkerhedsteamet) til mappen proposed-updates/ ikke understøttes af sikkerhedsteamet.

Sp: Hvem består sikkerhedsteamet af?

Sv: Debians sikkerhedsteam består af flere medlemmer og sekretærer. Sikkerhedsteamet udpeger selv folk til at deltage i teamet.

Sp: I hvor lang tid vil sikkerhedsopdateringer blive stillet til rådighed?

Sv: Sikkerhedsteamet prøver at understøtte en stabil distribution et års tid efter den næste stabile distribution er blevet udgivet, bortset fra når en anden stabile distribution udgives indenfor det samme år. Det er ikke muligt at understøtte tre distributioner; det er svært nok at understøtte to distributioner på samme tid.

Sp: Hvordan kontrollerer jeg en pakkes integritet?

Sv: Det kræver at man kontrollerer Release-filens signatur mod den offentlige nøgle som anvendes i forbindelse med arkivet. Release-filen indeholder kontrolsummer for filerne Packages og Sources, der indeholder kontrolsummer hørende til binære og kildekodepakker. For udførlige oplysninger om hvordan man kontrollerer en pakkes integritet, se Debians sikkerhedshåndbog.

Sp: Hvad gør jeg hvis en tilfældig pakke holder op med at virke efter en sikkerhedsopdatering?

Sv: Først og fremmest skal du finde ud af hvorfor pakken ikke længere virker og hvordan det hænger sammen med sikkerhedsopdateringen, dernæst kontaktes sikkerhedsteamet hvis problemet er alvorligt eller den stabile udgaves udgivelsesansvarlige hvis det er mindre alvorligt. Dette gælder hvis en tilfældig pakke holder op med at virke efter en anden pakke er blevet sikkerhedsopdateret. Hvis du ikke finde ud af hvad der går galt, men har en rettelse, så kontaktes sikkerhedsteamet også. De kan dog sende forespørgslen videre til den stabile udgaves udgivelsesansvarlige.

Sp: Hvad er en CVE-identifikation?

Sv: Projektet Common Vulnerabilities and Exposures tildeler unikke navne, kaldet CVE-identifikationer, til specifikke sikkerhedssårbarheder, for at gøre det lettere, unikt at referere til et specifikt problem. Flere oplysninger finder man i Wikipedia.

Sp: Udgiver Debian en DSA for hver CVE-id?

Sv: Debians Security Team holder styr på alle udgivne CVE-identifikationer, forbinder dem med de relevante Debian-pakker og vurderer indvirkningen i en Debian-sammenhæng - det faktum, at noget er blevet tildelt en CVE-id, betyder ikke nødvendigvis, at problemet er en alvorlig trussel mod et Debian-system. Oplysningen spores i Debian Security Tracker, og hvad angår problemer, som anses for at være alvorlige, vil et Debian Security Advisory blive udgivet.

Problemer med lav indvirkning, som ikke er kvalificeret til et DSA, kan blive rettet i den næste Debian-udgivelse, i en punktopdatering til den aktuelle stabile eller gamle stabile distribution eller medtages i en DSA, hvis en sådan udgives vedrørende en mere alvorlig sårbarhed.

Sp: Kan Debian tildele CVE-identifikationer?

Sv: Debian er en CVE Numbering Authority og kan tildele id'er, men jævnfør CVE's retningslinjer kan det kun ske angående endnu ikke offentliggjorte problemer. Hvis man har kendskab til en endnu ikke offentliggjort sikkerhedssårbarhed i software i Debian, og ønsker at få tildelt en identifikation dertil, så kontakt Debians Security Team. I fald sårbarheden allerede er offentliggjort, anbefaler vi at man følger proceduren beskrevet i CVE OpenSource Request HOWTO.

Sp: Har Debian en regel om at offentliggøre sårbarheder?

Sv: Debian har udgivet et regelsæt for offentliggørelse af sårbarheder, som en del af deltagelsen i CVE-projektet.

Udgåede spørgsmål og svar til sikkerhed i Debian

Sp: Hvad betyder lokal (fjern)?

Sv: Nogle bulletiner beskriver sårbarheder som ikke kan identificeres inden for rammerne af den klassiske opdeling mellem lokale og fjerne udnyttelser. Nogle sårbarheder kan ikke fjernudnyttes, eksempelvis hvis de ikke svarer til en dæmon, som lytter til en netværksport. Hvis de kan udnyttes af særlige filer, der leveres via netværket mens den sårbare service ikke er permanent forbundet med netværket, skriver vi lokal (fjern) (eller på engelsk local (remote)).

Sådanne sårbarheder ligger nærmest mellem lokale og fjerne sårbarheder, og dækker ofte arkiver, der kan leveres via netværket, fx som vedhæftelser til e-mail eller hentes fra en webside.