Re: [FRsAG] : commandes ssh resteintes
Le Sat, 12 Jan 2013 02:48:27 +0100, Jean Weisbuch 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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] : commandes ssh resteintes
Le 12 janv. 2013 à 12:22, JC PAROLA a écrit : > 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. Je me contenterai de répondre que question charge de travail, SELinux se pose là, dès qu'on sort des sentiers battus (a.k.a. ce qui est pré-packagé) Pour ainsi dire, sa lourdeur n'a d'égal que son efficacité. Florian Maury ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] : commandes ssh resteintes
Le 12 janv. 2013 à 02:48, Jean Weisbuch a écrit : > Le 11/01/2013 10:52, JC PAROLA a écrit : >> Je pense que ce point soulever par Emmanuel Thierry est beaucoup plus >> utilisé que ce que l'on pense. On m'a souvent demandé d'intervenir sur >> des serveurs mutualisés d'autres hébergeurs qui n'ont pas peur de >> fournir un accès SSH pour chaque utilisateur et pour les milliers de >> serveurs mutualisés qu'ils possèdent. >> >> En accédant en ssh sur ces serveurs, je m'était rendu compte que ce >> n'était pas un nouveau shell mais bien du super chroot comme énoncé >> précédemment >> >> Je vais creuser aussi la dessus. >> >> un grand merci également Jonathan SCHNEIDER pour son coup de pouce pour >> le contact avec le développeur de lshell. Sincèrement, je suis >> persuader que le pb venait de mon install (apt sur Debian et port sur >> Freebsd). La mise en prod mettra tout cela en lumière. > Pour une telle utilisation il est recommandé en terme de sécurité et > souplesse pour l'utilisateur (si l'on veux qu'il ait un environnement semi > ouvert) de mettre en place des conteneurs (LXC ou VServer ou OpenVZ) plutôt > que du chroot même avancé (sans forcément donner l'accès root à > l'utilisateur), 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. Le point avec LXC est qu'il est possible de "virtualiser" à la carte. On peut "virtualiser" le filesystem, les PID, les devices, etc, mais garder le même net namespace. C'est précisément ce que je fais sur l'un de mes setup où j'ai gardé une stock réseau unique pour tous les conteneurs. Cela évite un NAT inutile. Concrètement cela pourrait se faire pour des restrictions utilisateur en ayant un seul process sshd, lequel pourrait créer à la volée un nouveau conteneur pour chaque session ssh ou utilisateur. Cordialement. Emmanuel Thierry ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] : commandes ssh resteintes
Le 2013-01-12 16:16, Emmanuel Thierry a écrit : Le 12 janv. 2013 à 02:48, Jean Weisbuch a écrit : Le 11/01/2013 10:52, JC PAROLA a écrit : Je pense que ce point soulever par Emmanuel Thierry est beaucoup plus utilisé que ce que l'on pense. On m'a souvent demandé d'intervenir sur des serveurs mutualisés d'autres hébergeurs qui n'ont pas peur de fournir un accès SSH pour chaque utilisateur et pour les milliers de serveurs mutualisés qu'ils possèdent. En accédant en ssh sur ces serveurs, je m'était rendu compte que ce n'était pas un nouveau shell mais bien du super chroot comme énoncé précédemment Je vais creuser aussi la dessus. un grand merci également Jonathan SCHNEIDER pour son coup de pouce pour le contact avec le développeur de lshell. Sincèrement, je suis persuader que le pb venait de mon install (apt sur Debian et port sur Freebsd). La mise en prod mettra tout cela en lumière. Pour une telle utilisation il est recommandé en terme de sécurité et souplesse pour l'utilisateur (si l'on veux qu'il ait un environnement semi ouvert) de mettre en place des conteneurs (LXC ou VServer ou OpenVZ) plutôt que du chroot même avancé (sans forcément donner l'accès root à l'utilisateur), 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. Le point avec LXC est qu'il est possible de "virtualiser" à la carte. On peut "virtualiser" le filesystem, les PID, les devices, etc, mais garder le même net namespace. C'est précisément ce que je fais sur l'un de mes setup où j'ai gardé une stock réseau unique pour tous les conteneurs. Cela évite un NAT inutile. Concrètement cela pourrait se faire pour des restrictions utilisateur en ayant un seul process sshd, lequel pourrait créer à la volée un nouveau conteneur pour chaque session ssh ou utilisateur. Cordialement. Emmanuel Thierry ___ Liste de diffusion du FRsAG http://www.frsag.org/ merci pour votre retour. Je vais approfondir ce point. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] : commandes ssh resteintes
Pour ma part je suis assez d'accord avec Florian sur les aberrations que l'on voit avec un chroot mal fait. Je me contente d'un kernel récent avec patch grsec, séparation entre le web Nginx et PHP (communication par socket dédiés par sites), MySecureShell pour l'accès sftp/scp, combiné à lshell pour limiter les commandes possibles (éditions emacs/vim, packages, manipulation de base des fichiers/rep). Les accès sont donc chrooté virtuellement par MySecureShell qui lance lshell qui lui aussi ajoute son chroot virtuel. Les partitions sont montées en autre avec noexec, nosuid, nodev, php a une liste longue comme le bras pour limiter les fonctions utilisables (même curl_exec est bloqué). En amont sur une plate-forme à vocation mutualisée on a des reverses proxy Nginx avec naxsi (en cours de test sur quelques vhost). Voilà comment je gère cela. signature.asc Description: OpenPGP digital signature ___ Liste de diffusion du FRsAG http://www.frsag.org/
