Limitare un utente Linux ai file che possiede

24

Immagina una configurazione server di una società di web hosting condivisa in cui più (~ 100) clienti hanno accesso shell a un singolo server.

Molti "software" web raccomandano di chmod file 0777 . Sono nervoso per i nostri clienti che seguono inconsapevolmente questi tutorial, aprendo i loro file agli altri clienti. (Certamente non sto usando cmod 0777inutilmente me stesso!) Esiste un metodo per assicurarsi che i clienti possano accedere solo ai propri file e impedire loro di accedere a file leggibili da altri utenti?

Ho esaminato AppArmor , ma questo è strettamente associato a un processo, che sembra fallire in quell'ambiente.

— Phillipp
fonte

12

Vorrei in realtà considerare se le raccomandazioni del "software Web" chmod files 0777siano strettamente necessarie, vale a dire affrontare la causa principale del problema, piuttosto che il sintomo che, così facendo, chiunque può leggere i file di qualcun altro. Molte volte la raccomandazione di consentire tutti gli accessi è semplicemente un modo economico per evitare le chiamate di supporto o la mancanza di abilità tecnica nel riuscire a impostare correttamente le autorizzazioni. In quasi nessun caso ho dovuto impostare file 0777o concedere alle applicazioni l'accesso root completo quando richiesto. L'educazione degli utenti e / o dei venditori aiuta enormemente qui.

— Cosmic Ossifrage,

3

@CosmicOssifrage, gli utenti non possono essere educati così facilmente, non vogliono leggere istruzioni o manuali.

— Cristian Ciupitu,

12

Qualsiasi "software Web" che raccomanda ancora autorizzazioni 777 deve essere rimosso e girato . Utilizzare suexeco mpm_itko simili.

— Shadur,

3

@CosmicOssifrage Non credo che Phillipp stia dicendo o forzando gli utenti ai chmod 0777loro file. Penso che sia nervoso per il fatto che vanno loltoturialz.com/php_problemse si mettono chmod 0777da soli mentre seguono ciecamente un articolo scritto male. Non c'è davvero alcun modo per impedire loro di farlo, o per impedire loro di essere arrabbiati quando qualcuno ruba le loro cose.

— Kevin - Ripristina Monica l'

2

@kevin: ecco perché è stato creato il nulla di garanzia. Non ho quasi mai visto un dispositivo serio (sia esso un software compilato, un mucchio di script o quant'altro) senza una clausola del genere. E che ci crediate o no - nella maggior parte degli ambienti corretti gli utenti ne sono ben consapevoli

— Dani_l

34

Inserisci una directory limitata e immutabile tra il mondo esterno e i file protetti, ad es

/
 ├─ bin
 ├─ home
 │  └─ joe <===== restricted and immutable
 │     └─ joe <== regular home directory

oppure /home/joe/restricted/public_html.

Limitato significa che solo l'utente e forse il web server possono leggerlo (ad es. Modalità 0700/ 0750o alcuni ACL ).

L'immutabilità può essere fatta con chattr +io cambiando la proprietà in qualcosa del genere root:joe.

Un modo semplice per creare la gerarchia su Ubuntu potrebbe essere quella di modificare /etc/adduser.confe impostare GROUPHOMESa yes.

— Cristian Ciupitu
fonte

15

C'è un'opzione che potresti voler considerare (a seconda di quanto lavoro vuoi fare per quello).

Come altri hanno già pubblicato, "normalmente" non puoi impedire a qualcuno con accesso alla shell di leggere file leggibili in tutto il mondo.

Tuttavia, è possibile eseguirne il chroot nella propria home, limitando sostanzialmente l'accesso alla shell, in primo luogo, solo alla directory principale desiderata (AKA la directory home) e, in secondo luogo, impedire agli utenti di eseguire tutto ciò che non si desidera venga eseguito.

Ho avuto un approccio simile quando avevo un utente per accedere ai file web, ma non volevo che vedesse altri file all'esterno della cartella web.

Questo aveva un sacco di spese generali, era un disastro da configurare e ogni volta che aggiornavo qualcosa, si rompeva.

Ma per oggi penso che potresti ottenerlo abbastanza facilmente con l' opzione chroot OpenSSH :

WikiBooks OpenSSH

— Dennis Nolte
fonte

chroot per SFTP è facile da implementare, ma non sono sicuro che sia così facile per l'accesso alla shell. Dovresti impostare un chroot con tutti i binari e le librerie per ciascun utente.

— Cristian Ciupitu,

2

Questa è specifica per l'implementazione. ARCHLINUX ha uno specifico comando arch-chroot che si occupa di tutti i mount di bind extra ecc. Wiki.archlinux.org/index.php/Change_Root#Change_root

— Dani_l

@CristianCiupitu è quello che ho fatto, consentendo solo un sottoinsieme specifico di comandi con il collegamento di tutte le librerie di nessesary, ecco perché ho detto che era un disastro :) Dani_l vero, la mia installazione era un server debian, non ho mai avuto il tempo di controllare gentoo tristemente .

