Ubuntu Manpage: apt-secure - Ondersteuning in APT voor de authenticatie van archieven

NAME

       apt-secure - Ondersteuning in APT voor de authenticatie van archieven

OMSCHRIJVING

       Met ingang van versie 0.6 bevat APT code die voor alle pakketbronnen de ondertekening controleert van het
       bestand Release. Dit geeft de garantie dat gegevens uit het archief, zoals pakketten, niet gewijzigd
       kunnen worden door mensen die geen toegang hebben tot de sleutel waarmee het bestand Release ondertekend
       wordt. Met ingang van versie 1.1 vereist APT dat pakketbronnen recente authenticatie-informatie
       verstrekken om die pakketbron ongehinderd te kunnen gebruiken. Met ingang van versie 1.5 moet gewijzigde
       informatie over de pakketbron in het bestand Release bevestigd worden, vooraleer APT voortgaat met het
       toepassen van updates die uit die pakketbron afkomstig zijn.

       Opmerking: Alle op APT gebaseerde front-ends voor pakketbeheer, zoals apt-get(8), aptitude(8) en
       synaptic(8), ondersteunen deze authenticatiefunctionaliteit. Het is enkel om het eenvoudig te houden dat
       deze man-pagina van APT gebruikt wordt om die functionaliteit aan ze allemaal toe te schrijven.

CONFIGURATIE OP GEBRUIKERSNIVEAU

Sleutels moeten doorgaans worden opgenomen in hun corresponderende .sources door de ASCII-gepantserde
sleutel in de optie Signed-By op te nemen. Vervang hiervoor de lege regel door een punt en laat
vervolgens alle regels met twee spaties inspringen. Zie sources.list(5) voor meer informatie.

Als alternatief kunnen sleutels worden geplaatst in /etc/apt/keyrings voor lokale sleutels, of
/usr/share/keyrings voor sleutels die worden beheerd door pakketten, en vervolgens kan er naar worden
verwezen via de optie Signed-By: /etc/apt/keyrings/example-archive-keyring.asc in een .sources-bestand of
via deb [signed-by=/etc/apt/keyrings/example-archive-keyring.asc] ... te gebruiken in de oude
.list-indeling. Dit kan handig zijn voor vroegere APT-versies dan 2.4, die geen ingesloten sleutels
ondersteunen. ASCII-gepantserde sleutels moeten een extensie .asc gebruiken, en niet-gepantserde sleutels
een extensie .gpg.

