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

24

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.

linux security file-permissions shared-hosting Phillipp
la source
12
Je considérerais en fait si les recommandations du "logiciel Web" chmod files 0777sont strictement nécessaires, c'est-à-dire qu'elles s'attaquent à la cause première du problème, plutôt qu'au symptôme selon lequel, ce faisant, n'importe qui peut lire les fichiers de n'importe qui d'autre. Plusieurs fois, la recommandation d' autoriser l'accès est simplement un moyen peu coûteux d'éviter les appels d'assistance ou le manque de prouesse technique pour pouvoir configurer correctement les autorisations. Dans presque aucun cas, je n'ai dû définir des fichiers 0777ou accorder aux applications un accès root complet sur demande. L'éducation des utilisateurs et / ou des fournisseurs aide massivement ici.
Cosmic Ossifrage
3
@CosmicOssifrage, les utilisateurs ne peuvent pas être éduqués aussi facilement, ils ne veulent pas lire les instructions ou les manuels.
Cristian Ciupitu
12
Tout "logiciel Web" qui recommande toujours les autorisations 777 doit être retiré et abattu . Utilisez suexecou mpm_itkou similaire.
Shadur
3
@CosmicOssifrage Je ne pense pas que Phillipp dit ou force les utilisateurs à chmod 0777leurs fichiers. Je pense qu'il est nerveux à l'idée qu'ils se rendent loltoturialz.com/php_problemset se mettent chmod 0777à leur compte tout en suivant aveuglément un article mal écrit. Il n'y a vraiment aucun moyen de les empêcher de le faire ou de les empêcher de se fâcher quand quelqu'un vole leurs affaires.
Kevin - Rétablir Monica le
2
@kevin - c'est précisément pourquoi le vide de garantie a été créé. Je n'ai presque jamais vu un appareil sérieux (que ce soit un logiciel compilé, un tas de scripts ou autre) sans une telle clause. Et croyez-le ou non - dans la plupart des environnements d'entreprise, les utilisateurs en sont bien conscients
Dani_l

Réponses:

34

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.

Cristian Ciupitu
la source
15

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

Dennis Nolte
la source
chroot pour SFTP est facile à implémenter, mais je ne suis pas sûr que ce soit aussi simple pour accéder au shell. Vous devez configurer un chroot avec tous les binaires et bibliothèques pour chaque utilisateur.
Cristian Ciupitu
2
C'est spécifique à l'implémentation. ARCHLINUX a une commande arch-chroot spécifique qui prend en charge toutes les montures de liaison supplémentaires, etc. wiki.archlinux.org/index.php/Change_Root#Change_root
Dani_l
@CristianCiupitu c'est ce que j'ai fait, n'autorisant qu'un sous-ensemble spécifique de commandes avec la liaison de toutes les bibliothèques nessesary, c'est pourquoi j'ai dit que c'était un gâchis :) Dani_l true, ma configuration était un serveur debian, je n'ai jamais eu le temps de vérifier gentoo malheureusement .
Dennis Nolte
@Dani_l: qu'en est-il des packages installés? La arch-chrootcommande ne semble pas couvrir cela. Et puis il y a aussi le problème de l'espace disque gaspillé avec tous les doublons. Je ne dis pas qu'il est impossible de le faire, juste que cela pourrait être un peu plus compliqué actuellement.
Cristian Ciupitu
1
Quelque chose pour rendre cela plus facile est d'utiliser UnionFS pour chrooter les utilisateurs dans une union spéciale des rootfs en mode lecture seule et un répertoire de base en lecture-écriture, cela signifie qu'ils voient tous les packages système et les binaires mais les écritures sont automatiquement effectuées dans leur dossier personnel. ceci - doit être couplé avec la création de tous les 700 répertoires personnels, sinon les utilisateurs pourraient lire les fichiers des autres utilisateurs de toute façon.
Vality
11

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.

HBruijn
la source
5
Qu'est-ce que "fi" ? Je ne recommanderais pas d'utiliser des acronymes ou des abréviations à moins qu'ils ne soient classiques comme "par exemple", "ie", "etc" et peut-être OP.
Cristian Ciupitu
3

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.

maniaque
la source
Vous ne pouvez pas vraiment combiner différents systèmes d'exploitation, car tous doivent utiliser le noyau Linux , mais vous pouvez utiliser différentes distributions .
Cristian Ciupitu
1
Merci :) Oui, différents systèmes d'exploitation basés sur le noyau Linux.
maniaque
@CristianCiupitu voulez-vous dire le même noyau Linux identique? ou voulez-vous dire que chaque conteneur peut avoir une version différente du noyau?
agks mehx
@agksmehx, tous les conteneurs LXC partagent le noyau de l'hôte . Seules leurs applications et bibliothèques sont utilisées. Ainsi, par exemple, si vous avez un hôte RHEL 7 avec un conteneur Ubuntu 14.04, le noyau RHEL (3.10.0-123) sera utilisé, tandis que celui Ubuntu (3.13.0-24.46) ne sera pas utilisé; lire aussi ce commentaire du tutoriel. Soit dit en passant, étant donné que les noyaux des conteneurs ne sont pas utilisés, il peut être judicieux de les supprimer afin d'économiser de l'espace disque.
Cristian Ciupitu
@CristianCiupitu c'est ce que je pensais. ce n'était pas clair à partir de la réponse ou du commentaire, donc je voulais clarifier.
agks mehx
3

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.

Marek
la source
Ils sont appelés "lisibles par le monde" pour une raison.
Mark K Cowan
1
@DennisNolte En fait, cela aide, même si les fichiers sont lisibles par tous, s'ils se trouvent dans un répertoire que vous n'avez ni lu ni exécuté, vous ne pouvez pas les lire de toute façon.
Vality
1
@Vality true, supprimant mon commentaire car il est clairement faux.
Dennis Nolte
2

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.

Dani_l
la source
2
faux, chrooter / emprisonner l'utilisateur dans un sous-dossier et il est incapable de lire des fichiers "normalement" lisibles par le monde.
Dennis Nolte
1
-1 Je pense que vous critiquez inutilement la question du PO. Il veut donner à ses clients un filet de sécurité au cas où ils ne seraient pas intelligents quant à leurs autorisations. Mais il ne me semble pas que l'OP ne sache pas comment fonctionnent les autorisations de fichiers Unix ou les principes de sécurité de base.
Kevin - Réintègre Monica le
En outre, vous pouvez placer les fichiers dans un répertoire à l'intérieur d'un répertoire 000 autorisations, puis personne ne peut y accéder même si les fichiers sont lisibles par tous.
Vality
personne? même pas root? ;-)
Dani_l
@Kevin a convenu que mon commentaire est critiqué de près comme inutile. Cependant, Dani_I ne devrait pas tergiverser et hésiter. Ne déclarant pas que je ne suis pas d'accord avec le reste de sa réponse.
Dennis Nolte
0

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.

bbaassssiiee
la source
0

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.

kasperd
la source