sicurezza via chsh

3

Sto sviluppando un programma che voglio che le persone siano in grado di connettersi e utilizzare tramite ssh. Ho deciso che un modo semplice per farlo sarebbe quello di creare un account per loro sul mio server linux e cambiare la shell che usano per accedere, per essere il mio programma invece di bash.

Una misura che posso prendere è rimuovere la loro variabile PATH in modo che se in qualche modo ottengono l'accesso a bash, non saranno in grado di eseguire alcun comando.

Questo è orribilmente insicuro? Sto replicando qualche altra cosa esistente? Forse dovrei semplicemente implementare una connessione SSL invece di SSH?

    
posta Nacht 19.05.2014 - 08:33
fonte

2 risposte

2

Rimuovere la variabile PATH non farebbe alcuna differenza: se gli utenti possono eseguire un comando shell, potrebbero ancora impostare la variabile, o eseguire comandi dando il loro percorso completo. Se in qualche modo hanno accesso a una shell, hai perso.

Cambiare la shell in un'altra significa che sono limitati a quel programma e qualsiasi cosa riesca a lanciare da quel programma.

C'è un altro modo per limitare gli utenti che possono accedere solo con SSH: puoi dare loro una chiave (e non inserire una password nell'account, in modo che l'unico modo per accedere sia con la chiave), e mettere una restrizione command=… in authorized_keys (vedi la pagina man di sshd .Questo consente di impostare diversi comandi su chiavi diverse per lo stesso account, che possono o non possono essere utili. Nota che se ti affidi alle restrizioni in ~/.ssh/authorized_keys , dovresti creare la directory home dell'utente, la directory .ssh e il suo contenuto di proprietà di root in modo che l'utente non possa modificarli.

Se il programma a cui si desidera concedere l'accesso utilizza le interazioni del terminale o è un filtro di flusso, l'accesso SSH dedicato è un buon modo per fornire tale servizio. Se il programma produce solo output da una piccola quantità di input, o se il programma usa un tipo di interazione fill-in-a-form, allora HTTPS sarebbe più adatto. Non inventare il tuo protocollo su SSL per questo: usa la shell remota (via SSH) o HTTP (tramite HTTPS) è la migliore per l'interfaccia del tuo programma. HTTPS sarà più facile da usare per la maggior parte degli utenti.

Se vuoi dare agli utenti un accesso limitato alla shell che permetta loro solo di eseguire un insieme limitato di comandi, puoi renderne la shell rbash , a shell limitata . Fai attenzione che le shell ristrette sono difficili da configurare correttamente: devi assicurarti che nessuno dei programmi disponibili abbia una shell escape (GNU sed , versioni non limitate di vi , ...).

Per limitare maggiormente gli utenti, jail il più possibile. Questo può variare da un semplice chroot (che limita i file a cui gli utenti possono accedere se riescono a ingannare il tuo programma) per dare loro un account solo all'interno di una macchina virtuale in piena regola.

    
risposta data 19.05.2014 - 09:34
fonte
1

(Suppongo che tu stia usando OpenSSH qui, dato che è l'impostazione predefinita per i sistemi Linux.)

La rimozione della variabile PATH non fornirà alcuna sicurezza. Se un utente malintenzionato ottiene l'accesso a Bash, può comunque utilizzare i comandi incorporati della shell, uno dei quali consente di impostare PATH (e altre variabili di ambiente) su qualsiasi cosa vogliano; inoltre, possono ancora eseguire programmi specificando il percorso completo.

La modifica della shell di login fornisce un po 'di sicurezza: l'utente è limitato a fare cose che la shell di login consente loro di fare. Ci sono alcuni trucchi qui su un sistema Linux, però: PAM è spesso configurato per impedire l'accesso se la shell di login dell'utente non è elencata in /etc/shells .

Se utilizzi OpenSSH, l'opzione di configurazione ForceCommand in sshd_config può essere utilizzata per forzare l'utente a eseguire il tuo programma quando accedono.

    
risposta data 19.05.2014 - 09:31
fonte

Leggi altre domande sui tag