Concedi all'utente l'accesso in lettura / scrittura a una sola directory

Sto eseguendo un server e devo dare accesso in lettura / scrittura a una determinata directory a un singolo utente. Ho provato quanto segue:

sudo adduser abcd
sudo groupadd abcdefg
chown -R .abcdefg /var/www/allowfolder
chmod -R g+rw /var/www/allowfolder
usermod -a -G comments abcd

Quanto sopra sembra funzionare, tuttavia offre all'utente l'accesso in sola lettura al resto del server.

Come posso impostare le autorizzazioni in modo che l'utente possa solo leggere e scrivere in una cartella particolare? L'utente dovrebbe anche essere in grado di eseguire programmi come mysql.

permissions files account-restrictions

— Manishearth
fonte

La risposta breve: usa un chroot.

— Chris Down,

@Chris Care per approfondire questo in una risposta? Manish e io abbiamo lottato con questo e sembra non riuscire a farlo funzionare.

— Annulla il

Dove sarebbe mysqlsituato il programma? L'utente deve essere in grado di leggerlo e tutte le librerie e i file di dati di cui ha bisogno.

— Gilles 'SO- smetti di essere malvagio' il

@Gilles Hmm. È un'installazione mysql standard di apt-get, per quanto ne so (non il mio sistema, è di Undo).

— Manishearth,

Risposte:

ACL negativi

È possibile impedire a un utente di accedere ad alcune parti del filesystem impostando gli elenchi di controllo di accesso . Ad esempio, per garantire che l'utente abcdnon possa accedere a nessun file in /home:

setfacl -m user:abcd:0 /home

Questo approccio è semplice, ma è necessario ricordare di bloccare l'accesso a tutto ciò a cui non si desidera abcdpoter accedere.

chroot

Per ottenere un controllo positivo su ciò che abcdpuò vedere, imposta un chroot , ovvero limita l'utente a una sottostruttura del filesystem.

È necessario creare tutti i file necessari all'utente (ad es. mysqlE tutte le sue dipendenze, se si desidera che l'utente sia in grado di eseguire mysql) sotto il chroot. Dire che il percorso per il chroot è /home/restricted/abcd; il mysqlprogramma deve essere disponibile sotto /home/restricted/abcd. Un collegamento simbolico che punta all'esterno del chroot non è utile perché la ricerca del collegamento simbolico è influenzata dal carcere chroot. Sotto Linux, puoi fare buon uso dei mount bind:

mount --rbind /bin /home/restricted/abcd/bin
mount --rbind /dev /home/restricted/abcd/dev
mount --rbind /etc /home/restricted/abcd/dev
mount --rbind /lib /home/restricted/abcd/lib
mount --rbind /proc /home/restricted/abcd/proc
mount --rbind /sbin /home/restricted/abcd/sbin
mount --rbind /sys /home/restricted/abcd/sys
mount --rbind /usr /home/restricted/abcd/usr

Puoi anche copiare i file (ma dovrai quindi assicurarti che siano aggiornati).

Per limitare l'utente al chroot, aggiungi una ChrootDirectorydirettiva a /etc/sshd_config.

Match User abcd
    ChrootDirectory /home/restricted/abcd

Puoi provarlo con: chroot --userspec=abcd /home/restricted/abcd/ /bin/bash

Quadro di sicurezza

È inoltre possibile utilizzare framework di sicurezza come SELinux o AppArmor. In entrambi i casi, devi scrivere una configurazione abbastanza delicata, per assicurarti di non lasciare buchi.

— Gilles 'SO- smetti di essere malvagio'
fonte

Non è possibile creare un modo molto più semplice per fornire autorizzazioni di lettura e scrittura a una directory specifica? Ad esempio, potrebbe creare un nuovo gruppo e utilizzare chown per rendere il proprietario del gruppo di directory il gruppo creato e aggiungere l'utente al gruppo. Infine, dai alla directory le autorizzazioni di lettura e scrittura per i gruppi.

— Qasim

