Strategie di sicurezza per l'archiviazione della password sul disco

Question

Sto creando una serie di processi batch che richiedono l'accesso regolare a un database, in esecuzione su un computer Solaris 10. A causa di vincoli di progettazione (immutabili), è necessario utilizzare un determinato programma per connettersi ad esso. Tale interfaccia ci richiede di passare una password in testo semplice su una riga di comando per connettersi al database. Questa è una pratica di sicurezza terribile, ma siamo bloccati con esso.

Sto cercando di assicurarmi che le cose siano correttamente protette da parte nostra. Poiché l'elaborazione è automatizzata (ovvero, non è possibile richiedere una password) e non è possibile memorizzare nulla al di fuori del disco, ho bisogno di una strategia per archiviare la nostra password in modo sicuro.

Ecco alcune regole di base

1. Il sistema dispone di più utenti.
2. Possiamo supporre che le nostre autorizzazioni siano applicate correttamente (cioè, se un file con un chmod'd a 600, non sarà pubblicamente leggibile)
3. Non mi interessa nessuno con accesso da superutente guardando il nostro memorizzata la password

Ecco quello che ho finora

• Conservare la password in password.txt
• $ chmod 600 password.txt
• processo legge da password.txt quando è necessario
• Buffer sovrascritto con gli zeri quando non è più avuto bisogno di

Anche se sono sicuro che c'è un modo migliore.

Answer 1

Questa non è una soluzione per la crittografia. Indipendentemente dal codice utilizzato, la chiave sarà ugualmente accessibile all'attaccante. Cyrpto non risolve tutti i problemi.

chmod 400 è il migliore, questo lo rende di sola lettura. chmod 600 viene letto in scrittura, che può essere o meno un requisito. Assicurati anche che sia coperto dal processo che ne ha bisogno. Questo è davvero il meglio che puoi fare. Anche se si condivide la macchina con altri utenti, non dovrebbero essere in grado di accedervi. Speriamo che questa sia una macchina dedicata, in questo caso non c'è una grande minaccia. SELinux o AppArmor aiuteranno a rafforzare il sistema dagli attacchi cross-process/cross user.

Modifica: Shread è lo strumento necessario per eliminare in modo sicuro i file.

Modifica: In base ai commenti di Moron/Mike, il comando unix ps aux visualizza tutti i processi in esecuzione e il comando utilizzato per richiamarli. Ad esempio il seguente comando sarà esposto a tutti gli utenti del sistema: wget ftp://user:password@someserver/somefile.ext. Un'alternativa sicura è usare la libreria CURL. Dovresti anche disabilitare la cronologia della shell. In bash puoi farlo impostando una variabile di ambiente export HISTFILE=

Answer 2

Non sei lontano dall'approccio migliore dati i tuoi vincoli. Hai due problemi da affrontare. Il primo è l'archiviazione della password. Il secondo sta usando la password in modo sicuro.

Prima di occuparsi del secondo, si ha un grosso problema nell'uso del programma da riga di comando.Usando le opzioni per il comando 'ps', un utente può vedere gli argomenti usati nell'esecuzione del programma da riga di comando. Da quello che hai scritto, questo conterrebbe la password in testo normale. Lei dice che questa è un'interfaccia immutabile. Anche così, come programmatore etico, dovresti sollevare il problema. Se si trattasse di un'applicazione bancaria che gestisce transazioni finanziarie, potresti considerare di trovare un altro lavoro piuttosto che far parte di una soluzione non etica.

Passando alla memorizzazione sicura della password, non si indica quale lingua si sta utilizzando per i file batch. Se si utilizza uno script di shell, allora si ha poco da fare che non inserire la password nello script della shell o leggerla in un testo semplice da un file. Dalla tua descrizione di memorizzare la password in un file separato, spero che potresti scrivere un programma in un linguaggio compilato. Se è così, puoi fare un po 'meglio.

Se si utilizza un linguaggio compilato, è possibile crittografare la password nel file e decrittografarla all'interno del programma. La chiave per la decifrazione risiede nel programma stesso, quindi non può essere letto facilmente. Oltre a questo, vorrei

• chmod 400 file per impedire ad altri utenti di leggerlo
• aggiungere un prefisso dot ('') per il file di nasconderlo dalla directory normale messa in vendita di
• rinominare il file per renderlo meno interessante da leggere.
• Fare attenzione a non memorizzare la chiave in una stringa semplice: il comando "stringhe" stamperà tutte le stringhe stampabili da un'immagine eseguibile unix.

Avendo fatto queste cose, i prossimi passi sarebbero migliorare la gestione delle chiavi. Ma non andrei così lontano fino a chiarire il problema "ps". Non ha molto senso mettere il terzo catenaccio sulla porta d'ingresso quando prevedi di lasciare la finestra aperta.

Answer 3

Non riempire il buffer della password con zeri, questo è inutile. Il kernel può decidere di scambiarlo in una posizione arbitraria nel file di scambio o dire dopo l'allocazione di una certa memoria il kernel sposterà le tabelle della pagina, risultando in altre tabelle della pagina contenenti la password mentre si ha accesso solo alla nuova copia.

È possibile prctl (2) con PR_SET_NAME per modificare al volo il nome del processo. Purtroppo al momento non riesco a pensare ad altro modo se non inserire del codice nel processo in esecuzione tramite ptrace (2), il che significa che i processi nemici correranno per leggere la lista dei processi prima di avere la possibilità di cambiare il nome del nuovo processo:/

in alternativa, si può afferrare le patch del kernel grsecurity, e attivare CONFIG_GRKERNSEC_PROC_USER:

Se dite Y qui, gli utenti non-root saranno solo in grado di visualizzare i propri processi, e li limita da visualizzazione delle informazioni relative alla rete, e visualizzazione del simbolo del kernel e del modulo informazioni.

Questo fermerà ps da poter visualizzare il comando di marcia, come ps legge da /proc/<pid>/cmdline

interfaccia Detto richiede di passare una password plain-text su un comando linea per collegare a il database. Questo è una pratica di sicurezza terribile, ma siamo bloccati con esso.

È solo una cattiva pratica di sicurezza a causa di problemi nell'architettura O/S. Ti aspetteresti che altri utenti siano in grado di intercettare le tue syscalls? Non darei la colpa a uno sviluppatore che è caduto in questa trappola.