— Dennis Nolte,

@Dani_l: che dire dei pacchetti installati? Il arch-chrootcomando non sembra coprirlo. E poi c'è anche il problema dello spazio su disco sprecato con tutti i duplicati. Non sto dicendo che è impossibile farlo, solo che al momento potrebbe essere un po 'più complicato.

— Cristian Ciupitu,

1

Qualcosa per rendere questo un -lot- più semplice è usare UnionFS per chroot gli utenti in una speciale unione dei rootfs in modalità di sola lettura e in una directory di lettura in scrittura, questo significa che vedono tutti i pacchetti di sistema e i binari ma le scritture vengono eseguite automaticamente in la loro cartella principale. questo - deve essere abbinato alla creazione di tutte le home directory di 700 autorizzazioni, altrimenti gli utenti potrebbero comunque leggere i file di altri utenti.

— Valità,

11

Ho scoperto che gli elenchi di controllo degli accessi POSIX consentono a te, come amministratore di sistema, di proteggere i tuoi utenti dal peggio della loro stessa ignoranza, sovrascrivendo le normali autorizzazioni del file system di altri gruppi di utenti, senza molta possibilità di violare qualcosa di cruciale .

Possono essere particolarmente utili se per esempio (fi) avevi bisogno delle home directory per essere accessibili in tutto il mondo perché il contenuto web deve essere accessibile per apache ~/public_html/. (Anche se con gli ACL puoi ora fare il contrario, rimuovere l'accesso per tutti e usare un ACL specifico specifico per l'utente apache.)

Sì, un utente esperto può rimuoverli / sovrascriverli di nuovo, sono abbastanza rari da essere improbabili e quegli utenti che in genere non sono quelli che possono essere convenientemente chmod -R 777 ~/, giusto?

Devi montare il filesystem con l' aclopzione mount:

 mount -o remount,acl /home

In molte distribuzioni il valore predefinito è creare gruppi di utenti, ogni utente ha il proprio gruppo primario e ho impostato tutti gli utenti in un gruppo secondario con il nome privo di fantasia di users.

Utilizzando ACL è ora banale impedire ad altri utenti di accedere alle home directory:

Prima:

 chmod 0777 /home/user* 

 ls -l /home/user*
 drwxrwxrwx.  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx.  2 user2  user2  4096 Jul 11 15:24 user2

Ora imposta le autorizzazioni di directory effettive per i membri del usersgruppo su 0nessuna lettura, scrittura o accesso:

 setfacl setfacl -m g:users:0 /home/user*

 ls -l 
 drwxrwxrwx+  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx+  2 user2  user2  4096 Jul 11 15:24 user2

Il +segno indica la presenza di impostazioni ACL lì. E getfaclpuò confermare che:

getfacl /home/user1
getfacl: Removing leading '/' from absolute path names
# file: home/user1
# owner: user1
# group: user1
user::rwx
group::rwx
group:users:---
mask::rwx
other::rwx

Lo group:users:---spettacolo quel gruppo effettivamente non ha diritto di accesso, nonostante le normali autorizzazioni per gli altriother::rwx

E test come utente1:

[user1@access ~]$ ls -la /home/user2
ls: cannot open directory /home/user2: Permission denied

Una seconda soluzione comune sui sistemi condivisi è quella di avere le case home montate su automounter su richiesta e un server dedicato all'accesso alla shell. Questo è tutt'altro che infallibile, ma in genere solo una manciata di utenti verrà loggata contemporaneamente, il che significa che solo le home directory di quegli utenti sono visibili e accessibili.

— HBruijn
fonte

5

Che cos'è "fi" ? Non consiglierei l'uso di acronimi o abbreviazioni a meno che non siano classici come "eg", "ie", "etc" e forse OP.

— Cristian Ciupitu,

3

Linux Containers (LXC) potrebbe essere la migliore combinazione di chroot e sistema separato.

Sono più simili a un chroot avanzato, non alla virtualizzazione, ma è possibile combinare diversi sistemi operativi in un server.
Puoi dare a un utente un sistema operativo completo e chroot lì, quindi quando l'utente accede, va nel suo contenitore. E puoi anche limitare l'utilizzo del processore e della memoria lì.

Stéphane Graber, l'autore di LXC, ha un bel tutorial per aiutarti a iniziare.

— maniaque
fonte

Non puoi davvero combinare diversi sistemi operativi, perché tutti hanno bisogno di usare il kernel Linux , ma puoi usare diverse distribuzioni .

— Cristian Ciupitu,

1

Grazie :) Sì, diversi sistemi operativi basati su kernel Linux.

— maniaque,

@CristianCiupitu intendi lo stesso identico kernel Linux? o vuoi dire che ogni contenitore può avere una versione diversa del kernel?

— agks mehx,