Om sleutels te genereren die geschikt zijn voor gebruik in APT met GnuPG, moet u de opdracht gpg
--export-options export-minimal [--armor] --export gebruiken. Eerdere oplossingen met --keyring file
--import werken niet meer met recente GnuPG-versies, omdat deze een nieuwe interne indeling ("GPG keybox
database") gebruiken.

Merk op dat een standaardinstallatie reeds alle nodige sleutels bevat om op een veilige manier pakketten
op te halen uit de standaard pakketbronnen. Het beheren van sleutels is dus alleen nodig als er externe
pakketbronnen worden toegevoegd. Het pakket extrepo kan worden gebruikt om meerdere externe pakketbronnen
eenvoudig te beheren.

NIET-ONDERTEKENDE PAKKETBRONNEN

       Indien een archief een niet-ondertekend Release-bestand of helemaal geen Release-bestand heeft, zullen
       alle hedendaagse versies van APT bij update-operaties standaard weigeren om er gegevens van op te halen.
       En zelfs als ze tot ophalen verplicht worden, zullen frontends, zoals apt-get(8), om een expliciete
       bevestiging vragen als bij een installatieverzoek een pakket uit een dergelijk niet-geauthenticeerd
       archief betrokken is.

       U kunt alle APT-clients verplichten om enkel waarschuwingen te geven door de configuratie-optie
       Acquire::AllowInsecureRepositories op true in te stellen. U kunt ook individuele pakketbronnen toelaten
       om onveilig te zijn via de optie allow-insecure=yes in sources.list(5). Merk op dat onveilige
       pakketbronnen ten stelligste afgeraden worden en dat alle opties die apt verplichten om deze te blijven
       ondersteunen, uiteindelijk verwijderd zullen worden. Gebruikers beschikken ook over de optie Trusted,
       waardoor zelfs de waarschuwingen onderdrukt worden, maar u moet zeker zijn dat u de implicaties ervan
       begrijpt die uitgelegd worden in sources.list(5).

       Een pakketbron die zijn eerdere authenticatie-status zou kwijt spelen zal in geval van een
       update-operatie bij alle APT-clients een foutmelding opleveren, ongeacht het feit of een optie het
       gebruik van onveilige pakketbronnen toestaat of verbiedt. Een dergelijke fout kan voorkomen worden door
       bijkomend de optie Acquire::AllowDowngradeToInsecureRepositories op true in te stellen of voor
       individuele pakketbronnen door de optie allow-downgrade-to-insecure=yes te gebruiken in sources.list(5).

ONDERTEKENDE PAKKETBRONNEN

De vertrouwensketen vanaf een APT-archief tot de eindgebruiker, bestaat uit verschillende schakels.
apt-secure is de laatste schakel in die keten. Een archief vertrouwen betekent niet dat u er op vertrouwt
dat zijn pakketten geen kwaadwillige code bevatten, maar betekent wel dat u de beheerder van het archief
vertrouwt. Het behoort tot de verantwoordelijkheid van de archiefbeheerder om er voor te zorgen dat de
integriteit van het archief gevrijwaard blijft.

apt-secure controleert geen handtekeningen op pakketniveau. Indien u gereedschap nodig heeft om dit te
doen, moet u uitkijken naar debsig-verify en debsign (die respectievelijk in de pakketten debsig-verify
en devscripts te vinden zijn).

De vertrouwensketen in Debian begint (bijvoorbeeld) wanneer een pakketonderhouder een nieuw pakket of een
nieuwe versie ervan naar het Debian archief uploadt. Om effectief te worden moet deze upload ondertekend
worden met een sleutel uit de sleutelbos van de pakketonderhouders van Debian (te vinden in het pakket
debian-keyring). De sleutels van onderhouders worden door andere onderhouders ondertekend. Daarbij worden
vaststaande procedures gevolgd om de identiteit van de sleuteleigenaar te kunnen garanderen.
Vergelijkbare procedures worden in alle op Debian gebaseerde distributies gehanteerd.

Nadat het geüpload pakket geverifieerd werd en toegevoegd aan het archief, wordt de handtekening van de
onderhouder verwijderd en wordt de controlesom voor dat pakket berekend en in het bestand Packages
opgeslagen. Daarna wordt voor alle Packages-bestanden de controlesom berekend en opgeslagen in het
bestand Release. Daarna wordt het bestand Release ondertekend door de archiefsleutel voor deze Ubuntu
release en verdeeld met de pakketten en de Packages-bestanden naar de Ubuntu-spiegelservers. De sleutels
bevinden zich in de sleutelbos van het Ubuntu-archief die te vinden is in het pakket ubuntu-keyring.

Eindgebruikers kunnen de ondertekening van het bestand Release controleren, er de controlesom voor een
pakket uithalen en die vergelijken met de controlesom van het pakket dat ze handmatig gedownload hebben -
of vertrouwen op APT die dit automatisch doet.

Merk op dat dit niet hetzelfde is als een controle van handtekeningen op het niveau van individuele
pakketten. Deze werkwijze is ontworpen om twee mogelijke aanvallen te voorkomen:

• Netwerkaanval van het type "man-in-the-middle". Zonder de controle van de ondertekening kunnen
kwaadwillige personen binnendringen in het proces van het downloaden van pakketten en kwaadaardige
software verspreiden. Dit kunnen ze doen via het verwerven van controle over een element van het
netwerk (router, switch, enz.) of via het omleiden van trafiek naar een kwaadaardige server (via ARP
of aanvallen van DNS-spoofing).

• Gecompromitteerd spiegelservernetwerk. Zonder de controle van handtekeningen kan een kwaadwillige
persoon een spiegelserver binnendringen en de bestanden die er zich op bevinden wijzigen, om op die
manier kwaadaardige software te verspreiden naar alle gebruikers die pakketten van die server
downloaden.

Ze biedt evenwel geen bescherming tegen een aanval gericht tegen de hoofdserver van Debian (die de
pakketten ondertekent) of tegen een aanval gericht tegen de sleutel die gebruikt wordt om de
Release-bestanden te ondertekenen. In elk geval biedt dit mechanisme wel een aanvulling op een
ondertekening op pakketniveau.

INFORMATIEWIJZIGINGEN

       Het bestand Release bevat behalve de checksums voor de bestanden uit de pakketbron, ook algemene
       informatie over de pakketbron, zoals origine, codenaam en versienummer van de release.

       Deze informatie wordt op verschillende plaatsen weergegeven en dus zou de eigenaar van een pakketbron
       altijd de juistheid ervan moeten garanderen. Daarenboven kan gebruikersconfiguratie, zoals
       apt_preferences(5), van deze informatie gebruik maken en er afhankelijk van zijn. Daarom moet de
       gebruiker met ingang van versie 1.5 wijzigingen expliciet bevestigen, om te signaleren dat deze voldoende
       voorbereid is op bijvoorbeeld de nieuwe hoofdrelease van de distributie (bijvoorbeeld aangeduid met de
       codenaam) die door de pakketbron verdeeld wordt.

CONFIGURATIE VAN DE PAKKETBRON

Indien u voor een door u onderhouden archief in een ondertekening van het archief wilt voorzien, moet u
het volgende doen:

• Maak een Release-bestand aan voor het hoofdniveau als dit nog niet bestaat. U kunt dit doen met de
opdracht apt-ftparchive release (uit het pakket apt-utils).

• Onderteken het. U doet dit door het uitvoeren van de commando's gpg --clearsign -o InRelease Release
en gpg -abs -o Release.gpg Release.

• Maak de vingerafdruk van de sleutel openbaar, zodat uw gebruikers weten welke sleutel ze moeten
importeren om de bestanden uit het archief te authenticeren. U doet er best aan uw sleutel te
verspreiden via een eigen sleutelbospakket, zoals Ubuntu doet met ubuntu-keyring. Op die manier
kunnen later updates en transities van sleutels automatisch gedistribueerd worden.

• Geef de nodige instructies voor het toevoegen van uw archief en uw sleutel. Indien uw gebruikers niet
op een veilige manier uw sleutel kunnen bekomen, wordt de hierboven beschreven vertrouwensketen
verbroken. Hoe u gebruikers kunt helpen om uw sleutel toe te voegen, hangt af van uw archief en het
doelpubliek. Dit kan gaan van het toevoegen van uw sleutelbospakket aan een ander archief dat de
gebruikers reeds geconfigureerd hebben (zoals de standaard pakketbronnen van hun distributie) tot het
gebruik maken van het web van vertrouwen.

Telkens de inhoud van het archief wijzigt (als nieuwe pakketten toegevoegd of verwijderd worden) moet de
archiefverantwoordelijke de hierboven beschreven eerste twee stappen hernemen.

ZIE OOK

       apt.conf(5), apt-get(8), sources.list(5), apt-ftparchive(1), debsign(1), debsig-verify(1), gpg(1)

       Voor bijkomende achtergrondinformatie kunt u het hoofdstuk raadplegen over de beveiligingsinfrastructuur
       van Debian, Debian Security Infrastructure[1], uit de Securing Debian Manual (ook te vinden in het pakket
       harden-doc), alsook de Strong Distribution HOWTO[2] door V. Alex Brennen.

BUGS

       APT bugpagina[3]. Indien u een bug in APT wilt rapporteren, raadpleeg dan
       /usr/share/doc/debian/bug-reporting.txt of het reportbug(1) commando.

AUTEUR

       APT werd geschreven door het APT-team <apt@packages.debian.org>.

AUTEURS VAN DE MAN-PAGINA

       Deze man-pagina is gebaseerd op het werk van Javier Fernández-Sanguino Peña, Isaac Jones, Colin Walters,
       Florian Weimer en Michael Vogt.

VERTALING

       De Nederlandse vertaling werd in 2015 gemaakt door Frans Spiesschaert <Frans.Spiesschaert@yucom.be>, in
       samenwerking met het Debian Dutch l10n Team <debian-l10n-dutch@lists.debian.org>.

       Merk op dat de vertaling van dit document nog onvertaalde delen kan bevatten. Dit is intentioneel om te
       vermijden dat inhoud verloren zou gaan door een vertaling die achterop loopt op het origineel.

AUTEURS

       Jason Gunthorpe

       APT-team

OPMERKINGEN

        1. Debian Security Infrastructure
           https://www.debian.org/doc/manuals/securing-debian-manual/ch07

        2. Strong Distribution HOWTO
           http://www.cryptnet.net/fdp/crypto/strong_distro.html

        3. APT bugpagina
           https://bugs.debian.org/src:apt

APT 3.1.3                                       23 november 2024                                   APT-SECURE(8)