Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Vérification sur les droits d'un nouvel utilisateur

den66

Bonjour,

Je voulais vérifier une chose auprès de vous. Je suis obligé de créer un nouvel utilisateur sur mon serveur. En fait, j'héberge un petit outil Web que j'ai créé pour une antenne emploi du secours pop, et l'ami qui gère l'antenne à besoin d'un accès à la BDD de cet outil. Il utilise le logiciel Navicat et pour ce connecter il lui faut d'abord se connecter en ssh au serveur puis il se connecte à la BDD.
Pas de PHPMyAdmin sur le serveur, donc, pas de possibilité de lui donner un accès par ce biais.

Je vais donc lui créer un utilisateur, mais je voudrais, afin d'éviter toute boulette ou toute fuite, que cet utilisateur n'ait pas le droit de se balader dans le serveur et encore moins celui d'avoir la possibilité d'y agir.

J'ai vu que lorsque l'on créait un utilisateur, un groupe à son nom était créé (et un dossier dans le dossier home). Comment être sur qu'il ne puisse arpenter le serveur, lire les fichiers qui sont dessus (ce qui lui donnerait les login et mot de passe aux autres bases de données), à certain .htaccess... Non que je doute de lui, mais une erreur ou l'utilisation de cet accès par quelqu'un d'autre est si vite arrivé !

Est-ce possible de faire en sorte qu'il soit restreint à son dossier ? À chaque fois que je crois avoir compris comment fonctionnent les utilisateurs, je m'aperçois que ce n'est pas le cas.

J'ai exploré les pages https://doc.ubuntu-fr.org/adduser, https://guide.ubuntu-fr.org/server/user-management.html et https://doc.ubuntu-fr.org/tutoriel/gestion_utilisateurs_et_groupes_en_ligne_de_commande mais je ne trouve pas la solution à mon problème. Aussi, merci d'avance pour votre aide et vos conseils.

MicP

Bonjour

Et si, au lieu d'avoir un shell bash (donné par défaut à la création d'un compte utilisateur),
ce compte utilisateur n'avait pour shell que le programme (dont tu ne nous a pas donné le nom) qui gère la BDD,
il ne pourrait alors rien faire d'autre que d'utiliser les commandes de ce programme de gestion de la BDD
ou sortir de son shell, ce qui le déconnecterait de sa session,
et n'aurait accès à aucune autre commande qui lui permettrait de se balader dans l'arborescence de la machine.

bruno

Bonjour,

Ce n'est pas aussi simple.
Le seul moyen fiable de faire cela est de bloquer l'utilisateur dans son dossier personnel (ou autre) via la configuration de SSH et de lui créer un environnement chrooté plus ou moins complet. Par exemple voir une description basique : https://www.techrepublic.com/blog/linux-and-open-source/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/

Personnellement je chercherais un autre moyen de donner à cet utilisateur un accès à la base de données. Je ne sais pas ce qu'est Navicat (apparemment un logiciel privateur) ni pourquoi il a besoin d'une connexion SSH au préalable. Il faudrait éclaircir ce point.

den66

Bonjour MicP,

C'est effectivement une super idée. Je ne savais pas que c'était possible.
Je vais faire des recherches sur le sujet et je em permettrais de revenir vers vous si je ne trouve pas d'ici la fin de la semaine.
Merci beaucoup pour la piste.
Denis

den66

Bonjour Bruno,

Merci pour votre aide. C'est effectivement plus la voie que je comptais prendre, sauf que je n'en trouvais pas le chemin.
Navicat est un logiciel de connexion aux bases de données. On peut utiliser une connexion SSL, SSH ou HTTP pour aller sur le serveur, puis une connexion avec un utilisateur de la BDD pour se connecter dessus.

En tout cas, merci pour la piste, elle est plus proche de mes maigres connaissances que l'idée de MicP, même si je la trouverais élégante. Par contre, vu mon niveau, je crains de ne pouvoir l'aborder facilement.

Je regarde votre piste et vous tiens au courant.
Merci beaucoup.
Denis

bruno

Une doc un peu plus complète et assez proche de ce qu'il faut faire sous Ubuntu : https://fr-wiki.ikoula.com/fr/Chrooter_ses_utilisateurs_Debian
Mais attention c'est casse-pieds et délicat à mettre en place.

