Bonsoir,

Le projet limited shell est peut être ce qu'il te faut ?

http://lshell.ghantoos.org/

Je l'utilise régulièrement, ça semble correspondre à ce que tu veux. Tu peux créer des limitations globales, par groupe ou par utilisateurs, il suffit de configurer tes utilisateurs pour utiliser le shell lshell. Parmis ces limitations, il y a les commandes à autoriser et les dossiers dans lesquels les utilisateurs peuvent (ou pas) se balader. Il est présent dans les dépôts de quelques distributions directement en plus, selon ce que tu utilises.

En espérant être utile :)

Victor Héry

Le jeudi 10 janvier 2013 19:31:22, JC PAROLA a écrit :

Le Thu, 10 Jan 2013 19:26:00 +0100, Nathan delhaye contact@nathan-delhaye.fr a écrit :

...

Sinon tu la bonne veille solution du chroot avec des options de restriction une config du genre :

Match group limitedusers ChrootDirectory /home/chroots/%u X11Forwarding no AllowTcpForwarding no

Merci j'ai testé aussi mais le man de sshd_config indique que le dossier utilisateur dans /home/chroots/ doit appartenir en root et comme ce dossier contient le site web en PHP...le passage en root me lève des erreurs avec suPHP

Jean-Christophe PAROLA

---

Liste de diffusion du FRsAG http://www.frsag.org/

Il n'y a qu'a mettre le site dans un sous-répertoire genre /root/chroots/Alice/www/

L'utilisateur n'aura qu'a faire un cd www pour se retrouver dans le bon répertoire. Ce n'est pas très compliqué a expliquer. Le sous répertoire appartenant à l'user désiré + le fait que tous les répertoires parents appartiennent à root, plus de soucis.

Le 10 janvier 2013 19:31, JC PAROLA contact@sels-ingenierie.com a écrit :

Le Thu, 10 Jan 2013 19:26:00 +0100, Nathan delhaye contact@nathan-delhaye.fr a écrit :

...

Sinon tu la bonne veille solution du chroot avec des options de restriction une config du genre :

Match group limitedusers ChrootDirectory /home/chroots/%u X11Forwarding no AllowTcpForwarding no

Merci j'ai testé aussi mais le man de sshd_config indique que le dossier utilisateur dans /home/chroots/ doit appartenir en root et comme ce dossier contient le site web en PHP...le passage en root me lève des erreurs avec suPHP

Jean-Christophe PAROLA

---

Liste de diffusion du FRsAG http://www.frsag.org/

Bonsoir,

Sinon tu as lshell http://lshell.ghantoos.org/ qui est un shell en python qui te permet de restreindre les actions utilisateurs et les répertoires qui peuvent être parcourus.

Cdlt, Jonathan SCHNEIDER

Le 10 janvier 2013 19:26, Nathan delhaye contact@nathan-delhaye.fr a écrit :

Bonsoir,

Sinon tu la bonne veille solution du chroot avec des options de restriction une config du genre :

Match group limitedusers ChrootDirectory /home/chroots/%u X11Forwarding no AllowTcpForwarding no

Il te suffit de mettre les users dans le groupe limitedusers et de setup les chroots correctement.Je n'ai plus en tête les fichiers nécessaires, main il y a plein de tuto sur le net pour ca.

my 2 cents

Le 10 janvier 2013 19:19, JC PAROLA contact@sels-ingenierie.com a écrit :

Bonsoir à tous,

...

J'aimerais donner un accès ssh utilisateur en plus de l'accès FTP à mes utilisateurs.

Je voudrais que mes utilisateurs puissent se connecter avec un mot de passe, qu'ils ne puissent pas remonter dans l'arborescence du système de fichier sans pour autant les chrooter car les dépendances en terme de librairies et autres est trop importante.

Avec OpenSSH, un ssh user permet dans souci de parcourir /etc /root ce qui est génant, même si les ACL du FS ne permettent aucune modification.

Les clients veulent pas exemple décompresser des archives dans leur $HOME.

J'ai testé plusieurs solutions:

1/rbash : facile à mettre en oeuvre mais n'autorise pas la commande cd 2/rssh: ne permet de faire que du scp et sftp 3/utilisation de l'instruction 'command' dans le fichier autorized_keys afin de faire pointer toutes les commandes shell vers un wrapper 4/iron bash shell: top mais l'implémente que 3 commandes shell

J'ai passé un long moment sur sourceforge.net et freecode ainsi que les moteur de recherche, je suis surpris que rien ne corresponde....je dois mal définir mon besoin

Avez vous déjà été confronté à cela ?

Bonne soirée à tous et bonne année

--

Jean-Christophe PAROLA

---

Liste de diffusion du FRsAG http://www.frsag.org/

-- Nathan Delhaye 06 69 27 64 25 0805 696 494

---

Liste de diffusion du FRsAG http://www.frsag.org/

Bonsoir la liste

ssh_config et une config de sudo

~/.ssh/config

avec un truc du genre

command="sudo poste-client-",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa La cLé SSH super longue client@poste-client"

