Restreindre un utilisateur Linux aux fichiers qu'il possède

Imaginez une configuration de serveur d'une société d'hébergement Web partagée où plusieurs (~ 100) clients ont un accès shell à un seul serveur.

Beaucoup de "logiciels" web recommandent de chmod les fichiers 0777 . Je suis nerveux à l'idée que nos clients suivent ces tutoriels de manière imprudente, ouvrant leurs fichiers à nos autres clients. (Je n'utilise certainement pas cmod 0777moi-même inutilement!) Existe-t-il une méthode pour s'assurer que les clients ne peuvent accéder qu'à leurs propres fichiers et les empêcher d'accéder aux fichiers lisibles par le monde à partir d'autres utilisateurs?

J'ai examiné AppArmor , mais cela est très étroitement lié à un processus qui semble échouer dans cet environnement.

Mettez un répertoire restreint et immuable entre le monde extérieur et les fichiers protégés, par exemple

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

ou /home/joe/restricted/public_html.

Restreint signifie que seul l'utilisateur et peut-être le serveur Web peuvent le lire (par exemple, les modes 0700/ 0750ou certaines ACL ).

L'immuabilité peut se faire avec chattr +iou en changeant la propriété en quelque chose comme root:joe.

Un moyen facile de créer cette hiérarchie sur Ubuntu serait de modifier /etc/adduser.confet de définir GROUPHOMESsur yes.

Il y a une option que vous voudrez peut-être envisager (selon la quantité de travail que vous voulez faire pour cela).

Comme d'autres l'ont déjà signalé, «normalement», vous ne pouvez pas empêcher une personne disposant d'un accès shell de lire des fichiers lisibles par tous.

Cependant, vous pouvez les chrooter dans leur propre maison, limitant fondamentalement l'accès shell à, premièrement, uniquement le répertoire racine que vous voulez (AKA le répertoire personnel) et, deuxièmement, empêcher les utilisateurs d'exécuter tout ce que vous ne voulez pas qu'ils exécutent.

J'ai fait une approche similaire lorsque j'avais un utilisateur pour avoir accès aux fichiers Web, mais je ne voulais pas qu'il voit d'autres fichiers en dehors du dossier Web.

Cela avait beaucoup de frais généraux, était un gâchis à configurer, et chaque fois que je mettais à jour quelque chose, il se cassait.

Mais pour aujourd'hui, je pense que vous pourriez y arriver assez facilement avec l' option chroot OpenSSH :

WikiBooks OpenSSH

J'ai trouvé que les listes de contrôle d'accès POSIX permettaient à vous, en tant qu'administrateur système, de protéger vos utilisateurs du pire de leur propre ignorance, en remplaçant l'autorisation régulière du système de fichiers d'un autre groupe d'utilisateurs, sans beaucoup de chance de casser quelque chose de crucial .

Ils peuvent être particulièrement utiles si, par exemple (fi), vous avez besoin que les répertoires personnels soient accessibles à tous, car le contenu Web doit être accessible pour apache dans ~/public_html/. (Bien qu'avec les ACL, vous pouvez maintenant faire l'inverse, supprimer l'accès pour tous et utiliser une ACL efficace spécifique pour l'utilisateur apache.)

Oui, un utilisateur averti peut à nouveau les supprimer / remplacer, est assez rare pour que ce soit improbable, et les utilisateurs qui ne le sont généralement pas de chmod -R 777 ~/toute façon, n'est-ce pas?

Vous devez monter le système de fichiers avec l' acloption de montage:

 mount -o remount,acl /home

Dans de nombreuses distributions, la valeur par défaut est de créer des groupes d'utilisateurs, chaque utilisateur a son groupe principal et j'ai défini tous les utilisateurs dans un groupe secondaire avec le nom sans imagination de users.

À l'aide des ACL, il est désormais trivial d'empêcher d'autres utilisateurs d'accéder aux répertoires personnels:

Avant:

 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

Définissez maintenant les autorisations de répertoire effectives pour les membres du usersgroupe sur 0aucune lecture, écriture ou accès:

 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

Le +signe indique la présence de paramètres ACL à cet endroit. Et le getfaclpeut confirmer que:

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

