Perché è male avere i file di scrittura root in una directory non di proprietà di root?

Questo è emerso in un commento a un'altra domanda e mi piacerebbe che qualcuno potesse spiegarmi le ragioni.

Ho suggerito di fare in modo che Apache registrasse gli errori per un dato VHost nella home directory di un utente. Questo è stato abbattuto perché insicuro. Perché?

Ho chiesto chiarimenti in un commento di risposta, ma tutto quello che ho ottenuto è che non è sicuro avere la scrittura root in una cartella non di proprietà di root. Ancora una volta, qualcuno potrebbe spiegare?

Grazie,

Bart.

linux security permissions

— Bart B
fonte

Cosa sta facendo Apache in esecuzione come root - il principio del privilegio minimo grida contro quello!

— Jonathan Leffler,

Apache funziona come www, ma viene avviato come root in modo che possa legarsi alla porta 80 come è la norma. Apparentemente registra anche come root.

— Bart B,

Perché un utente malvagio può tentare maliziosamente di indicare che il file rootsta scrivendo in una posizione diversa . Questo non è così semplice, ma davvero possibile.

Ad esempio, se un utente trovasse il modo di creare un collegamento simbolico dal presunto log di Apache a, diciamo, / etc / shadow , all'improvviso avrai un sistema inutilizzabile. Apache ( root) sovrascriverebbe le credenziali dei tuoi utenti rendendo il sistema difettoso.

ln -s /etc/shadow /home/eviluser/access.log

Se il file access.log non è scrivibile dall'utente, può essere difficile dirottarlo, ma evitare la possibilità è meglio!

Una possibilità potrebbe essere quella di utilizzare logrotate per eseguire il lavoro , creando il collegamento a un file non già esistente, ma tale logrotate verrà sovrascritto non appena i log crescono:

ln -s /etc/shadow /home/eviluser/access.log.1

Nota :

Il metodo symlink è solo uno dei possibili attacchi, dato come prova di concetto.

La sicurezza deve essere fatta pensando alla White List , non inserendo nella blacklist ciò che sappiamo essere un problema.

— AlberT
fonte

C'è un modo per impostare le autorizzazioni su di esso in modo che possano solo leggere il file e non cancellare, modificare o fare qualsiasi altra cosa (come chown, chmod, ecc.)?

— Giosuè,

dovresti fare questa operazione su ogni possibile file di destinazione! questo file scrivibile è il file preferito, non il collegamento stesso di proprietà dell'attaccante durante la sua creazione.

— drAlberT,

@Joshua: chown può essere eseguito solo da root. chmod può essere eseguito da chiunque sia il proprietario del file. IIRC, la ridenominazione può essere effettuata da chiunque sia in possesso della directory. Come menziona AlberT, la creazione di un collegamento prima che root crei il file può essere eseguita da chiunque possa scrivere nella directory.

— atk,

@atk: Inoltre, chiunque possieda la directory può generalmente rimuovere i file da essa (a meno che non +tsia impostato il bit sticky ), anche se non hanno il permesso di scrittura per i file stessi (perché unlink () è una scrittura nella directory, non il file). Anche se root crea il file in anticipo, il proprietario della directory potrebbe comunque essere in grado di eliminarlo e sostituirlo con un collegamento simbolico a qualcos'altro.

— James Sneeringer,

Se eviluser può scrivere in / home / eviluser (o può cambiare i permessi sulla directory - lo possiedono, IOW), allora non importa quali siano i permessi su access.log; il malvagio utente può (ri) spostare il file e posizionare il suo link simbolico al suo posto. Un'altra domanda è se il software presta attenzione a ciò che apre.

— Jonathan Leffler,

Il principio generale di non avere processi che scrivono in una directory di cui non sono proprietari o di cui si fida è buono. Ma in questo caso particolare, è ragionevole fidarsi che il codice Apache apre il registro con O_NOFOLLOWecc: l'accesso alla home directory di un utente è una configurazione comune.

— poolie
fonte