Le Thu, 10 Jan 2013 19:26:18 +0100, Christophe Baegert c.baegert-listes@lixium.fr a écrit :

...

NFS !

c'est un serveur dédié 1U...je ne pense pas que cela soit judicieux :-)

Jean-Christophe PAROLA

---

Liste de diffusion du FRsAG http://www.frsag.org/

Os c'est pas dans .ssh/config c'est dans authorized_keys qu'il faut limiter les commandes ssh..

Sorry

Guillaume Pancak guillaume@pancak.com

Le 10 janv. 2013 à 19:38, Guillaume Pancak gpkfr@imelbox.com a écrit :

Bonsoir la liste

ssh_config et une config de sudo

~/.ssh/config

avec un truc du genre

command="sudo poste-client-",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa La cLé SSH super longue client@poste-client"

...

Le Thu, 10 Jan 2013 19:26:18 +0100, Christophe Baegert c.baegert-listes@lixium.fr a écrit :

...

NFS !

c'est un serveur dédié 1U...je ne pense pas que cela soit judicieux :-)

Jean-Christophe PAROLA

---

Liste de diffusion du FRsAG http://www.frsag.org/

---

Liste de diffusion du FRsAG http://www.frsag.org/

Le 10/01/2013 19:52, Tristan Mahé a écrit :

Bonsoir,

Pour nos hébergements mutualisés c'est ce que nous avons déployé, un chroot géré par ssh pour le sftp + un chroot shell pour l'utilisateur.

Inconvénient d'un shell chrooté par contre, c'est qu'on doit avoir une copie des binaires et des librairies dans le repertoire chrooté, mais pas génant au final car cela permet de limiter les commandes disponibles pour l'utilisateur...

Bonsoir, juste par curiosité, vous installez les commandes en version dynamique ou vous les recompilez (et installez) en statique ?

Merci, Emilio

Je propose ;)

Cela dit quelles commandes doivent être utilisées par les clients?

Le 10 janv. 2013 à 19:48, JC PAROLA contact@sels-ingenierie.com a écrit :

Le Thu, 10 Jan 2013 19:38:45 +0100, Guillaume Pancak gpkfr@imelbox.com a écrit :

...

ssh_config et une config de sudo

~/.ssh/config

avec un truc du genre

command="sudo poste-client-",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa La cLé SSH super longue client@poste-client"

Mais sur un serveur dédié avec plusieurs dizaines d'hébergement, à moins de mettre la même clé publique pour tous les hébergements (pas top !) ça va être galère

Jean-Christophe PAROLA

---

Liste de diffusion du FRsAG http://www.frsag.org/

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

Le Thu, 10 Jan 2013 23:10:18 +0100, Emmanuel Thierry ml@sekil.fr a écrit :

Côté www, il y a l'option suPHP, mais il y a également l'option ACL étendues, qui te permettent de définir des droits supplémentaires par rapport aux droits unix classiques. Sur mon ancien setup les fichiers étaient ownés par les utilisateurs mais une ACL étendu donnait le droit à l'utilisateur www-data de créer/modifier/supprimer les fichiers.

Enfin, pour l'isolation de tes utilisateurs, le chroot est pas mal mais le container LXC est encore mieux. En plus du chroot, tu peux exécuter le shell de l'utilisateur dans des namespace réseau, PID, ... différents, et dropper les capabilities qui ne te plaisent pas (histoire d'éviter qu'une élévation de privilège permette à un de tes utilisateurs de rebooter le serveur).

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.

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

(...)

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.

Sur FreeBSD tu peux aussi ajouter un jail qui te permet d'avoir, en plus de MAC, des choses assez blindées.

Après pour garantir que ton OS n'est pas modifiable :

kern_securelevel="3" kern_securelevel_enable="YES"

Et un reboot, dans ce cas présent toute modification de fichiers système ne peux être obtenu que :

- en single user (donc accès console) - en modifiant /etc/rc.conf et un reboot (donc en général un reboot ca se voit)

/Xavier

Le Mon, 14 Jan 2013 12:52:18 +0100, Xavier Beaudouin kiwi@oav.net a écrit :

Sur FreeBSD tu peux aussi ajouter un jail qui te permet d'avoir, en plus de MAC, des choses assez blindées.

Après pour garantir que ton OS n'est pas modifiable :

kern_securelevel="3" kern_securelevel_enable="YES"

Et un reboot, dans ce cas présent toute modification de fichiers système ne peux être obtenu que :

• en single user (donc accès console)
• en modifiant /etc/rc.conf et un reboot (donc en général un reboot

ca se voit)

C'est effectivement une approche de j'aime beaucoup et que j'utilise très souvent.

en couplant cela avec IPFW qui permet d'adapter les règles de filtrage IP en fonction de l'uid/guid, on obtient une granulatité très fine.

Juste pour re-situer le contexte, il s'agit d'ouvrir un accès ssh restreint sur un serveur mutualisé avec une centaine de vhosts.

Donc le jail est un peut trop lourd dans ce cas.

Le 12 janv. 2013 à 02:48, Jean Weisbuch jean@plusquenet.net 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