VPN-APT-bron: wat die toekent en hoe je hem beperkt

Een VPN-client downloaden is een eenmalige beslissing; het APT-repository ervan toevoegen niet. Het tweede vertelt de pakketbeheerder waar toekomstige software vandaan mag komen, en dat is een blijvende overdracht van bevoegdheid in plaats van een download. Dat kan de juiste regeling zijn wanneer de leverancier een repository goed onderhoudt. Toch verdient het een bewuste beslissing, en de meeste installatiehandleidingen slaan het over.

Een handtekening authenticeert een archief, niet de code ervan

APT verifieert ondertekende repositorymetadata en vertrouwt vervolgens de controlesommen daarin voor de pakketten die het ophaalt. Dat bewijst dat het archief overeenkomt met wat de sleutelhouder publiceerde, en niets over de code erin. Een correct ondertekend pakket kan nog steeds onveilige maintainerscripts bevatten, en die scripts draaien als root terwijl het pakket wordt geïnstalleerd. De apt-secure-handleiding trekt precies deze grens tussen archiefauthenticatie en een beoordeling van de software.

De nuttige vraag is dus niet of de handtekening valideert, want een gebroken handtekening stopt de installatie toch. Het is wiens handtekening je vanaf nu kiest te vertrouwen. Een gestolen ondertekeningssleutel is erger dan een gestolen pakket, omdat de aanvaller nog lang geldige metadata blijft produceren na de eerste slechte release. Rotatie is de enige reparatie, en die hangt ervan af of de leverancier een nieuwe sleutel publiceert via een kanaal dat je onafhankelijk kunt verifiëren.

Daarom verdient de sleutelidentiteit evenveel aandacht als de URL van de repository. Een sleutel uit een adres in een oud forumannwoord bewijst niets over de uitgever, terwijl HTTPS het transport beschermt tot wie de telefoon beantwoordde. Transportbeveiliging en uitgeversidentiteit zijn aparte vragen, en alleen de eerste wordt door een certificaat opgelost.

Beperk de sleutel tot de bron, niet tot het systeem

Modern APT accepteert een bronspecifieke Signed-By-verwijzing. Een door de operator beheerde sleutel kan onder /etc/apt/keyrings/ staan, en de bronregel noemt de sleutel die dat archief mag authenticeren. Dat is smaller dan dezelfde sleutel in een wereldwijd vertrouwde set gooien, waar hij kan instaan voor bronnen die je nooit wilde toestaan. Volg de geïnstalleerde APT-versie en de actuele instructies van de leverancier in plaats van fragmenten uit verschillende generaties handleidingen te mengen.

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

Repareer een handtekeningsfout nooit door verificatie uit te schakelen of een onbekend archief als vertrouwd te markeren. Dat ruilt een zichtbare fout voor een onzichtbare, en de onzichtbare blijft tot iemand de bronnenlijst controleert. Als de sleutel niet past, is de juiste oplossing de juiste sleutel vinden, niet de controle verwijderen.

Haal de repositorygegevens en de sleutelidentiteit bij het project of bij een beheerde beheerder. Een sleutel die uit een blogpost is gekopieerd is een bewering over auteurschap, geen bewijs ervan. Wanneer een leverancier een rotatiekanaal publiceert, noteer het dan samen met de sleutel, want dat kanaal is wat de volgende rotatie mogelijk maakt.

Bronpinning is geen pakket-allowlist

Een sleutel tot één bron beperken beperkt welk archief hij kan authenticeren, niet welke pakketten dat archief mag publiceren. De repository kan veel meer leveren dan de gewenste VPN-client, en de kandidaatselectie en prioriteiten van APT bepalen welke geschikte versie wint. Bekijk de voorgestelde transactie voordat je hem bevestigt, inclusief de afhankelijkhedenlijst, want afhankelijkheden komen uit hetzelfde archief. Een sleutelbereik kan ’alleen dit pakket’ niet uitdrukken.

Heb je sterkere controle nodig, druk het dan uit als beleid over pakketnamen of -versies en houd dat beleid onder configuratiebeheer. Een transactie lezen kost een minuut; een onverwacht pakket zes maanden later ontdekken kost een beoordeling.

Onverwachte pakketten zijn het moment om te stoppen in plaats van door te gaan, en de vraag aan de archiefeigenaar is waarom ze nodig zijn. Een repository die een dozijn pakketten rond één client publiceert is normaal voor een leverancier die een desktopsuite levert. Het is ook een groter oppervlak dan de installatiehandleiding suggereerde, en dat is het deel dat het noteren waard is. Geen van beide uitkomsten is een reden om de handtekening te wantrouwen; beide zijn redenen om op te schrijven wat je hebt geaccepteerd.

Leg de bevoegdheid vast en hoe je die verwijdert

Schrijf de archiefeigenaar op, de ondersteunde besturingssysteemversie, het sleutelrotatiekanaal en de verwijderprocedure. Die vier feiten zijn wat een opvolger nodig heeft wanneer de client wordt uitgefaseerd of de leverancier zijn sleutel roteert. Zonder hen erft de volgende persoon een bronregel en een sleutelbestand zonder enig verhaal.

Verwijderen is de stap die wordt overgeslagen, dus schrijf die bij de installatie op. Verwijder de bronregel en de bijbehorende sleutel samen, en controleer of die sleutel elders wordt gebruikt voordat je het bestand weghaalt. Een gedeelde sleutel die zonder die controle wordt verwijderd, verandert een opruiming in een ongerelateerde storing, wat de slechtste uitkomst is voor een routinewijziging. Bevestig daarna dat gewone updates nog steeds oplossen als de regel weg is.

Eén ding blijft over nadat de repository is verwijderd: elk pakket dat er al uit is geïnstalleerd blijft draaien tot iets het vervangt. De eerlijke vraag is welke bevoegdheid je hebt toegevoegd, en hoe nauw de rol ervan was uitgedrukt.