Le 10 janv. 2013 à 23:10, Emmanuel Thierry a écrit : > De la même manière que la majorité des gens je suggérerais un chroot ssh (à > l'intérieur desquels tu bindes les dossiers nécessaires à la bonne exécution > de leurs applis (/usr, /bin, /sbin, ...).
Bonjour, J'ai lu pas mal de choses qui m'ont fait sursauter, d'un point de vue sécurité lors de cet échange. Alors traitez moi de parano :) Pour autant, je réagis sur celui-ci qui est un fantôme bien connu, et commun : si vous bindez des répertoires (bind comme dans mount --bind), à fortiori des binaires, de l'extérieur d'un chroot à l'intérieur de celui-ci, vous créez un super tremplin pour l'évasion dudit chroot : une élévation de privilège à l'intérieur du chroot permettra de réécrire les binaires, qui seront tout autant affectés à l'extérieur du chroot... et plouf, le beau reverse-shell :) Concernant le problème plus général : compte tenu de la complexité de sécuriser un accès SSH, et à fortiori shell (penser à toutes les options de ssh, et de tous les programmes que l'utilisateur pourra lancer, loguer toutes les commandes sans que ce soit aisément contournable...) , je dirai que c'est une mauvaise idée d'en ouvrir un, tout court. Si je devais faire cela, je référencerai de manière exhaustive les besoins des clients (qui ne doivent pas être très nombreux, finalement...), et je ferai un "menu" web (accessible uniquement après une authentification forte, sur le backoffice de l'utilisateur) avec des commandes pré-générées et dont les arguments ont été correctement échappés/encodés pour éviter l'injection de commandes OS. Ces commandes seraient alors exécutées avec le droit de l'utilisateur en question (plusieurs techniques possibles...). Dans le doute, je m'inspirerai de ce qu'ont fait les "grands" du mutualisé, qui s'en tirent pas mal, sans donner d'accès shell. Un dernier point : il ne faut pas donner aux utilisateurs juste un répertoire qui est directement le docroot, lors des accès FTP. C'est pourri, en terme de sécurité. Toutes les bonnes pratiques conseillent de ne mettre dans le docroot que ce qui a réellement besoin d'être accessible par les internautes (oui, je sais, bcp de framework PHP eux mêmes ne le font pas... don't get me started on this, PHP, sécurité, vendredi, tout ça...). Les astuces à base de .htaccess (valable uniquement pour Apache, et je pourrais citer bon nombre de techniques permettant de prendre la main sur un serveur À CAUSE des htaccess ; d'une manière général : désactivez ces saloperies), ou de petites lignes en haut de chaque fichier PHP (oubli très facile...) sont en général super pourries. Au moins un niveau en dessous est souhaitable. Pour prévenir l'effacement du répertoire docroot qui vous ferait une erreur lors du redémarrage du serveur web, utilisez une astuce sur les droits systèmes avec le sticky bit ;) Bon courage, Florian Maury _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
