Beschränken Sie einen Linux-Benutzer auf die Dateien, deren Eigentümer er ist

Stellen Sie sich eine Serverkonfiguration eines gemeinsam genutzten Webhosting-Unternehmens vor, bei der mehrere (~ 100) Kunden Shell-Zugriff auf einen einzelnen Server haben.

Eine Menge Web "Software" empfiehlt, Dateien 0777 zu chmod . Ich bin nervös, dass unsere Kunden diese Tutorials unklug befolgen und ihre Dateien für unsere anderen Kunden öffnen. (Ich selbst benutze es mit Sicherheit nicht cmod 0777unnötig!) Gibt es eine Methode, um sicherzustellen, dass Kunden nur auf ihre eigenen Dateien zugreifen können und sie daran hindern, auf weltlesbare Dateien anderer Benutzer zuzugreifen?

Ich habe mir AppArmor angeschaut , aber das ist sehr eng mit einem Prozess verbunden, der in dieser Umgebung anscheinend fehlschlägt.

Legen Sie ein eingeschränktes und unveränderliches Verzeichnis zwischen der Außenwelt und den geschützten Dateien ab, z

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

oder /home/joe/restricted/public_html.

Eingeschränkt bedeutet, dass nur der Benutzer und möglicherweise der Webserver es lesen können (z. B. Modi 0700/ 0750oder einige ACLs ).

Unveränderlichkeit kann mit chattr +ioder durch Ändern des Eigentums in etwas wie erfolgen root:joe.

Eine einfache Möglichkeit, diese Hierarchie unter Ubuntu zu erstellen, ist das Bearbeiten /etc/adduser.confund Einstellen GROUPHOMESvon yes.

Möglicherweise möchten Sie eine Option in Betracht ziehen (abhängig davon, wie viel Arbeit Sie dafür leisten möchten).

Wie andere bereits gepostet haben, können Sie "normalerweise" niemanden mit Shell-Zugriff daran hindern, von der Welt lesbare Dateien zu lesen.

Sie können sie jedoch in ihrem eigenen Heim chrooten, indem Sie den Shell-Zugriff grundsätzlich auf das gewünschte Stammverzeichnis (AKA, Home-Verzeichnis) beschränken und zweitens verhindern, dass die Benutzer alles ausführen, was sie nicht ausführen sollen.

Ich habe einen ähnlichen Ansatz gewählt, als ein Benutzer Zugriff auf die Webdateien hatte, aber ich wollte nicht, dass er andere Dateien außerhalb des Webordners sieht.

Dies hatte viel Overhead, war ein Chaos beim Einrichten und jedes Mal, wenn ich etwas aktualisierte, brach es.

Aber für heute denke ich, dass Sie es mit der OpenSSH- Chroot-Option ziemlich einfach erreichen können :

WikiBooks OpenSSH

Ich habe festgestellt, dass POSIX-Zugriffssteuerungslisten es Ihnen als Systemadministrator ermöglichen, Ihre Benutzer vor der schlimmsten Unwissenheit zu schützen, indem Sie die regulären Berechtigungen für Benutzergruppen und andere Dateisysteme außer Kraft setzen, ohne die entscheidenden Probleme zu lösen .

Sie können besonders nützlich sein, wenn Sie beispielsweise möchten, dass Home-Verzeichnisse weltweit zugänglich sind, da Webinhalte für Apache in zugänglich sein müssen ~/public_html/. (Obwohl Sie mit ACLs jetzt das Gegenteil tun können, entfernen Sie den Zugriff für alle und verwenden Sie eine bestimmte effektive ACL für den Apache-Benutzer.)

Ja, ein sachkundiger Benutzer kann sie wieder entfernen / überschreiben, ist nur selten genug, dass dies unwahrscheinlich ist, und die Benutzer, die dies können, sind in der Regel chmod -R 777 ~/sowieso nicht die, die dies bequem tun, oder?

Sie müssen das Dateisystem mit der aclMount-Option mounten:

 mount -o remount,acl /home

In vielen Distributionen werden standardmäßig Benutzergruppen erstellt, jeder Benutzer hat seine primäre Gruppe, und ich habe alle Benutzer in einer sekundären Gruppe mit dem einfallslosen Namen "" festgelegt users.

Mit ACLs ist es jetzt ganz einfach zu verhindern, dass andere Benutzer auf die Basisverzeichnisse zugreifen:

Vor:

 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

Stellen Sie nun die effektiven Verzeichnisberechtigungen für Mitglieder der usersGruppe auf " 0Kein Lesen, Schreiben oder Zugriff" ein:

 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

Das +Vorzeichen zeigt das Vorhandensein von ACL-Einstellungen an. Und das getfaclkann bestätigen:

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

