Linux.general : Sécurité fichiers page perso et serveur ssh...
Posté par Sylvain Rampacek (Jabber id, page perso, ) le 18 avril 2006
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 !
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 !
> Lire le message (13 commentaires, moyenne: 2,3).
Vous avez demandé le commentaire #703157.
Run by 
Cette page a été générée par Templeet en 0.0472s (dont 0.0039 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Chroot + scponly
Salut,
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
pour le coup du scp only, ça va pas être possible non plus...
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
Et bien virtualise ;-)
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
c'est cette solution qui me parait la mieux ! j'en parlerai avec l'administrateur attitré de la machine.
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
La virtualisation est une excellente réponse à ta question. Tout administrateur système sait parfaitement qu'un serveur = un service permet de garantir une sécurité correct bien plus facilement, et accessoirement permet de faciliter la maintenance dans certain cas ...
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.