[Resolu][SFTP] Comment bloquer un user dans un rep

[ssc37]

Bonjour

Après avoir monté mon serveur SFTP avec shell restreint sur ma debian etch (j'ai testé rssh,scponly), je souhaitais que l'utilisateur arrive dans son répertoire et ne puisse pas remonter d'un niveau. Après avoir recherché plusieurs heures sur notre ami google je ne suis arrivé qu'a chrooté le user,mais lorsqu'il se connecte il peut remonter d'un niveau et donc voir dev,bin,etc.. du chroot.

Quelqu'un aurait-il un indice vers lequel m'orienter? où même me dire si cela est faisable? car je trouve cela vraiment génant et c'était beaucoup plus simple quand j'utilisais vsftpd ^^

Merci

[zoto]

Salut

Regarde du coté de scponly .

C'est un shell spéifique qui ne permet que d'utiliser le scp .

Avec est fournie un script qui permet de chrooté facilement un user :)

a+

[ssc37]

Salut

Regarde du coté de scponly .

C'est un shell spéifique qui ne permet que d'utiliser le scp .

Avec est fournie un script qui permet de chrooté facilement un user :)

a+

Déjà regardé et testé .Mon chroot a été crée justement avec chroot_setup fourni par scponly, l'utilisateur arrive bien dans le dossier incoming mais peut remonter d'un niveau et voir les dev,bin,etc.. chrooté.

[rt23]

As tu regardé MySecureShell ?

Il me semble que j'avais réussi à faire ça avec ce logiciel.

[zoto]

Salut

Regarde du coté de scponly .

C'est un shell spéifique qui ne permet que d'utiliser le scp .

Avec est fournie un script qui permet de chrooté facilement un user :)

a+

Déjà regardé et testé .Mon chroot a été crée justement avec chroot_setup fourni par scponly, l'utilisateur arrive bien dans le dossier incoming mais peut remonter d'un niveau et voir les dev,bin,etc.. chrooté.

Salut

En même temps on s'en fiche, tous appartient a root sauf le dossier incomming .

a+

[LukeSkyPator]

Regarde au niveau de ton serveur sFTP, tu dois avoir une option pour faire du jail.

LSP, le manchot pro vsFTPd

[tuXXX]

Normalement le principe du chroot c'est justement d'avoir le homedir en "/" du chroot, si il y a /dev dans le chroot l'intérêt est tout de suite à relativiser à mon avis.

[ssc37]

Normalement le principe du chroot c'est justement d'avoir le homedir en "/" du chroot, si il y a /dev dans le chroot l'intérêt est tout de suite à relativiser à mon avis.

C'est bien pour cela que je pose la question tuXXX Sur tout les sites que j'ai pu parcourir les explications sont les mêmes et les seuls topics abordant ce sujet sont resté sans réponses

Personne s'est retrouvé dans ce cas de figure?

Il se peut que le soucis vienne de mes capacités limitées, mais j'ai beau lire et relire les différents articles je ne pense pas avoir fait de fausses manips

Voici l'arborescence obtenu avec setup_chroot (contenant les librairies):

/home
  |->ftpuser
       |->bin
       |->dev
       |->etc
       |->incoming
       |->lib
       |->usr

et cette ligne dans mon /etc/passwd: ftpuser:x:1001:1001::/home/ftpuser//incoming:/usr/sbin/scponlyc

Je vois vraiment pas comment procéder que cela soit avec rsssh ou scponly..... je vais regarder du coté de MySecureShell mais cela m'étonne qu'il est pas une solution "plus standard"

[LukeSkyPator]

Bah écoute, je me répète, mais avec vsFTPd, tu peux chrooter le user directement dans la conf du ftpd

LSP, le manchot qui baille

[ssc37]

Bah écoute, je me répète, mais avec vsFTPd, tu peux chrooter le user directement dans la conf du ftpd

LSP, le manchot qui baille

depuis quand vsftpd fait du sftp? avec SSL j'étais au courant mais à travers du SSH il me semble pas en avoir entendu parler

[Compte_supprime_74291]

Après avoir recherché plusieurs heures sur notre ami google je ne suis arrivé qu'a chrooté le user,mais lorsqu'il se connecte il peut remonter d'un niveau et donc voir dev,bin,etc.. du chroot.

Ca, c'est parce que, apparemment, ce que tu as fait ne revient qu'à chrooter le daemon (sftp, il semble)... mais ce n'est pas la même chose que de chrooter un user dans son /home (ce qu'il est discutable d'appeler chroot, puisqu'a priori, ce genre de choses ne se fait pas avec chroot... je peux me tromper, mais je n'ai jamais rien vu d'autre que des applis chrootées... chrooter un utilisateur avec chroot sans lui permettre d'accéder à des applications n'a pas vraiment de sens pour moi... avec autre chose que chroot, soit, mais avec chroot )...

