Come limitare la shell degli utenti consentendo di eseguire programmi di shell

È possibile impedire a qualsiasi utente di non utilizzare comandi come ls, rm e altri comandi di sistema che potrebbero danneggiare il sistema. Ma gli utenti dovrebbero essere in grado di eseguire programmi shell.

La tua domanda dovrebbe essere:

Non mi fido dei miei utenti. Quelli stupidi vedono qualcosa su Internet e provano senza capire cosa fa. Ai subdoli piace curiosare in giro e guardare i file degli altri e rubare le loro idee. E i pigri, non farmi iniziare dai pigri.

Come posso proteggere il mio sistema e i miei utenti dai miei utenti?

Innanzitutto, unix ha un sistema di autorizzazioni per filesystem molto completo. Questo sembra essere un tutorial decente sulle autorizzazioni del filesystem unix . L'essenza di questo è che le directory possono essere impostate in modo tale che un utente possa andare in una directory e può eseguire programmi da quella directory ma non può visualizzare il contenuto di quella directory. Se lo fai, ad esempio, su / home, se l'utente esegue ls su / home, viene visualizzato un errore di autorizzazione negata.

Se hai davvero paura dei tuoi utenti e vuoi inserirli in un tipo supermax di ambiente limitato, usa qualcosa come le prigioni di freebsd o le zone di solaris - ogni utente ha il suo ambiente su misura. Per i punti aggiunti usa ZFS in modo da poter scattare un'istantanea dell'ambiente quando effettuano l'accesso, quindi se eliminano i loro file puoi semplicemente estrarli dall'istantanea.

Ci sono tre cose che devono essere in atto per fare pienamente quello che stai chiedendo:

1. Una shell personalizzata priva dei comandi che ti interessano . Questa è una cosa difficile da ottenere, ma se davvero non vuoi che gli utenti abbiano accesso ad alcune primitive di shell, questo è l'unico modo per rimuoverle.
2. Impostare correttamente le autorizzazioni per i file . Non vuoi che gli utenti danneggino il sistema? Imposta le autorizzazioni in modo che non possano danneggiare il sistema anche se hanno gli strumenti giusti. Di questi tre passaggi, questo è il passaggio più semplice.
3. Utilizzare una tecnologia di controllo accessi obbligatoria come AppArmor . MAC come AppArmor e SELinux incorporano le autorizzazioni nel kernel. Questi impediscono agli utenti di eseguire gli strumenti giusti anche se li trovano da qualche parte (e come i permessi dei file, impediscono loro di usarli al di fuori della casella riservata).

Cintura, bretelle e una pistola di base per buona misura. Difficile sbagliare lì.

AppArmor è interessante poiché il MAC per un eseguibile specifico è ereditato da tutti i suoi figli. Imposta come utente il login dell'utente /bin/bash-bob, imposta il profilo AppArmor per quel diritto binario specifico e l'unico modo per uscire da quel carcere di autorizzazione è attraverso exploit del kernel. Se alcuni script di installazione pigri lasciano /var/opt/vendor/tmpscrivibile a livello globale per qualche stupida ragione, l'utente che usa /bin/bash-bobcome shell non sarà in grado di scrivere lì . Imposta il profilo bash-bob per consentire solo la scrittura nella loro directory home e /tmp, e tali errori di autorizzazione non possono essere sfruttati. Anche se in qualche modo trovano la password di root, il profilo AppArmor per /bin/bash-bobsi applicherà anche dopo che si sono verificati suda allora sue il bashprocesso che genera sono figli /bin/bash-bob.

La parte difficile è costruire quel profilo AppArmor.

1. Crea un profilo AppArmor per / bin / bash-bob e impostalo in modalità di controllo
2. Impostare la shell di accesso di Bob su / bin / bash-bob
3. Accedi come Bob. Fai tutto quello che vuoi che Bob sia in grado di fare.
4. Usa auditlog per creare il profilo AppArmor (SUSE ha strumenti per questo, non sono sicuro di altre distro Linux). Questo è mostruosamente noioso, ma deve accadere se hai bisogno di questo livello di sicurezza.
   1. Farai cose come:
      • Approvazione dell'accesso in lettura alla maggior parte delle librerie di sistema
      • Approvazione dei diritti di lettura ed esecuzione dei pochi comandi di sistema consentiti selezionati
      • Approvazione dell'accesso in scrittura agli spazi temporanei
      • Approvazione della creazione del socket, se necessario
