Il tuo comando VPN gira senza privilegi; il servizio no

Il comando VPN gira come il tuo utente, non compare alcuna password e il tunnel si alza. Questa sequenza sembra un’operazione senza privilegi, e di solito non lo è. Un servizio separato esegue le modifiche di rete, e la domanda interessante è che cosa farà quel servizio per un chiamante che non ha verificato. Contare le richieste di password non ti dice nulla su quel confine.

L’interfaccia, il meccanismo e il controllo

L’interfaccia accetta richieste: connetti, disconnetti, scegli un profilo. Il meccanismo possiede le operazioni di rete: creare interfacce, cambiare rotte, applicare filtri. Il controllo di autorizzazione decide se questo chiamante può chiedere questa azione. Questi tre possono essere distribuiti tra un binario, un helper e un servizio di sistema, e l’utente vede solo il primo.

I ruoli possono vivere in un solo binario, in due processi o in un client e un servizio di sistema, e il comando che l’utente vede rivela di rado quale. Un’icona nella barra e un demone di sistema possono sembrare un’unica applicazione mentre girano con un’autorità molto diversa. Il privilegio al momento dell’installazione e il privilegio al momento della richiesta sono anch’essi cose diverse. Un installatore che ha girato come root può lasciare un servizio in ascolto per richieste successive, molto dopo che il gestore dei pacchetti ha finito. È quel servizio, non il comando che hai digitato, a detenere l’autorità.

La delega è il progetto normale

Delegare il lavoro di rete privilegiato a un servizio è l’architettura ragionevole. Mantiene le applicazioni ordinarie senza privilegi e centralizza le operazioni che richiedono cura. Il progetto ripaga solo quando il servizio controlla anche chi chiede e per che cosa. Senza quel controllo è solo una porta più larga.

NetworkManager è l’esempio concreto su Linux. La sua guida alla configurazione spiega come PolicyKit autorizza le richieste non root nella configurazione predefinita. Questo mostra un’autorizzazione delegata in un prodotto reale. Non dimostra che ogni client commerciale usi NetworkManager, e non descrive il percorso del socket né la politica di un fornitore particolare.

Lo schema è una delega con una politica dietro. L’esempio è un’implementazione di quello schema, non una universale.

Leggi il confine, non la richiesta

Trova il servizio, il proprietario della sua configurazione e l’interfaccia locale che usa il frontale. Poi chiedi quali utenti possono richiedere quali operazioni. Poter alzare e abbassare un profilo salvato non è lo stesso permesso di caricare una configurazione che l’operatore non ha mai esaminato. La differenza è tutta la questione di sicurezza.

Comincia dal gestore dei servizi e dalla visione che il client ha dei propri permessi. I comandi qui sotto mostrano se il demone è in esecuzione, che cosa il chiamante può chiedergli e che cosa il demone espone sotto la sua directory di esecuzione.

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

Chiedi anche su che cosa agisce l’operazione. Una voce di menu che sembra personale può cambiare rotte e DNS per l’intera macchina, il che significa che può disturbare le sessioni di altri utenti. Il raggio d’impatto appartiene alla stessa revisione del permesso, e di solito decide se il servizio ha bisogno di un ruolo più stretto.

Correggi i permessi nel modo supportato

Rendere un socket di controllo protetto scrivibile da tutti, o aggiungere un account a un gruppo amministrativo ampio, elimina un errore di permesso e ne crea uno più grande. L’errore era l’unica cosa che ti diceva che quel confine esisteva. Usa il processo documentato di appartenenza o autorizzazione, compreso il rinnovo di sessione che richiede. L’appartenenza a un gruppo spesso vale solo per le nuove sessioni di accesso, ed è per questo che una modifica può sembrare inerte fino al successivo accesso.

Se il prodotto espone un ruolo più stretto per l’operazione, preferiscilo a una concessione generale. Scrivi il ruolo scelto e il suo proprietario accanto al nome del servizio.

Come appare una buona separazione

Le applicazioni ordinarie restano senza privilegi, il servizio esegue solo la preparazione per cui è stato progettato, e ogni chiamante viene controllato contro una politica che qualcuno possiede. È un progetto difendibile. È anche verificabile, perché la politica ha un nome collegato. Qualunque cosa di più ampio merita un’eccezione scritta invece di un silenzioso cambio di permessi.

Il modo di fallire è un servizio che esegue qualsiasi richiesta di qualsiasi utente locale perché l’interfaccia è comoda. Dal lato dell’utente sembra identico, e porta un’autorità molto maggiore. Prova una richiesta rifiutata, non solo quella riuscita. Un rifiuto che viene dalla politica è la prova che la politica esiste.