Permesso di attraversamento su ogni directory prima della chiave

Il modo 0600 e il proprietario corretto non garantiscono che il servizio possa aprire una chiave. Il permesso mancante di solito si trova su una directory superiore. Linux risolve un percorso un componente alla volta, e ogni passo richiede il permesso di ricerca prima che si tenti il successivo. Leggete l’intero percorso, non l’ultima riga dell’elenco.

Il permesso di lettura è l’ultimo passo, non l’unico

Aprire un file richiede che il kernel attraversi dalla radice o dalla directory di lavoro ogni componente del percorso. Una directory senza permesso di ricerca interrompe quel cammino con un errore di permesso. Il modo del file stesso non viene mai consultato, quindi una chiave perfettamente leggibile sembra illeggibile. L’errore arriva spesso all’apertura senza nominare la directory, e per questo si incolpa il file finale.

Per una directory, il bit di esecuzione significa ricerca, non esecuzione del contenuto. Una chiave resta un dato, e nessuna parte di questa riparazione richiede di marcarla come eseguibile.

Percorrete il percorso come account di servizio

Elencate ogni componente con proprietario e modo, poi ripetete la lettura come identità reale del servizio. La differenza tra la vostra shell e il demone è spesso tutta la risposta. Seguite i collegamenti simbolici fino al bersaglio reale, perché è il percorso risolto a essere controllato.

namei -l /etc/openvpn/client/office.key
sudo -u vpn-reader stat -c '%A %U:%G %n' /etc/openvpn/client/office.key

Un servizio può anche aprire file in più di una fase. Parte del materiale viene letto durante la configurazione privilegiata, mentre altri file vengono aperti dopo la rinuncia ai privilegi. Una shell di root che legge il file non riproduce l’accesso del worker successivo. Uno spazio dei nomi di mount può presentare una vista diversa dello stesso percorso, soprattutto dentro un container, quindi confrontate la vista del filesystem del demone con la vostra.

Cambiate il permesso più stretto che basta

Scegliete la disposizione più piccola che dà accesso al processo: un gruppo controllato con ricerca sulle directory necessarie, una posizione gestita che il servizio già possiede, o un altro meccanismo documentato. Leggere un file non richiede il permesso di scrittura sulla sua directory. Un permesso ampio di scrittura di gruppo su una configurazione privilegiata non è una normale riparazione dell’attraversamento. Nemmeno 0777 ricorsivo è una soluzione.

Annotate quale componente avete cambiato e perché. Un cambio di permesso senza una ragione registrata è difficile da rivedere e facile da dimenticare.

Guardate oltre i modi solo dopo l’attraversamento

Se i bit di modo sembrano sufficienti, i controlli rimanenti sono ACL, politica di sicurezza e restrizioni della sandbox. Un’ACL può concedere un accesso che i bit di modo suggeriscono assente, o negare un accesso che sembrano permettere. Quelle impostazioni appartengono al proprietario attuale della configurazione, e vanno regolate in modo stretto invece di disattivarle. Una differenza di radice o di directory di lavoro può anche spiegare un percorso assoluto che funziona in un contesto e fallisce in un altro.

Non perdete di vista che cos’è il file mentre riparate l’accesso. Un certificato CA è pubblico per progetto; una chiave privata no. I file che il client riscrive hanno bisogno anche di diritti di scrittura diversi da quelli di una chiave di identità in sola lettura. Ispezionate i metadati senza stampare segreti, poi confermate che il servizio stesso funzioni dopo la modifica. Una breve nota nella documentazione del servizio risparmia lo stesso percorso alla persona successiva.