È sicuro chiamare mount (2) e passare la password come parametro?

3

Volevo scrivere un daemon che gli utenti possano avviare e che ogni 2 ore monti automaticamente una condivisione di rete autenticata. Il demone chiederà all'utente la password solo la prima volta e lo manterrà mlock() ed allora.

La mia idea era di chiamare in qualche modo il programma linux mount(1) (notazione manpage). Il protocollo per il montaggio (nel mio caso samba) consente solo di dare la password tramite le opzioni di mount -o [1]. Tuttavia, il passaggio della password come parametro a uno script di shell lo rende visibile nella ps-table.

Poi, ho scoperto che c'è una chiamata di sistema linux mount(2) che prende gli stessi parametri. È sicuro passare semplicemente la password come testo normale ai parametri di mount(2) ?

Cose di cui mi preoccupo:

  • mount(2) potrebbe essere implementato chiamando un processo in cui passa gli argomenti, inclusa la password. Questo lascerebbe la password nella ps-table. Tuttavia, penso che le chiamate di sistema non lo faranno?
  • mount(2) potrebbe avere i suoi parametri nella memoria non mlock() ed, ad es. se il sistema si scambia, la password in chiaro è leggibile su disco. Non so se un sistema - chiama memoria può essere scambiato, ma dal momento che la chiamata di montaggio è attiva solo per un breve periodo, immagino che questo non sia un vero problema.
  • mount(2) potrebbe (o dipende dal tipo di file system) errori di stampa o messaggi di log che espongono i suoi parametri. (ad esempio nei file di sistema come /var/log/messages o dmesg output). Almeno, ho appena testato mount(2) con il flag MS_SILENT e non ho trovato alcun registro di sistema, anche in caso di errore.

Tutto sommato, quanto è sicura la mia soluzione?

Note: [1] Samba consente anche i file di autenticazione in testo normale o la digitazione della password al prompt, ma nel mio caso non è stato utile.

    
posta Johannes 05.01.2017 - 15:10
fonte

1 risposta

1
  1. mount (2) potrebbe essere implementato chiamando un processo è esattamente l'opposto: mount(1) è un front-end che alla fine chiama mount(2) che essendo una chiamata di sistema chiede al kernel per fare il lavoro

  2. mount (2) potrebbe avere i suoi parametri nella memoria non-mlock () ed non sicuri, ma perché pensi che la memoria mlock sia sicura? AFAIK root può leggere / dev / mem e / dev / kmem come (di più?) Facilmente come il contenuto della partizione di swap ...

  3. mount (2) potrebbe (forse a seconda del tipo di file system) errori di stampa o messaggi di log che espongono i suoi parametri sarebbe effettivamente una minaccia alla sicurezza, e non conosco nessuna rete montare l'utility per registrare una password in chiaro. Ad ogni modo, come detto in 1, qualsiasi tentativo di montare la condivisione di rete finirà per terminare con una chiamata di mount(2) , quindi non puoi evitarlo.

TL / DR: è molto più sicuro chiamare mount(2) che avvia un sottoprocesso per chiamare mount(1) perché i parametri passati al comando subprocess saranno accessibili attraverso la tabella del processo e possono essere visualizzati con ps con le opzioni appropriate e l'elaborazione della condizione di errore saranno molto più semplici.

    
risposta data 05.01.2017 - 18:02
fonte

Leggi altre domande sui tag