crea chroot utente al primo login

Sto utilizzando ldap per l'authentication dell'utente remoto e ho fondamentalmente bisogno di capire come:

un. chroot un utente sulla macchina b dalla macchina a via nfs (che non sembra ansible senza installare più directory rispetto a me)

  • squid: imansible connettersi a peer con tcp_outgoing_address
  • Dare un process un nome specifico in GNU / Linux?
  • Perché ntpd ascolta su così tante porte / indirizzi?
  • Perché il mio utente Postgres non dispone di autorizzazioni per aggiungere un database Postgres?
  • L'operazione mkfs prende molto tempo sul software Raid 5 di Linux
  • samba + openldap vs annuncio per la networking di medie size
  • o ——-

    b. Dopo aver aggiunto un utente al db ldap sulla macchina a, forzare uno script da eseguire sulla macchina b durante l'accesso degli utenti che verrà automaticamente chroot l'utente prima che essi siano autorizzati a fare qualsiasi cosa al loro primo accesso.


    Penso che la mia seconda opzione sia probabilmente la migliore scommessa e stava pensando lungo le linee di utilizzo di pam_exec.so per call lo script. Tuttavia, ho alcune preoccupazioni su questo approccio. In primo luogo, non sono sicuro se lo script che verrà eseguito avrà le autorizzazioni di root che avrà bisogno per eseguire il chroot. In secondo luogo, non sono sicuro se pam_exec succede abbastanza presto nel process di login per essere un'opzione efficace. Infine, devo assicurarmi che il codice funziona sia in pam.d / ssh che in pam.d / su per considerarlo una soluzione valida.

    Sono le mie preoccupazioni valide o sembra che questa sarebbe una buona soluzione? Oppure c'è un approccio migliore a questo problema.

    One Solution collect form web for “crea chroot utente al primo login”

    Innanzitutto, probabilmente, il chroot potrebbe non essere considerato una funzionalità di sicurezza . Ci sono opinioni anche nell'altra direzione .

    Probabilmente, ciò che è necessario implementare è un metodo ripetibile e verificabile per limitare la capacità dell'utente di eseguire azioni diverse da quelle strettamente consentite.

    Se registri i tuoi utenti in LDAP, sicuramente hai già distribuito i meccanismi per eseguire l'authentication LDAP su qualsiasi macchina collegata a questo LDAP, sia tramite sssd che utilizzando qualsiasi altro module PAM, non è pertinente per il resto della soluzione , e si suppone che sia già in atto (nel mio caso, sto usando freeIPA e sssd ).

    Per attuare questo scenario, quello che faccio adesso è il seguente (tenere presente che questo tipo di restrizioni richiede che siano soddisfatte diverse condizioni, altrimenti la restrizione può essere facilmente aggirata):

    • Gli utenti non appartengono al gruppo wheel , l'unica autorizzata ad utilizzare su (forzata tramite PAM). Di solito, un utente non LDAP ( sysadm ) esiste per consentire agli amministratori attendibili di eseguire azioni nei casi di disaster recovery o LDAP non disponibile.
    • Gli utenti sono dotati di un rbash correttamente protetto con un PATH di sola lettura che indica un ~/bin privato, questa directory ~/bin/ contiene i collegamenti a tutti i comandi consentiti, ad esempio:

       $ 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* 
    • gli utenti sono dotati di un ambiente limitato, di sola lettura (pensi a cose come LESSSECURE , TMOUT , variables HISTFILE ). Ciò significa evitare shell fughe di shell da comandi come less o vim .

    • se le restrizioni MAC sono in atto (la distribuzione GNU / Linux specifica che utilizza è abilitata SELinux), gli utenti vengono mappati all'utente SELinux staff_u e hanno dato i diritti per eseguire i comandi come altri utenti come richiesto tramite sudo . Le particolarità consentite devono essere attentamente riesaminate per impedire all'utente di eludere queste limitazioni e può anche essere implementata nell'infrastruttura LDAP esistente (questa è una delle funzionalità freeIPA).
    • gli utenti /home , /tmp e eventualmente /var/tmp sono poliststizzati 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 

      La moltiplicazione delle directory non è una nuova funzionalità, è stata disponibile da molto tempo. Come riferimento, vedere questo articolo dal 2006 . Di fatto, molti moduli già utilizzano pam_namespace per impostazione predefinita, ma la configuration predefinita in /etc/security/namespace.conf non consente la polistntanizzazione. Inoltre, /etc/security/namespace.init dovrebbe rendere tutti i file scheletrici solo di lettura per gli utenti e di properties; di root .

    In questo modo è ansible scegliere se gli utenti possono eseguire qualsiasi command per conto proprio (tramite un collegamento nella directory privata ~/bin , fornito tramite /etc/skel , come sopra spiegato), per conto di altri utenti (via sudo ) o proprio nessuno.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.