5. Imposta il criterio da applicare.
6. Accedi come Bob, fai le cose.
7. Apporta le modifiche.

A mio avviso, hai solo bisogno dei passaggi 2 e 3, poiché in combinazione entrambi impediscono la possibilità di fare qualcosa di dannoso al di fuori della scatola accuratamente costruita che hai impostato in entrambi quei passaggi.

Bene, puoi impostare la shell dell'utente su un programma che hai scritto che consente loro solo di eseguire determinati script di shell.

Naturalmente questo sarebbe sicuro solo come il programma e gli script della shell; in pratica, questo tipo di shell limitata in genere non è sicura contro un aggressore intelligente.

Non tentare di limitare i comandi, limitare le autorizzazioni per i file. Non puoi praticamente limitare l'accesso delle persone ai syscalls, quindi tutto ciò che qualcuno deve fare è fornire la propria copia di qualsiasi comando "pericoloso" che non vuoi che esegua e sei pieno.

Se si desidera che l'utente sia in grado di eseguire solo determinati script / binari, è possibile utilizzare una shell con restrizioni . Questo (come menziona l'articolo di Wikipedia) non è completamente sicuro, ma se puoi garantire che nessuna applicazione autorizzata a eseguire sia in grado di eseguire una nuova shell, allora è una buona alternativa.

Per impostare una shell con restrizioni dell'utente, impostare /bin/rbash(o simile, la maggior parte delle shell entra in modalità limitata quando il binario è chiamato r *** name *) come shell degli utenti. Quindi, modifica **. Bashrc (o equivalente) e imposta $PATHuna directory in cui sono memorizzati tutti i binari / script consentiti.

Sì, è possibile, ma in pratica ci vorrebbe molto lavoro e pianificazione. È possibile creare script e farli funzionare come uso privilegiato, quindi rimuovere tutti i privilegi dall'utente in questione. In alternativa, è possibile impostare la shell dell'utente su qualcosa di proprio che consente loro di fare solo ciò che si consente esplicitamente.

Tuttavia, i permessi standard in Linux rendono quasi impossibile per un utente normale "danneggiare il sistema". Che tipo di danno stai cercando di prevenire? È banale impedire agli utenti di installare software o eseguire programmi al di fuori della loro home directory e puoi usare chroot per bloccare ulteriormente il sistema.

Potresti provare [lshell] [1] (shell limitata).

lshell è una shell codificata in Python, che ti consente di limitare l'ambiente di un utente a serie limitate di comandi, scegliere di abilitare / disabilitare qualsiasi comando su SSH (ad esempio SCP, SFTP, rsync, ecc.), registrare i comandi dell'utente, implementare la limitazione di temporizzazione, e altro ancora

[1]: http://lshell.ghantoos.org/Overview lshell

Il modo in cui di solito implemento questo tipo di restrizioni richiede che siano soddisfatte diverse condizioni, altrimenti la restrizione può essere facilmente aggirata:

• L'utente non appartiene al wheelgruppo, l'unico autorizzato ad utilizzare su(applicato tramite PAM).

• All'utente viene fornito un oggetto protetto in modo sicuro rbash con una sola lettura che PATHpunta a un privato ~/bin, questa ~/bin/directory contiene collegamenti a utilità semplici:

  $ ll ~/bin
  total 0
  lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
  lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
  lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
  lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
  lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
  lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
  

• l'utente viene dato un ambiente di sola lettura limitata (si pensi a cose come LESSSECURE, TMOUT, HISTFILEvariabili).

• l'utente viene mappato all'utente SELinux staff_ue gli viene dato il diritto di eseguire comandi come altri utenti come richiesto tramite sudo.

• l'utente /home, /tmpe possibilmente /var/tmpsono polinistanziati tramite /etc/security/namespace.conf:

  /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
  /var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
  $HOME      $HOME/$USER.inst/              tmpdir:create   root
  

  Inoltre, /etc/security/namespace.initrende tutti i file scheletrici di sola lettura per l'utente e di proprietà di root.

In questo modo è possibile scegliere se $USEReseguire qualsiasi comando per proprio conto (tramite un collegamento nella ~/bindirectory privata , eseguito il provisioning tramite /etc/skel, come spiegato sopra), per conto di un altro utente (tramite sudo) o nessuno.

Sì, basta modificare le autorizzazioni per questi comandi.

Potresti avere maggiori possibilità di combattere scrivendo un comando shell che si comporta secondo le tue esigenze.

Cosa non è appropriato delle autorizzazioni predefinite per gli utenti normali su Linux?