È pericoloso programmare un utente chiamato deamon che invia password tramite https?

3

Ho questo problema:

  • L'app della mia console deve connettersi a un server. Tuttavia, il server richiede password in testo normale per HTTP POST per l'accesso. La connessione è HTTPS.
  • L'app viene chiamata solo di tanto in tanto, ma non viene eseguita in modo permanente.

Ora, non voglio che l'utente inserisca la sua password per ogni esecuzione dell'app. La mia idea era:

  • Quando l'utente avvia l'app per la prima volta, all'utente viene chiesta una password. È in corso l'avvio di un nuovo deamon (ovvero un programma eseguito dall'utente, che può essere eseguito per più settimane) e la password immessa viene passata direttamente al demone.
  • Per accedere alla homepage, l'app dice solo al demone "login". Il demone, che ha la password nella RAM, chiama wget per accedere al sito web [1].

La mia principale preoccupazione è che il demone abbia la password nella RAM. Quali pericoli potrebbero arrendersi da questo?

Vedo tre rischi:

  • Qualcuno potrebbe accedere alla RAM. Probabilmente costringendo il computer a sostituirlo, quindi premendo il pulsante di accensione, e quindi esaminando il disco rigido. È possibile, ma probabilmente non è efficace.
  • Il demone potrebbe usare i file temporanei per archiviare la memoria. Probabilmente è vero per bash? Tuttavia, se scriverò un programma in C, questo non dovrebbe essere possibile?
  • Qualcuno potrebbe usare uno script che dice "Ciao deamone, sono wget / internet, dammi la password". Finché chiamerò "/ usr / bin / wget" e finché l'utente non è root, penso che non sarà possibile?

Altri problemi?

Note: [1] wget ottiene la password tramite un file, quindi la password non si trova in ps -table. Il file sarebbe costruito dal demone con diritti di lettura solo per l'utente, e sarebbe cancellato dopo il login.

    
posta Johannes 20.12.2016 - 15:03
fonte

1 risposta

3

Any other issues?

Sì, lo stai complicando eccessivamente.

Suggerirei di installare solo un ramfs o un LUKS montare e impostare l'autorizzazione in modo che solo l'applicazione abbia accesso in lettura a tale directory. L'applicazione dovrebbe essere setuid per l'utente speciale, oppure dovresti avere un sudoers regola che consente di eseguire sudo -u specialuser secureapp .

La sicurezza è la stessa o migliore di quella che stai proponendo, e sarebbe molto più semplice da implementare.

Per quanto riguarda la tua preoccupazione che qualcuno possa scaricare la RAM, se l'utente malintenzionato ha il privilegio di scaricare la RAM, sei già fregato. Perdere la password è l'ultima delle tue preoccupazioni.

Se non si riesce a divulgare la password in ogni caso, anche se l'utente malintenzionato può scaricare la RAM, non utilizzare le password per l'accesso. Invece, suggerirei forme alternative di autenticazione come token di accesso, o PKI con certificato client, possibilmente in un modulo di sicurezza hardware (ad esempio x.509 o smartcard OpenPGP).

Se vuoi comunque scrivere un daemon, e hai un'area nella RAM che contiene dati sensibili, dovresti usare mmap (MAP_LOCKED) / mlock () per allocare memoria non mappabile o per impedire una parte del memoria dall'impaginazione.

Per la tua terza preoccupazione, piuttosto che il daemon che ascolta su HTTP via TCP (AF_INET), suggerirei che il demone dovrebbe ascoltare Unix domain socket (AF_LOCAL) . Con il socket Unix, è possibile applicare il permesso di file per limitare chi può comunicare con il socket, questo offre un controllo degli accessi molto più fine rispetto a TCP. Esempi: ssh-agent e gpg-agent sono implementati usando i socket Unix.

    
risposta data 20.12.2016 - 16:46
fonte

Leggi altre domande sui tag