AMHA, l'idée de MicP ne fonctionnera pas, ou si elle fonctionne il sera très facile d'avoir un accès complet au système (retrouver un shell bash ou autre).

Il faut décrire plus précisément les méthodes de connexion utilisées par Navicat. Il doit y a avoir moyen de donner un accès sans passer par SSH un un environnement chroot.

den66

Merci Bruno,

Ça me fout toujours les miquettes quand je dois faire un truc comme ça ! Heureusement, je peux faire un smanshot du serveur avant de me lancer, ça c'est vraiment une invention du feu de dieu.
J'ai regarder la doc, je pense que je vais faire ça ce week-end.
Sinon, comme je le disais, Navicat prpose une connexion SSL (Key client, certificat client et certificat CA), SSH (host, port, user name, et password ou key) et tunnel HTTP, mais ça je ne sais ps trop pourquoi, mais ça ne me tente pas. J'ai regardé la doc Ubuntu sur le sujet, ça me parait encore plus compliqué.
Si vraiment, jene m'en sort pas, je lui dirais que quand il a besoin d'un DUMP, je lui enverrai ! Ça reste la solution la plus simple :-)

En tout cas, merci pour ton aide, d'ici mardi, je vous donnerais des nouvelles.
Bonne fin de semaine à tous.

MicP

…l'idée de MicP ne fonctionnera pas, …

Regarde quel est le shell utilisé par le compte postgresql (ou autre base de données)

…ou si elle fonctionne il sera très facile d'avoir un accès complet au système (retrouver un shell bash ou autre).…

essaye, pour voir…

bruno

hum… si ton machin Navicat utilise un tunnel SSH pour se connecter il doit y avoir moyen de faire fonctionner cela sans un avoir un chroot complet. Avec un utilisateur sans login mais autorisé à faire du tunnelling (AllowTcpForwarding yes) ça devrait le faire.

den66

Merci Micp,
Je regarderai aussi, quand on est comme moi un amateur qui n'a appris qu'à gérer son petit serveur Web et qui ne sait donc faire que ce dont il a besoin, toutes les pistes sont bonne à suivre.

Et je ne voudrais surtout pas occasionner une dispute entre expert !

bruno

@MicP, désolé mais je n'ai sans doute pas compris ce que tu voulais faire. Je ne vois pas comment cela pourrait fonctionner avec un utilisateur qui aurait pour shell /usr/bin/mysql ou /usr/bin/pgsql
En fait je ne vois pas comment un utilisateur pourrait se connecter en SSH sans avoir un shell valide (sh,bash, dash, zsh, …)

Et les shells « restreints » comme rbash sont très faciles à contourner : https://fireshellsecurity.team/restricted-linux-shell-escaping-techniques/
C'est pourquoi je disais que la seule méthode fiable est environnent chroot.

den66

Ok Bruno,

Voilà une autre piste ! Je sens que je vais passer un week-end épique ! Donc, du tunneling... je vais regarder ça https://www.tecmint.com/create-ssh-tunneling-port-forwarding-in-linux/ ça m'a l'air de répondre à cette problématique... il me faut juste le temps de déchiffrer le texte (et oui, pas une brute en anglais !)

bruno

Non il faut que tu regardes la doc de ton logiciel. J'ai l'impression qu'il utilise le tunneling SSH pour ensuite établir la connexion à la base de données. Dans ce cas tu peux avoir un utilisateur qui ne peut rien faire sur le système (par exemple shell /bin/true et home /dev/null), ou ne faire que du SFTP, mais qui est autorisé à faire du tunnelling SSH. Il faudra tout de même utiliser un mot de passe très solide ou mieux une authentification par clé.

MicP

Créé un compte utilisateur et fait en sorte qu'il ait son mot de passe sur le serveur de la BDD pour accéder à ses bases de données dans le serveur de BDD

sudo chsh /bin/PrgDeGestionDeBddQueJeNeConnaisToujoursPas nomDuCompteUtilisateur

La prochaine fois que ce compte utilisateur ouvrira une session sur ta machine, (que ce soit depuis la machine ou par ssh),
il se trouvera avec le prompt du PrgDeGestionDeBddQueJeNeConnaisToujoursPas qui lui demandera le mot de passe de son compte sur le serveur de la BDD
et il ne pourra pas utiliser autre chose que les commandes du serveur de base de données que l'administrateur de la BDD lui aura autorisé dans la BDD.