En gros, tu n'as apparemment fait qu'enfermer ton daemon dans un chroot, mais dans ce chroot, tout ce passe comme dans un OS normal (enfin, un OS normal bien castré, si c'est bien fait... ce qui se discute, se remet en question, se vérifie, encore et encore, jusqu'à ce que les messieurs en blanc viennent toquer); et dans un OS normal, les users ont accès à / (ou au moins des bouts), ce qui est, tu en conviendras, pratique pour lancer des applis ... Avec ce que tu sembles avoir fait, tu prends des mesures pour éviter qu'une faille dans ton chroot (donc, vraisemblablement sur ton daemon ftp) ne se répercute sur le reste de ton système, mais c'est tout...

Après, pour ce que je connais, ce n'est pas un user qu'on chroote, mais une application (éventuellement, on peut limiter un user dans un bash restreint... oui, ça, ça se fait, et il ne voit pas au-delà de ce que le bash restreint lui autorise... mais les restrictions sont imposées par bash qui crée une instance restreinte de lui-même et on n'a pas besoin de chroot pour ça... on peut globalement faire ça avec toutes les applis bien faites, mais, même si ça reste sémantiquement du chroot, pas besoin de /usr/sbin/chroot pour le faire)...

Si tu veux limiter un user à certains répertoires, il faut que tu le fasses avec l'application que tu le laisses utiliser (ton serveur ftp, a priori)... Ah oui: et surtout pas de chroot dans le chroot (quand je dis chroot, je parle de l'application "chroot"... limiter un utilisateur à son /home du chroot avec un daemon qui tourne dans un chroot ne doit pas être censé faire appel à chroot lui-même)... c'est l'un des moyens les plus simples de s'en échapper (avec les applis en suid, certes, certes).

Si ton appli ne permet pas ça... là, c'est la merde ... faut plutôt chercher dans la création d'autant de chroots du daemon que d'users qui vont se connecter, avec pour seul bénéfice qu'ils seront isolés les uns des autres et ne pourront pas voir leurs documents respectifs, même s'ils pourront chacun voir le / de leurs chroots respectifs... et voilà l'usine à gas (enfin, pour deux ou trois users, ça peut encore se faire, mais bon...)...

