Perché nosuid impedisce a un helper VPN di diventare root

Cifratura del disco e un mount nosuid suonano come varianti della stessa idea, e non hanno alcun rapporto. L’una protegge i dati a riposo, e l’altro decide se il kernel rispetterà un bit di privilegio nel momento in cui un programma parte. Un helper che non raggiunge l’identità che si aspetta si sta lamentando del secondo. Il presupposto che sia il primo il responsabile manda le persone a reinstallare client che non erano mai stati guasti.

Due Proprietà Non Correlate

La cifratura del disco risponde a chi può leggere i blocchi quando la macchina è spenta. Un’opzione di mount risponde a cosa farà il kernel con i bit di modo di un file quando qualcuno lo esegue. Nulla del primo vincola il secondo, e un portatile completamente cifrato può montare un filesystem con tutte le restrizioni al loro posto.

Leggerli come un’unica proprietà è ciò che produce la teoria secondo cui una home cifrata impedisce l’accesso root. Quella teoria sopravvive perché i due sintomi compaiono sulla stessa macchina, non perché condividano una causa.

Cosa Sopprime Davvero la Transizione

Il riferimento di execve descrive come un eseguibile set-user-ID cambi l’identità effettiva del nuovo processo con quella del proprietario del file. La stessa pagina elenca le condizioni che sopprimono quella transizione e l’equivalente per gli identificatori di gruppo: un’impostazione no_new_privs, un filesystem montato con nosuid e un processo sotto tracciamento. Le capability del file vengono ignorate nelle stesse condizioni. Quelle quattro regole coprono quasi ogni segnalazione di questo tipo.

Quell’elenco spiega perché il modo stampato da ls non è mai tutta la storia dell’autorizzazione. Non dice quale condizione abbia causato un particolare messaggio di errore, e l’applicazione potrebbe segnalare un’operazione di credenziali non correlata con le stesse parole. Annota il programma esatto, il launcher e la sequenza degli errori prima di trarre una conclusione.

Identifica l’eseguibile installato dal pacchetto supportato, il suo proprietario, il suo percorso reale e la politica del filesystem che lo contiene. Una copia in una cartella di download non è l’helper installato, qualunque cosa dica il suo modo.

Cosa Non Fare al Riguardo

Mettere bit set-user-ID su un binario non verificato e spostarlo finché la restrizione non scompare non è una riparazione. Sostituisce una politica che non capivi con un privilegio che non puoi verificare, e la stessa tecnica applicata a un helper è una via di escalation ben nota. Togliere nosuid da un mount è peggio, perché riguarda ogni programma su quel filesystem, non solo uno.

La via supportata è l’installazione documentata dell’helper o del servizio da parte del client, eseguita da un amministratore, che colloca il binario dove la politica se lo aspetta. Così resta un solo meccanismo di privilegio invece di due.

Confermare il Contesto di Avvio Reale

Dopo una correzione autorizzata, esegui l’helper come lo esegue il prodotto e non da una shell di root. Un successo come root non dimostra nulla sul percorso di un utente normale, e la differenza tra questi due contesti è esattamente ciò di cui parlava l’errore.

Poi conferma l’operazione di rete per cui l’helper esiste. Un helper che parte ma non riesce a configurare l’interfaccia ha spostato il problema di una fase, non risolto.

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

Annota le opzioni di mount e la proprietà dell’helper nella stessa nota. Altrimenti la prossima persona che eseguirà il debug di questo ripartirà dalla teoria della cifratura.