@Qasim Ciò richiede che tutti i file abbiano le autorizzazioni e la proprietà impostate come desiderato. Ci sono così tante cose che possono andare storte (file copiati da altrove o estratti da un archivio con le loro autorizzazioni conservate, file che devono appartenere a un altro gruppo, file che non dovrebbero essere leggibili in gruppo, utenti che commettono errori o possono " essere disturbato per assicurarsi che l'accessibilità del gruppo rimanga come desiderato ...) che i gruppi non risolvano davvero questo problema.

— Gilles 'SO- smetti di essere malvagio' il

Voglio dire, non vedo come i file dovrebbero avere le proprie autorizzazioni se le autorizzazioni di gruppo sulla directory fossero impostate in modo tale che nessun utente potesse "cd" nella directory o "ls" nella directory.

— Qasim

@Qasim Ogni file in /var/www/allowfoldere le sue sottodirectory deve essere accessibile, non solo /var/www/allowfolderse stesso. E viceversa altri file non devono essere accessibili. In effetti una soluzione basata esclusivamente sulle autorizzazioni per i file e ACL non può soddisfare completamente i requisiti: consentirebbe almeno all'utente di verificare se esiste un determinato nome /var/www, poiché devono disporre dell'autorizzazione x /var/wwwper accedere /var/www/allowfolder.

— Gilles 'SO- smetti di essere malvagio' il

Oh ok capisco, ma se escludiamo la directory / var da questa e diciamo che stiamo parlando di una directory normale nella directory / home / user?

— Qasim

Si dovrebbe usare chroot. Il chrootcomando modifica la directory principale che viene visualizzata da tutti i processi figlio. Fornirò un esempio per dimostrare come funziona.

Questo è stato scritto sul posto; Al momento non sono di fronte a una macchina UNIX. In questo esempio, c'è una directory chiamata dircon tre file: a, b, c, e ls. I primi tre sono file regolari. lsè un collegamento reale al vero lsbinario in modo che possiamo elencare i file mentre ci troviamo nel chroot.

Ho intenzione di chrootin dir. (Nota che probabilmente sto dimenticando alcune directory nella directory principale.)

Ecco la configurazione, nel modulo di output della shell:

$ pwd
/home/alex/test
$ l
dir
$ ls dir
a b c ls
$ ./ls dir # does the same thing
a b c ls
$ ls /
bin boot dev etc home mnt media proc sbin sys usr var

Ora sarò chrootin dir. L' /bin/bashargomento sceglie quale processo deve essere eseguito con la nuova directory principale. L'impostazione predefinita è /bin/sh.

$ chroot /bin/bash dir
$ # this prompt is now from a subprocess running in the new root directory
$ PATH=/ ls
a b c ls
$ pwd
/

Ora usciamo da chroot:

$ exit
$ # this prompt is now from the original bash process, from before the chroot
$ pwd
/home/alex/test

Spero che questo illustri come funziona il chrootcomando. Fondamentalmente quello che devi fare per risolvere il tuo problema è eseguire un chrootcomando come quell'utente ogni volta che effettuano il login. Forse metterlo in uno script di avvio?

Un hardlink a un file continuerà a funzionare all'interno di a chroot, anche se quel file non è accessibile con altri mezzi (questo funziona perché i hardlink puntano a inode, non a percorsi). Pertanto, per consentire all'utente di accedere ad esempio al mysqlcomando, è necessario eseguire:

ln /usr/bin/mysql /path/to/chroot/target

— strugee
fonte

Ma questo non mi richiederebbe di impostare un intero ambiente chroot con tutti i collegamenti simbolici? Non sarebbe più semplice eseguire un comando in modo che il nuovo utente non abbia accesso alle altre directory, ma programmi come Apache non perdano l'accesso ad esse?

— Manishearth,

Fondamentalmente, c'è un modo (tramite chmod) di far perdere l'accesso in lettura al resto della fs da parte di un utente senza influire sull'accesso di altri utenti?

— Manishearth,

@Manishearth non c'è modo semplice con chmod. quando dici "non sarebbe più facile eseguire un comando ... non perdere l'accesso ad essi", quel comando è chroot. se spieghi cosa intendi per "un intero ambiente chroot", o perché questo sarebbe un problema, forse capirò meglio. (notare che è possibile dare accesso a tutti i file eseguibili con un oneliner: ln /bin/* /path/to/chroot/target)

— strugee

@Manishearth se il mio esempio non avesse senso, ti incoraggio a giocare con chrootte stesso o fammi sapere cosa non aveva senso. ancora meglio, fai entrambe le cose. (e leggi le manpage.)

— strugee

@Manishearth se questa risposta ti ha aiutato sufficientemente a condurti alla risposta, dovresti considerare di accettarla.

— Strugee,