Sinon, pour la présence des /dev dans un chroot d'application (et j'insiste bien sur "application"), encore heureux... ne serait-ce que /dev/null est indispensable à trop de choses (rediriger des logs ou des cochonneries à l'intérieur du chroot vers le néant)... les /dev dépendent du noyau et les chroot n'ont jamais prétendu être efficaces en cas de faille noyau. Donc, si le but est de faire tourner une appli dans un chroot (et il y a de fortes chances qu'un daemon ait au moins besoin de /dev/null), tout en étant conscient qu'un chroot n'est qu'une application, qu'elle n'a pas spécialement de pouvoir sur le noyau et qu'elle dépend aussi des failles de ce derniers, oui, la plupart du temps, il faut faire du mknod (bon, évidemment, ne pas mettre n'importe quoi comme node dans le /dev du chroot... ou ne pas s'étonner que l'on puisse faire beaucoup plus de cochonneries que prévu à partir du chroot... enfin "prévu": si on met son vital /dev/?da dans le /dev du chroot, c'est tellement risqué qu'on peut plutôt parler de connerie ouverte que d'imprévu)...

Mais bon, un chroot n'est pas tout... imagine que ton serveur ftp ait une faille qui permette à l'utilisateur logué de lancer des commandes avec ses droits... il suffit d'une application suid ou tout simplement de chroot dans le / du chroot pour en sortir... enfin, si rien n'est fait contre ça...

Après, pour se protéger des failles noyaux et des astuces anti-chroot (inhérentes au fonctionnement des *NIX... il faut du workaround), ou au moins limiter leur INpact, faut aller taper dans les patches de sécurité (grsec, selinux, rsbac)... mais bon, c'est encore un autre monde que le vulgaire chroot (bien que les patches de sécu soit indispensables pour protéger un chroot du double-chrooting et autres mignoneries... mais ça, c'est une autre histoire)...

Autrement, pour ce qui est de configurer ton chroot (car il n'en reste pas moins que pour un truc ouvert à tous vents comme un serveur sftp, chrooter cette application n'est vraiment-vraiment- vraiment pas du luxe), vérifie bien que tout s'y passe comme tu veux. Je pense notamment au /etc/passwd du chroot (qui ne doit pas forcément être le même qu'hors-chroot... il doit refléter qu'il y sera fait référence comme si ce qui est, par, exemple /home/chroot/ftp pour l'OS principal était / ; et tous les utilisateurs de l'OS principal n'ont pas à y figurer) et au /etc du chroot, plus globalement (notamment, maintenant que ton daemon ftp tourne dans un chroot, le /etc de l'OS principal n'est plus l'endroit où configurer les applis qui tournent dans ton chroot... il faut aller dans le /etc du chroot, car comme ce sont deux emplacements différents, ils sont maintenant indépendants l'un de l'autre... donc, ce que ton daemon semble appeler chroot_local_user=yes doit être réglé dans le /etc du chroot de ton daemon ftp, et pas dans le /etc principal... ça ne fera pas intervenir /usr/sbin/chroot pour chrooter les utilisateurs de sftp, mais c'est à mon avis comme ça qu'il faut faire)...

[ssc37]

Mouarf quand tu donne une explication tu hésites pas sur le texte Aefron mais il se le lit bien

Ca m'éclaire pas mal sur certaines choses comme "on ne chroot pas un user mais une appli"

L'appli sftp-server n'ayant pas l'air d'avoir la fonctionnalité recherchée, je pensais faire un tour du coté de MySecureShell mais au final je pense que je vais rester avec rssh pour une question de maintenance surement plus simple.

Merci à tous pour tout ses compléments d'infos ^^

[Compte_supprime_74291]

Apparemment, le wiki Gentoo (toujours aussi bonne source d'infos... même quand on a en majeure partie switché à Debian ) confirme que ça ne se fait avec sftp server qu'en créant un chroot par user (ce qui ne résoud donc pas le problème qu'ils aient ainsi accès au / de leur chroot... ce qui est vraiment tout pourri...)...

[ggbce]

Malheureusement le SFTP n'est pas encore un protocole très répandu et les fabricants de logiciels pour cette solution sont très limités contrairement au HTTP -> HTTPS

La plupart des logiciels FTP ne font que du FTP. Le SFTP est possible avec OpenSSH et MySecureShell SFTP-Server. Il existe des solutions sous Windows aussi...

Si tu veux une alternative tu peux regarder du côté de Pure-FTPd qui est un serveur FTP supportant le TLS qui est une autre méthode d'encryption des données. Je crois que les fabricants de serveurs FTP penchent plus sur cette solution également. Comme ça tu auras communication sécurisée et toutes les options d'un vrai serveur FTP. (Je préfère la version Pure-FTPd car il est possible de l'utiliser avec MySQL pour stocker les comptes virtuels et pratiquement toutes les options (Bandwidth, Home, Droits, etc...). J'utilisais VSFTPD avant qui était super et très rapide, mais le manque d'options avec MySQL m'a fait changer.

[ssc37]

Malheureusement le SFTP n'est pas encore un protocole très répandu et les fabricants de logiciels pour cette solution sont très limités contrairement au HTTP -> HTTPS

La plupart des logiciels FTP ne font que du FTP. Le SFTP est possible avec OpenSSH et MySecureShell SFTP-Server. Il existe des solutions sous Windows aussi...

Si tu veux une alternative tu peux regarder du côté de Pure-FTPd qui est un serveur FTP supportant le TLS qui est une autre méthode d'encryption des données. Je crois que les fabricants de serveurs FTP penchent plus sur cette solution également. Comme ça tu auras communication sécurisée et toutes les options d'un vrai serveur FTP. (Je préfère la version Pure-FTPd car il est possible de l'utiliser avec MySQL pour stocker les comptes virtuels et pratiquement toutes les options (Bandwidth, Home, Droits, etc...). J'utilisais VSFTPD avant qui était super et très rapide, mais le manque d'options avec MySQL m'a fait changer.

Merci pour ce complément d'infos, n'ayant pas entendu parlé de TLS je me pencherai sur ce sujet dans le temps histoire de voir le mode de fonctionnement :) et dans un futur repasser à du pur ftp .

Si je peux me permettre un mini HS: j'ai cru voir pas mal de soft qui comme tu le dis rentre dans une base SQL pas mal d'infos, l'interêt est dans la possibilité d'utiliser les comptes users etc.. à travers plusieurs applis? ou c'est une question de sécurité? si un petit link traine pour une explication du principe et de ces raisons je suis preneur

Merci

[zoto]

Salut

Bonjour si tu veux une solution qui permet a partir du même compte de permettre l'acces a plusieurs appli, regarde du coté de ldap .

a+

[ssc37]

Salut

Bonjour si tu veux une solution qui permet a partir du même compte de permettre l'acces a plusieurs appli, regarde du coté de ldap .

a+

Ok zoto, merci je me pencherai donc la dessus pour voir comment tout cela est mis en place