Die group:users:---zeigen, dass Gruppe effektiv kein Zugriffsrecht hat, trotz der regulären Berechtigungen für andere Wesenother::rwx

Und testen als user1:

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

Eine zweite gängige Lösung für gemeinsam genutzte Systeme besteht darin, die Basisverzeichnisse des Automounters bei Bedarf auf einem Server für den Shell-Zugriff bereitzustellen. Das ist alles andere als ein Kinderspiel, aber normalerweise werden nur eine Handvoll Benutzer gleichzeitig angemeldet, was bedeutet, dass nur die Home-Verzeichnisse dieser Benutzer sichtbar und zugänglich sind.

Linux Container (LXC) könnten die beste Kombination aus Chroot und separatem System sein.

1. Sie ähneln eher einer erweiterten Chroot-Umgebung, nicht einer Virtualisierung, aber Sie können verschiedene Betriebssysteme auf einem Server kombinieren.

2. Sie können einem Benutzer ein vollständiges Betriebssystem geben und ihn dort chrooten. Wenn sich der Benutzer anmeldet, wechselt er zu seinem Container. Sie können dort auch die Prozessor- und Speichernutzung einschränken.

Stéphane Graber, der Autor von LXC, hat ein nettes Tutorial , das Ihnen den Einstieg erleichtert.

Wenn Sie beispielsweise möchten, dass der Benutzer nur auf sein eigenes homeVerzeichnis zugreifen kann, sollten Sie Folgendes tun:

cd /home
sudo chmod 700 *

Jetzt /home/usernameist nur für seinen Besitzer sichtbar. Um dies für alle neuen Benutzer zur Standardeinstellung zu machen, bearbeiten Sie diese /etc/adduser.confund setzen Sie sie DIR_MODEauf 0700anstelle der 0755Standardeinstellung.

Wenn Sie den Standard-DIR_MODE ändern möchten, hängt dies natürlich von Ihrer Distribution ab, an der ich gearbeitet habe Ubuntu.

bearbeiten

Wie @Dani_l richtig sagte , ist diese Antwort richtig, um sie NICHT für die ganze Welt lesbar zu machen.

Nur um pedantisch zu sein - Nein, gibt es nicht.
@Marek gab eine richtige Antwort , aber Ihre Frage ist falsch - man kann nicht verhindern , dass jemand von „Welt lesbar“ Dateien zugreifen.
Entweder sind sie von der Welt lesbar oder nicht. @ Mareks Antwort ist richtig, sie NICHT für die ganze Welt lesbar zu machen.

Ich sehe keine Erwähnung der "eingeschränkten Shell" in den bisher gegebenen Antworten.

ln / bin / bash / bin / rbash

Legen Sie dies als Login-Shell fest.

Wenn der Webserver für jede gehostete Domäne als derselbe Benutzer und dieselbe Gruppe ausgeführt wird, ist es schwierig (wenn nicht unmöglich), die Einrichtung sicher zu machen.

Sie möchten, dass bestimmte Dateien sowohl für den Benutzer als auch für den Webserver zugänglich sind, jedoch nicht für andere Benutzer. Sobald der Webserver darauf zugreifen kann, kann ein anderer Benutzer sie lesen, indem er einen Symlink zu der Datei auf seiner eigenen Website erstellt.

Wenn Sie dafür sorgen können, dass jede Website als separater Benutzer ausgeführt wird, ist dies recht einfach. Jeder Kunde hat nun zwei Benutzer im System, einen für den Webserver und einen für den Shell-Zugriff.

Erstellen Sie eine Gruppe mit diesen beiden Benutzern. Erstellen Sie nun ein Verzeichnis mit dieser Gruppe und dem Benutzer root. Dieses Verzeichnis sollte über Berechtigungen verfügen 750, dh root hat vollständigen Zugriff und die Gruppe hat Lese- und Ausführungszugriff. In diesem Verzeichnis können Sie Ausgangsverzeichnisse für jeden der beiden Benutzer erstellen. Dies bedeutet, dass das Basisverzeichnis des Benutzers nicht mehr das Formular hat /home/username, sondern etwas mit mindestens einer weiteren Verzeichniskomponente. Dies ist kein Problem. Es ist nicht erforderlich, dass Basisverzeichnisse gemäß dieser speziellen Konvention benannt werden.

Es kann schwierig sein, Websites mit unterschiedlichen Benutzern und Gruppen zum Laufen zu bringen, wenn Sie namenbasierte vhosts verwenden. Sollte sich herausstellen, dass Sie die Trennung nur mit IP-basierten vhosts durchführen können und nicht über genügend IPs für jeden Standort verfügen, können Sie jede Website unter einer IPv6-Adresse hosten und einen Reverse-Proxy für alle von ihnen auf eine setzen IPv4-Adresse.