Sto lavorando su un server web che memorizza le risorse in Redis . Per rendere le distribuzioni di sciami il più possibile senza problemi, sto implementando un'opzione in cui il server non ha bisogno di accedere al filesystem per recuperare i dati operativi.
Il protocollo di comunicazione Redis è in chiaro. Questo è OK perché la maggior parte delle risorse non è sensibile e l'utente non dovrebbe rendere accessibile lo sciame Redis da Internet. Tranne le chiavi private del certificato TLS, che devono anche essere memorizzate nel database Redis. Se un utente malintenzionato accede a una delle stazioni nella sottorete privata con accesso allo sciame Redis, non avrebbe bisogno di nient'altro per connettersi a Redis e recuperare la suddetta chiave.
Quindi la prima idea per una soluzione era crittografare la chiave di certificato TLS prima di memorizzarla. Ma poi ho bisogno di fornire ogni processo nel mio sciame con la chiave di crittografia simmetrica. Ora, a quanto pare, non è sicuro fornire quella chiave di crittografia simmetrica tramite i parametri della riga di comando. Ad esempio, se lo faccio:
$ cat /proc/6630/status
...
Uid: 0 0 0 0
...
e poi
$ cat /proc/6630/cmdline
/sbin/dhclient-d-sf/usr/lib/NetworkManager/nm-dhcp-client.action-pf/run/sendsigs.omit.d/network-manager.dhclient-eth0.pid-lf/var/lib/NetworkManager/dhclient-90380716-3851-4c0f-98c5-aaf16acdc395-eth0.lease-cf/var/lib/NetworkManager/dhclient-eth0.confeth0
da un account normale, vedo che un utente con privilegi minimi è perfettamente in grado di snoop dei parametri della riga di comando dei processi avviati da qualsiasi altro utente, ad es. root. Quindi, usare un parametro da riga di comando non è ancora abbastanza buono.
Quindi ho l'opzione 2: per memorizzare la chiave privata in una posizione protetta nel filesystem. Questa scelta sconfigge la mia intenzione di fare in modo che il server non acceda al filesystem. E l'opzione 3, per memorizzare parte della chiave di crittografia simmetrica nel binario del server web stesso e dare alle persone un modo per personalizzare il frammento chiave. Almeno in teoria, con l'opzione 3 un utente malintenzionato dovrebbe essere registrato in una stazione che esegue il server Web e disporre di privilegi sufficienti per leggere il file binario del server Web stesso. Questo è equivalente alla situazione dello status quo oggi in cui la chiave privata è memorizzata in un file protetto nel server.
L'opzione 4 consiste nel mettere la chiave simmetrica in una variabile d'ambiente, apparentemente più sicura:
$ cat /proc/6630/environ
cat: /proc/6630/environ: Permission denied
C'è un modo per evitare perdite della chiave attraverso /proc/<PID>/cmdline nello scenario 1? Nello scenario 4, c'è un modo in cui l'ambiente di un processo può perdere che non ho tenuto conto? E infine, c'è qualche altra scelta di design evidente che non ho preso in considerazione?