Bonjour à tous...
Un petit problème me passe à travers la tête depuis quelques jours.
Soit un serveur apache où tout un groupe d'utilisateur y met sa page web perso. Certaines de ces pages sont "privées" et un .htaccess est là comme il faut pour limiter l'accès par apache.
Par contre, ce même serveur sert également de serveur SSH : donc tous les utilisateurs ont un login et mot de passe pour mettre à jour leur page web.
D'où la question : comment faire pour que seul l'utilisateur propriétaire des fichiers puissent lire ses fichiers de sa page web en ssh et pas ceux des autres ? notamment si sur son site perso, l'utilisateur veut mettre un script php contenant un mot de passe, comment éviter que les autres utilisateurs SSH de la machine puisse le récupérer ?
J'ai bien plusieurs solutions qui me viennent à l'esprit :
- "chmod 701 public_html" et "chmod 604" sur les fichiers contenus dans ce dossier, mais là, si un autre utilisateur connaît le nom du fichier à récupérer, il suffit de faire cat /home/login/public_html/lefichier, et c'est mort...
- "chown login:apache public_html" et "chmod 710 public_html", mais pour exécuter la commande chown, il faut ajouter le login utilisateur au groupe apache, et dans ce cas, l'utilisateur peut alors accéder à tous les fichiers dont le groupe est apache...
- ...
Bref, à chaque fois, il y a un moyen pour contourner la protection.
Quelqu'un aurait une idée ??
Merci d'avance !
Forum Linux.général Sécurité fichiers page perso et serveur ssh...
18
avr.
2006
# Chroot
Posté par Sebastian . Évalué à 3.
Il existe la méthode dite du "Chrootage".
Cela permet d'établir une sorte de "prison", qui interdit aux utilisateurs de sortir de leur répertoire personnel.
Donc effectue des recherches [ ssh + chroot ].
[^] # Re: Chroot
Posté par Sebastian . Évalué à 3.
Mais il existe le projet "chrootssh" où l'on peut télécharger des patch ou des versions entières d'OpenSSH patchées.
http://chrootssh.sourceforge.net/
[^] # Re: Chroot
Posté par JJD . Évalué à 2.
Il est effectivement possible de chrooter les utilisateurs se connectant sur le serveur OpenSSH mais, de mémoire, la solution était assez lourde (patch du serveur SSH).
Une autre solution pourrait être l'utilisation de scponly qui offre deux avantages :
- limitation de l'accès SSH aux transferts de fichiers par scp et/ou sftp (suppression de la possibilité d'ouvrir une session et/ou d'exécuter des commandes).
- possibilité de chrooter (facilement ?) les utilisateurs connectés.
Pour plus de détails, voir le site http://www.sublimation.org/scponly/ .
Une autre piste à étudier (sans garantie) serait l'utilisation des ACL sur le système de fichiers en question. Les droits sur l'arborescence d'un site (ou au moins le répertoire racine) seraient mis à 700 et on accorde les droits de lecture (voire écriture selon les besoins) au user apache. Il reste à voir comment ces ACL se propagent aux fichiers créés (mais ce n'est pas forcément nécessaire).
La mise en place de ces ACL dépend tout de même de plusieurs paramètres :
- la distribution utilisée (et les options du noyau et des modules) ;
- le système de fichiers utilisé ;
- la possibilité de modifier les options de montage (/etc/fstab).
- ...
Au final, une combinaison scponly avec chroot ou scponly+ACL devrait fournir une solution viable.
Bon courage et tiens nous au courant des résultats,
JJD
[^] # Re: Chroot
Posté par Sylvain Rampacek (site web personnel) . Évalué à 2.
de plus, comme je l'explique, le gros hic c'est que le serveur est utilisé en serveur de calcul, donc ne plus pouvoir se loguer sur la machine n'est pas possible (scponly)
(je sais, on n'est pas compliqué :-p)
[^] # Re: Chroot
Posté par Sylvain Rampacek (site web personnel) . Évalué à 2.
Donc les empêcher de remonter dans l'aboresence va poser d'autres problèmes...
[^] # Re: Chroot
Posté par Dabowl_92 . Évalué à 2.
# Groupe par utilisateur
Posté par peck (site web personnel) . Évalué à 3.
Par contre c'est un peu lourd quand tu veux ajouter un utilisateur (il faut penser a ajouter apache à son groupe et relancer apache).
[^] # Re: Groupe par utilisateur
Posté par Sylvain Rampacek (site web personnel) . Évalué à 2.
car j'ai décris celle-ci qui fait que tout les utilisateurs ayant le groupe apache (grep "login" /etc/group : apache:x:1234:login) peuvent lire tout les fichiers ayant comme groupe propriétaire apache :
"chown login:apache public_html" et "chmod 710 public_html", mais pour exécuter la commande chown, il faut ajouter le login utilisateur au groupe apache, et dans ce cas, l'utilisateur peut alors accéder à tous les fichiers dont le groupe est apache...
et l'opération inverse ne fonctionne pas si les fichiers ont comme droits 600 ou 700 (le but) (grep "login" /etc/group : login:x:1234:apache).
# Chroot + scponly
Posté par Dabowl_92 . Évalué à 2.
Pour ton problème, je pense qu'un chroot ferait effectivement ce que tu veux, du coup personne ne peut aller chez le voisin et ça facilite le problème des droits.
Je te conseille aussi l'utilisation de scponly, cet outil empêche aux utilisateurs de se loggeur et donc d'ouvrir un shell, il laisse juste passer les transferts avec sftp/scp.
Plus d'info ici :
http://www.sublimation.org/scponly/
Et pour finir, comme je le dis dans mon autre commentaire, si les utilisateurs veulent échanger des fichiers entre eux, alors il faut créer un espace commun...
[^] # Re: Chroot + scponly
Posté par Sylvain Rampacek (site web personnel) . Évalué à 2.
car le bi-xéon HT sert également de serveur de calcul (ben oui, ce ne sont que des petites pages perso), donc si plus personne ne peut l'utiliser pour lancer son calcul, ça va être dur...
en fait, toute la complexité réside dans le faite que le serveur à plusieurs rôles (je sais, dans l'idéal, faut pas, mais la réalité, c'est autre chose).
[^] # Re: Chroot + scponly
Posté par Dominique Feyer (site web personnel) . Évalué à 2.
V-Server
http://linux-vserver.org/
Vu que tu n'as qu'une seule machine, et que les tâches que tu dois effectuer sur la machine te pose des problèmes au niveau des règles de sécurité, le meilleure truc à faire c'est de virtualisé.
Tu crée autant de serveur virtuel que tu veux sur ta machine physique:
1 pour le partage de fichier
1 pour le calcul
1 pour l'hébergement web
Tu peux partager des dossiers entre différents V-Server donc gérer tes fichiers web depuis le v-server de partage de fichier par example.
Les possibilités sont infini et très souple. En plus les mécanisme d'isolation des V-Server sont bien plus sécurisé qu'un simple chroot.
L'overhead sur un V-Server et de l'ordre de 2% donc sur un bi-xénon c'est négligeable.
[^] # Re: Chroot + scponly
Posté par Sylvain Rampacek (site web personnel) . Évalué à 2.
mais ce qui m'étonne, c'est qu'il n'existe pas moyen de faire cela sans sortir des outils supplémentaires (cad juste en utilisant des droits configurés comme il faut et un apache).
c'est vrai que les ACL apportent un plus... mais bon, en tout cas, je me sens moins seul : visiblement, il n'y a pas de réponse immédiate !
Merci à tous !
[^] # Re: Chroot + scponly
Posté par Dominique Feyer (site web personnel) . Évalué à 3.
Mais tout bon administrateur système connait aussi les relations avec le département compatable, manque de budget, ...
Les machines récentes peuvent très bien supporter une solution comme Vserver.
Je l'utilise dans mon entreprise pour le serveur Intranet, virtualisé en 6 machines
1. Firwall/VPN (communique avec l'exterieur via ADSL)
2. Serveur de fichiers (samba,coda,ftp)
3. Apache Intranet
4. Proxy HTTP/SOCKS
5. Mail (en fait un proxy filtrant le spam, virus)
6. DNS Primaire (le secondaire est sur un vieux serveur physique)
Le tout fonctionne sur un bi xénon 3.2 Ghz, 2Go RAM, sous Debain 3.1, 280Go de disque en RAID V (hardware) partagé entre les vhosts avec LVM pour simplifier la gestion des partitions.
Sur le serveur physique, il n'y a aucun service sauf SSH.
J'ai pas mal d'autre configuration fonctionnant sous VServer, jamais eu de problème majeur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.