Le Sat, 12 Jan 2013 02:48:27 +0100, Jean Weisbuch jean@plusquenet.net a écrit :
mais évidemment si vous voulez garder une seule IP publique frontale vous devrez avoir un proxy frontal et du nat pour les accès SSH (chaque conteneur ayant son propre SSHD, si possible lancé sur demande car seule une petite partie des utilisateurs utilisent du SSH). Cette solution est bien évidemment plus lourde à mettre en place et peut être contraignante et consommera plus de ressources par compte.
Si la solution d'un chroot était choisie, il vaut mieux avoir un kernel avec le patchset grsecurity qui permet entre autre aux utilisateurs non root de ne pas pouvoir voir les processus des autres utilisateurs (pratique si une commande comprenant un login ou mot de passe est lancé par un user) et différents renforcements de la sécurité des environnements chrootés.
Merci beaucoup pour ces éléments très pertinents.
Le patchset de grsecurity est effectivement une très bonne réponse en terme besoin sur le ssh utilisateur mais soulève du coup d'autres contraintes au niveau du systemes d'exploitation comme le fait de recompiler le noyaux Linux dès que GrSec sort un nouveau patch.
Plus le fait d'installer des noyaux "custom" n'est souvent spécifique à chaque distribution. Il faut donc bien connaître les distrib pour connaître les options à laisser impérativement spécifiquement pour la distribution Linux.
J'ai un peu peur que la charge de travail n'augmente trop.
Le déploiement sous forme de VM seraint une solution.....autre sujet.
Je sais que l'on hérite de UNIX System V, que des ACL étendues ont été crées pour palier à certaines carences, j'aurais pensé qu'une solution plus "standard" voire "packagée" pouvait exister pour ce besoin de ssh utilisateur.
Je me posait la question de savoir si des systèmes MAC (Mandatory Access Control) comme SELinux/AppArmor ou les MAC de FreeBSD n'était pas prévu pour ça.
Avec un Framework MAC on traiterait du coup le pb du ssh user mais aussi d'autres points.....question ouverte.
JC PAROLA