Après ces tests, si tu veux redonner à ce compte utilisateur un shell bash :

sudo chsh /bin/bash nomDuCompteUtilisateur

bruno

@MicP : on ne peut pas ouvrir une session sur une machine sans shell valide.

MicP a écritil ne pourra pas utiliser autre chose que les commandes du serveur de base de données que l'administrateur de la BDD lui aura autorisé dans la BDD.

Ce n'est pas clair… Qu'est-ce qui est autorisé, ou interdit, et comment et où ?

MicP

Voilà, c'est fait :

J'ai installé mysql 8.0.20
et créé une base dans la quelle j'ai créé une table
puis un utilisateur du même nom que celui qui devra se connecter avec le shell mysql : monusermysql
puis j'ai donné sur cette base les privilèges ALL au compte utilisateur monusermysql
puis j'ai quitté mysql

J'ai installé le paquetage mysql-shell
et j'ai ajouté à la liste des shells le shell /usr/bin/mysqlsh

add-shell /usr/bin/mysqlsh

et j'ai changé le shell du compte utilisateur monusermysql
par /usr/bin/mysqlsh :

chsh /usr/bin/mysqlsh monusermysql

Maintenant, quand l'utilisateur monusermysql se connecte,
il tombe dans le shell de mysql

Après, à vous de configurer mysql et le programme mysqlsh comme il vous plaira,
mais quoi qu'il en soit, il ne peut plus accéder à autre chose que mysql

=======
Je ne connais pas du tout Navicat, mais il faudrait déjà savoir comment ce programme va chercher à se connecter à un serveur de base de données,
si ça se trouve, il n'a même pas besoin d'ouvrir de session autrement qu'en se connectant directement au serveur de la base de données.
Donc, n'y aurait qu'à intervenir dans mysql pour que son compte utilisateur puisse s'y connecter directement par Navicat

den66

OUAHHH ! Je teste ça samedi.
Un grand merci. Si un jour vous avez un soucis en peinture !-)
Et encore merci. Je vous tiens au courant.

bruno

@MicP : où as-tu trouvé le paquet mysql-shell, ce paquet n'existe ni sous Debian, ni sous Ubuntu.
Ensuite j'ai déjà dit que les soi-disant shells restreints n'étaient pas sûrs et que l'on pouvait s'en échapper facilement.

MicP a écritmais quoi qu'il en soit, il ne peut plus accéder à autre chose que mysql

Amusons-nous avec un shell mysql :

mysql> \! ls /

mysql> \! nano

mysql> \! sh

N.B. : je ne te contredis pas pou t’embêter ou pour le plaisir mais parce que je pense, et je peux me tromper, que ce que tu proposes n'est pas une mauvaise solution (ou au mieux une fausse bonne idée).

MicP

@bruno
Ce n'est pas un des "...soi-disant shells restreints..." : il ne s'agit pas d'un shell qui a été bricolé par un fichier de configuration quelconque,
mais d'un programme shell qui a été fait par Oracle Corporation et qui ne permet que d'accéder à mysql.
Si on quitte ce programme, on se retrouvera déconnecté de la machine, et si on est en ssh, on se retrouve déconnecté de sa session ssh

J'ai installé la dernière version de mysql depuis le site d'Oracle Corporation
en téléchargeant le paquetage à l'adresse https://dev.mysql.com/get/mysql-apt-config_0.8.13-1_all.deb
Une fois ce paquetage installé, j'ai installé le paquetage mysql-shell

bruno

Où sont les sources ?
Et tu as testé ? Connexion à la base de données puis les commandes que j'ai indiquées en #18 ?

Je rappelle que soi-disant :

MicP a écritmais quoi qu'il en soit, il ne peut plus accéder à autre chose que mysql

Après avoir récupéré le binaire chez Oracle (pas trouvé les sources) :

 MySQL  JS > \c toto@localhost:3306

 MySQL  localhost:3306  JS > \! cat /etc/passwd

À partir du moment on l'on donne accès à un utilisateur à la ligne de commande MySQL, il peut accéder à plein de choses sur le système.

Page suivante »