Le group:users:---spectacle que le groupe n'a effectivement aucun droit d'accès, malgré les autorisations régulières pour les autresother::rwx

Et tester en tant qu'utilisateur1:

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

Une deuxième solution courante sur les systèmes partagés consiste à avoir les répertoires de base de montage automatique à la demande et un serveur dédié à l'accès shell. C'est loin d'être infaillible, mais en général, seule une poignée d'utilisateurs seront connectés simultanément, ce qui signifie que seuls les répertoires personnels de ces utilisateurs sont visibles et accessibles.

Les conteneurs Linux (LXC) pourraient être la meilleure combinaison de chroot et de système séparé.

1. Ils ressemblent plus à un chroot avancé, pas à la virtualisation, mais vous pouvez combiner différents systèmes d'exploitation sur un serveur.

2. Vous pouvez donner à un utilisateur un système d'exploitation complet et le chrooter, donc lorsque l'utilisateur se connecte, il va dans son conteneur. Et vous pouvez également y limiter l'utilisation du processeur et de la mémoire.

Stéphane Graber, l'auteur de LXC, a un joli tutoriel pour vous aider à démarrer.

Par exemple, si vous souhaitez que l'utilisateur n'ait accès qu'à son propre homerépertoire, vous devez:

cd /home
sudo chmod 700 *

Désormais /home/usernamevisible uniquement par son propriétaire. Pour en faire la valeur par défaut pour tous les nouveaux utilisateurs, modifiez /etc/adduser.confet définissez sur DIR_MODEau 0700lieu de la 0755valeur par défaut.

Bien sûr, si vous souhaitez modifier le DIR_MODE par défaut, cela dépend de votre distribution, celle sur laquelle je posté fonctionne Ubuntu.

modifier

Comme @Dani_l l'a correctement mentionné, cette réponse est correcte en les rendant NON lisibles par tout le monde.

Juste pour être pédant - Non, il n'y en a pas.
@Marek a donné une réponse correcte , mais votre question est incorrecte - vous ne pouvez empêcher personne d'accéder à des fichiers "lisibles par le monde".
Soit ils sont lisibles par le monde, soit ils ne le sont pas. @ La réponse de Marek est correcte en les rendant NON lisibles par le monde.

Je ne vois aucune mention de la «coquille restreinte» dans les réponses données jusqu'à présent.

ln / bin / bash / bin / rbash

Définissez-le comme shell de connexion.

Si le serveur Web fonctionne avec le même utilisateur et groupe pour chaque domaine hébergé, il est difficile (voire impossible) de sécuriser la configuration.

Vous souhaitez que certains fichiers soient accessibles à l'utilisateur ainsi qu'au serveur Web, mais pas aux autres utilisateurs. Mais dès que le serveur Web peut y accéder, un autre utilisateur peut les lire en plaçant un lien symbolique vers le fichier dans son propre site Web.

Si vous pouvez faire fonctionner chaque site Web en tant qu'utilisateur distinct, cela devient assez simple. Chaque client aura désormais deux utilisateurs sur le système, un pour le serveur Web et un pour l'accès au shell.

Créez un groupe contenant ces deux utilisateurs. Créez maintenant un répertoire avec ce groupe et cette racine utilisateur. Ce répertoire doit avoir des autorisations 750, ce qui signifie que root a un accès complet et que le groupe a un accès en lecture et en exécution. À l'intérieur de ce répertoire, vous pouvez créer des répertoires personnels pour chacun des deux utilisateurs. Cela signifie que le répertoire personnel de l'utilisateur n'aura plus la forme /home/username, mais plutôt quelque chose avec au moins un composant de répertoire supplémentaire. Ce n'est pas un problème, rien ne nécessite que les répertoires personnels soient nommés selon cette convention spécifique.

Il peut être difficile de faire fonctionner des sites Web avec différents utilisateurs et groupes si vous utilisez des vhosts basés sur le nom. S'il s'avère que vous ne pouvez effectuer la séparation qu'avec des vhosts basés sur IP et que vous n'avez pas suffisamment d'adresses IP pour chaque site, vous pouvez héberger chaque site Web sur une adresse IPv6 et mettre un proxy inverse pour chacun d'eux sur un Adresse IPv4.