Sorgente APT VPN: cosa concede e come limitarla

Scaricare un client VPN è una decisione una tantum; aggiungere il suo repository APT non lo è. Il secondo dice al gestore dei pacchetti da dove potrà arrivare software futuro, e si tratta di un trasferimento permanente di autorità, non di un download. Può essere l’accordo giusto quando il fornitore mantiene correttamente un repository. Merita comunque una decisione consapevole, e la maggior parte delle guide all’installazione la salta.

Una firma autentica un archivio, non il suo codice

APT verifica i metadati firmati del repository e poi si fida dei checksum al loro interno per i pacchetti che scarica. Ciò dimostra che l’archivio corrisponde a quanto pubblicato dal titolare della chiave, e nulla sul codice che contiene. Un pacchetto firmato correttamente può comunque portare script di manutenzione non sicuri, e quegli script vengono eseguiti come root durante l’installazione del pacchetto. Il manuale apt-secure traccia esattamente questa linea tra l’autenticazione dell’archivio e una revisione del software.

Dunque la domanda utile non è se la firma sia valida, perché una firma rotta ferma comunque l’installazione. È a quale firma scegli di affidarti da ora in poi. Una chiave di firma rubata è peggio di un pacchetto rubato, perché l’attaccante continua a produrre metadati validi molto dopo la prima versione cattiva. La rotazione è l’unica riparazione, e dipende dal fatto che il fornitore pubblichi una nuova chiave tramite un canale che puoi verificare in modo indipendente.

Per questo l’identità della chiave merita tanta attenzione quanto l’URL del repository. Una chiave presa da un indirizzo in una vecchia risposta di un forum non stabilisce nulla sull’editore, mentre HTTPS protegge il trasporto fino a chi ha risposto al telefono. Sicurezza del trasporto e identità dell’editore sono questioni separate, e solo la prima si risolve con un certificato.

Limita la chiave alla sorgente, non al sistema

L’APT moderno accetta un riferimento Signed-By specifico della sorgente. Una chiave gestita dall’operatore può risiedere sotto /etc/apt/keyrings/, e la voce della sorgente nomina la chiave che può autenticare quell’archivio. È più stretto che gettare la stessa chiave in un insieme fidato globale, dove può garantire per sorgenti che non hai mai voluto consentire. Segui la versione di APT installata e le istruzioni attuali del fornitore invece di mescolare frammenti di generazioni diverse di guide.

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

Non riparare mai un errore di firma disattivando la verifica o marcando come attendibile un archivio sconosciuto. Si scambia un errore visibile con uno invisibile, e l’invisibile dura finché qualcuno non controlla l’elenco delle sorgenti. Se la chiave non corrisponde, la correzione giusta è trovare la chiave giusta, non togliere il controllo.

Ottieni i dettagli del repository e l’identità della chiave dal progetto o da un amministratore gestito. Una chiave copiata da un post di un blog è un’affermazione sulla paternità, non una prova. Quando un fornitore pubblica un canale di rotazione, annotalo insieme alla chiave, perché è quel canale a rendere possibile la rotazione successiva.

Il pinning della sorgente non è una lista bianca dei pacchetti

Limitare una chiave a una sorgente limita quale archivio può autenticare, non quali pacchetti quell’archivio può pubblicare. Il repository può distribuire molto più del client VPN che volevi, e la selezione dei candidati e le priorità di APT decidono quale versione idonea vince. Esamina la transazione proposta prima di confermarla, inclusa la lista delle dipendenze, perché le dipendenze arrivano dallo stesso archivio. L’ambito di una chiave non può esprimere ’solo questo pacchetto’.

Se ti serve un controllo più forte, esprimilo come politica su nomi o versioni dei pacchetti e tieni quella politica sotto gestione della configurazione. Leggere una transazione richiede un minuto; scoprire un pacchetto inatteso sei mesi dopo richiede una revisione.

I pacchetti inattesi sono il momento di fermarsi anziché proseguire, e la domanda per il proprietario dell’archivio è perché siano necessari. Un repository che pubblica una dozzina di pacchetti attorno a un client è normale per un fornitore che distribuisce una suite desktop. È anche una superficie più ampia di quanto implicasse la guida all’installazione, e questa è la parte che vale la pena annotare. Nessuno dei due esiti è un motivo per diffidare della firma; entrambi sono motivi per scrivere ciò che hai accettato.

Annota l’autorità e come rimuoverla

Scrivi il proprietario dell’archivio, la versione del sistema operativo supportata, il canale di rotazione della chiave e la procedura di rimozione. Quei quattro fatti sono ciò che serve a un successore quando il client viene ritirato o il fornitore ruota la sua chiave. Senza di essi, la persona successiva eredita una riga di sorgenti e un file di chiave senza alcuna storia.

La rimozione è il passo che si salta, quindi scrivilo al momento dell’installazione. Elimina la voce della sorgente e la sua chiave dedicata insieme, e controlla se quella chiave è referenziata altrove prima di rimuovere il file. Una chiave condivisa eliminata senza quel controllo trasforma una pulizia in un’interruzione non correlata, che è il peggior esito per una modifica di routine. Poi conferma che gli aggiornamenti ordinari si risolvono ancora una volta che la voce è sparita.

Una cosa resta dopo la rimozione del repository: qualsiasi pacchetto già installato da esso continua a funzionare finché qualcosa non lo sostituisce. La domanda onesta è quale autorità hai aggiunto, e con quanta strettezza è stato espresso il suo ruolo.