Qual è il modo sicuro per modificare spesso le autorizzazioni UNIX su un file harcoded?

Naviga le tue risposte
2

Sto scrivendo un daemon che controlla qualcosa nel sistema operativo e capovolge i permessi di esecuzione su un file in / run / back and forth. Il file ha contenuti statici e il nome del file è hardcoded nel demone. Ho reso il demone eseguito come root per renderlo in grado di scrivere in / run /.

Il daemon dovrebbe essere usato su un gran numero di macchine Linux desktop, quindi voglio assicurarmi che non sia sfruttabile. Non sono particolarmente preoccupato dagli attacchi DDoS anche perché il daemon non è mission-critical. Tuttavia, tutti i modi per rendere un file eseguibile o non eseguibile sembrano avere un difetto di sicurezza.

Way # 1: chmod () avanti e indietro

Crea il file e chmod() avanti e indietro. Non mi piace l'idea, perché se un utente malintenzionato riesce a sostituire il file con un collegamento simbolico a qualcos'altro, un file o una cartella arbitraria sarà codificato in leggibilità e possibilmente eseguibilità. Tuttavia, l'autore dell'attacco avrebbe bisogno delle autorizzazioni di root.

Way # 2: rimuovi il file e ricominciamo a ricrearlo atomicamente con open ()

Elimina prima il file e poi ne crea atomicamente uno nuovo con le autorizzazioni corrette usando open(path, O_CREAT|O_WRONLY|O_TRUNC|O_EXCL, permissions) , quindi scrivi i contenuti nello stream e chiudilo. Mi piace questo perché l'unica cosa che può essere sfruttata è la rimozione di un file con un nome hardcoded sostituendo la directory di destinazione con un link simbolico ad un'altra directory, e se è possibile sovrascrivere le directory di root non è necessario aver bisogno di demoni ingannevoli per rimuovere un file con un nome file hardcoded comunque.
Cosa succede se il file viene eliminato mentre il daemon sta scrivendo in streaming in questo caso?
Sta usando g_remove () okay o devo usare solo unlink () e abortire se fallisce?

Mi manca qualcosa o sto solo diventando paranoico e il modo # 2 è abbastanza sicuro?

    
posta Shnatsel 21.11.2012 - 00:47
fonte

2 risposte

6

Il tuo metodo # 1 può essere adattato per proteggersi dagli attacchi symlink:

  1. lstat() del percorso del file che vuoi modificare. Salva i valori di st_dev e st_ino nel struct stat che viene restituito. Questi due numeri identificano in modo univoco il file sul tuo sistema.
  2. open() del file con O_RDONLY .
  3. fstat() il descrittore di file aperto. Verifica che st_dev e st_ino siano uguali a quelli salvati in precedenza. Se sono diversi, hai appena seguito un link simbolico e dovresti eseguire il salvataggio.
  4. fchmod() del descrittore di file per impostare il bit di esecuzione. fchmod() è come chmod() tranne che opera su un descrittore di file aperto.

Se l'utente malintenzionato non può modificare le directory degli antenati della directory contenente questo file, questo è tutto ciò che devi fare. Se l'autore dell'attacco può modificare le directory degli antenati, allora è possibile che tu abbia seguito un collegamento simbolico su un componente precedente del percorso quando hai chiamato lstat . Quindi diventa un po 'più complicato:

  1. lstat() il primo componente del percorso che potrebbe essere un collegamento simbolico. Salva st_dev e st_ino .
  2. chdir() nel prossimo componente del percorso utilizzando un percorso relativo .
  3. stat() della directory corrente ( . ) e assicurati che st_dev e st_ino siano uguali.
  4. Ripeti fino a raggiungere la directory contenente il file.

Quando hai finalmente raggiunto la directory contenente il file, esegui i passaggi precedenti, ma assicurati di chiamare lstat() e open() su un percorso relativo.

    
risposta data 21.11.2012 - 05:14
fonte
1

Attenzione: l'impostazione di un eseguibile come non eseguibile non impedisce l'esecuzione se è leggibile (per non parlare del concetto di copia del file). 

$ cp /bin/ls ~/bin/ls
$ chmod a-x ~/bin/ls
$ /lib/x86_64-linux-gnu/ld-2.15.so ~/bin/ls
#Yup, that worked.

... anche se puoi evitarlo se il file non è leggibile, il che non ferma l'esecuzione. 

$ chmod a+x ~/bin/ls 
$ chmod a-r ~/bin/ls
$ ~/bin/ls
#Worked
$ /lib/x86_64-linux-gnu/ld-2.15.so ~/bin/ls 
/home/me/bin/ls: error while loading shared libraries: /home/me/bin/ls: cannot open shared object file: Permission denied

Potrebbe impedire l'esecuzione di un programma come suid, ma la risposta probabilmente non implica l'impostazione del bit di esecuzione.

    
risposta data 21.11.2012 - 02:35
fonte

Leggi altre domande sui tag

Microsoft può monitorare il mio computer a causa dell'ingresso dell'email di Windows 8 Migliorare l'autenticazione del digest utilizzando PBKDF2