@agksmehx, tutti i contenitori LXC condividono il kernel dell'host . Vengono utilizzate solo le loro applicazioni e librerie. Quindi, ad esempio, se si dispone di un host RHEL 7 con un contenitore Ubuntu 14.04, verrà utilizzato il kernel RHEL (3.10.0-123), mentre quello Ubuntu (3.13.0-24.46) non verrà utilizzato; leggi anche questo commento dal tutorial. A proposito, poiché i kernel dei contenitori non vengono utilizzati, potrebbe essere una buona idea rimuoverli per risparmiare spazio su disco.

— Cristian Ciupitu,

@CristianCiupitu è quello che pensavo. non era chiaro dalla risposta o dal commento, quindi volevo chiarire.

— agks mehx il

3

Ad esempio, se si desidera che l'utente abbia accesso solo alla propria homedirectory, è necessario:

cd /home
sudo chmod 700 *

Ora /home/usernameè visibile solo al suo proprietario. Per rendere questo il valore predefinito per tutti i nuovi utenti, modificare /etc/adduser.confe insieme DIR_MODEal 0700posto del 0755default.

Naturalmente, se vuoi modificare il DIR_MODE predefinito, dipende dalla tua distribuzione, quella su cui ho pubblicato funziona Ubuntu.

modificare

Come correttamente menzionato @Dani_l , questa risposta è corretta nel renderli NON leggibili dal mondo.

— Marek
fonte

Sono chiamati "leggibili dal mondo" per un motivo.

— Mark K Cowan,

1

@DennisNolte In realtà, aiuta, anche se i file sono leggibili da tutti, se si trovano in una directory che non hai né letto né eseguito su di te, non puoi comunque leggerli.

— Vality,

1

@Valità vera, rimuovendo il mio commento perché è chiaramente sbagliato.

— Dennis Nolte,

2

Solo per essere pedanti - No, non c'è.
@Marek ha dato una risposta corretta , ma la tua domanda non è corretta: non puoi impedire a nessuno di accedere a file "leggibili dal mondo".
O sono leggibili dal mondo o non lo sono. La risposta di @ Marek è corretta nel renderli NON leggibili dal mondo.

— Dani_l
fonte

2

sbagliato, chroot / jailing l'utente in una sottocartella e non è in grado di leggere file "normalmente" leggibili in tutto il mondo.

— Dennis Nolte,

1

-1 Penso che tu sia inutilmente critico verso la domanda del PO. Vuole offrire ai suoi clienti una rete di sicurezza nel caso in cui non siano intelligenti riguardo alle loro autorizzazioni. Ma non mi sembra che l'OP non sia a conoscenza del funzionamento delle autorizzazioni dei file Unix o dei principi di sicurezza di base.

— Kevin - Ripristina Monica l'

Inoltre, puoi inserire i file in una directory all'interno di una directory di 000 autorizzazioni, quindi nessuno può accedervi anche se i file sono leggibili dal mondo.

— Valità,

nessuno? nemmeno root? ;-)

— Dani_l

@Kevin ha convenuto che il mio commento è stato criticato da vicino a inutili. Comunque Dani_I non dovrei far capire che è pedandico e sbagliato. Non affermando che non sono d'accordo con il resto della sua risposta.

— Dennis Nolte,

0

Non vedo alcuna menzione del "guscio limitato" nelle risposte fornite finora.

ln / bin / bash / bin / rbash

Impostalo come shell di login.

— bbaassssiiee
fonte

0

Se il server Web è in esecuzione con lo stesso utente e gruppo per ogni dominio ospitato, è difficile (se non impossibile) rendere sicura l'installazione.

Si desidera che determinati file siano accessibili all'utente e al server Web, ma non ad altri utenti. Ma non appena il server Web può accedervi, un altro utente potrebbe leggerli inserendo un link simbolico al file all'interno del proprio sito Web.

Se riesci a far funzionare ciascun sito web come utente separato, allora diventa abbastanza semplice. Ogni cliente avrà ora due utenti nel sistema, uno per il server Web e uno per l'accesso alla shell.

Crea un gruppo contenente questi due utenti. Ora crea una directory con quel gruppo e l'utente root. Tale directory dovrebbe avere autorizzazioni 750, il che significa che root ha pieno accesso e il gruppo ha accesso in lettura ed esecuzione. All'interno di quella directory è possibile creare home directory per ciascuno dei due utenti. Ciò significa che la home directory dell'utente non avrà più il modulo /home/username, ma piuttosto qualcosa con almeno un altro componente di directory. Questo non è un problema, nulla richiede che le home directory siano nominate secondo quella specifica convenzione.

Far funzionare i siti Web con utenti e gruppi diversi può essere complicato, se si utilizzano vhosts basati sul nome. Se si scopre che è possibile far funzionare la separazione solo con vhosts basati su IP e non si dispone di IP sufficienti per ciascun sito, è possibile ospitare ciascun sito Web su un indirizzo IPv6 e inserire un proxy inverso per tutti loro su un Indirizzo IPv4.

— kasperd
fonte