Le blog de Shnoulle

Bricolage en informatique et autres joyeusetées

Accueil > Logiciels libres > GNU/Linux > Chroot sftp: solution sftponly, bind et acl : accès sécurisé sur un serveur de (...)

Chroot sftp: solution sftponly, bind et acl : accès sécurisé sur un serveur de sauvegarde

vendredi 9 octobre 2009, par Shnoulle

Pour chrooter les utilisateurs ftp ou mieux sftp, il existe énormément de possibilités, ayant eu besoin d’un accès sécurisé pour les utilisateurs d’une entreprise aux sauvegardes effectuées sur un serveur linux, j’ai cherché une solution pour offrir un accès sécurisé permettant à chacun de partager les fichiers en lecture, en lecture/écriture selon ses besoins.

J’utilise sftponly [1], bind [2], et les ACLs [3]

Ce que je voudrais

Pour les utilisateurs d’un groupe particulier :

  1. Accès en lecture sur la partie sauvegarde du serveur interne sur le serveur externe
  2. Accès en lecture/écriture sur une partie dédiée au transferts (commune au différents groupe)
  3. Accès en lecture/écriture sur une partie dédiée au transferts pour ce groupe uniquement.
  4. Accès en lecture/écriture sur des documents partagés via webshare

Il était hors de question que je permette à mes utilisateur un accès complets à la machine, et que les fichiers se baladent sur internet non crypté, la solution la plus simple me semblait le sftponly.

sftponly pour limiter l’accès des utilisateurs

Le sftponly permet de chrooter facilement n’importe quel utilisateur sur son répertoire home.

Il suffit pour cela d’ajouter dans le fichier de configuration du serveur (/etc/ssh/sshd.conf par exemple)

Match group sftponly
 ChrootDirectory /home/%u
 X11Forwarding no
 AllowTcpForwarding no
 ForceCommand internal-sftp

Ensuite pour qu’un utilisateur ne puisse plus qu’accéder à son répertoire home via sftp, il suffit de l’ajouter au groupe sftponly. Il faut que son répertoire appartienne à root, donc , pour utilisateur :

chown root.root /home/utilisateur
usermod -d / utilisateur
adduser utilisateur sftponly

Il suffit ensuite de créer un ou des répertoire(s) dans ce dossier, de leur associer l’utilisateur en tant que propriétaire pour que celui-ci est un système de sauvegarde et de transfert sécurisé.

L’utilisateur n’a plus accès que à ses fichiers, ne peut plus se connecter en ssh. Ce qui est parfait pour mes utilisateurs. Par contre, pas d’accès à des répertoire partagé, pas d’accès aux fichiers déjà partagé ... C’est là qu’intervient bind.

mount bind pour accéder à d’autres fichiers

la commande mount permet de monter une partie de l’arborescence sur un répertoire. La commande pour le faire est celle-ci : mount --bind olddir newdir

Dans notre cas, nous allons ajouter le répertoire de sauvegarde et un répertoire totalement partagé.

$ mkdir /home/utilisateur/partage
$ mkdir /home/utilisateur/sauvegarde
$ mount --bind /ouquevousvoulez/partage /home/utilisateur/partage
$ mount --bind /ouquevousvoulez/sauvegarde /home/utilisateur/sauvegarde

et ajouter les lignes suivantes au fstab pour que les répertoires montés soit constants.

/ouquevousvoulez/partage /home/utilisateur/partage none bind 0 0
/ouquevousvoulez/sauvegarde /home/utilisateur/sauvegarde none bind 0 0

En donnant les droits correspondants, ca semble fonctionner (par exemple :

$ chmod -r a+rw /ouquevousvoulez/partage
$ chmod -r a+r /ouquevousvoulez/sauvegarde

Cependant le prochain fichier (ou répertoire ) ajouté va prendre les droits voulu par l’umask. Ce n’est toujours pas ce que l’on veut. C’est là que l’on met en place les acl.

Utilisation des ACL (Access Control List)

Les ACLs permettent de gérer finement les droits sur les répertoire ou fichier linux, ils permettent de modifier les droits existant pour un utilisateur ou un groupe en particulier, mais aussi les droits par défauts.

Dans un premier temps , il faut que les ACLs soient activés sur le point de montage voulu. Dans notre cas, nous admettons que notre point de montage est /ouquevousvoulez/. Sa ligne dans le fstab est celle ci.

/dev/sd1        /ouquevousvoulez        ext3        defaults        1        2

. Il suffit d’ajouter acl derrière le defaults, donc :

/dev/sd1        /ouquevousvoulez        ext3        defaults,acl        1        2

.

Ensuite : umount /ouquevousvoulez , et mount -a pour vérifiez que le noyau permet bien le montage avec les ACLs [4] et que vous n’avez pas fait d’erreur sur le montage.

Il faut ensuite pouvoir gérer ses droits supplémentaires, nous allons utiliser 2 commandes : setfacl et getfacl.

Dans un premier temps, nous allons créer un groupe pour l’entreprise (nous pourrions avoir plusieurs entreprises, ou gérer des groupes séparer (comptabilité, direction ... ) . groupadd entreprise et ajouter notre utilisateur à ce groupe : gpasswd -a utilisateur entreprise.

Il faut ensuite donner les droits correspondants via les acl sur les répertoires voulus, dans notre cas, cela se feras comme ceci (en retirant les droits que nous avions accordés aux autres) :

$ chmod -r A-rwx /ouquevousvoulez/sauvegarde
$ chmod -r A-rwx /ouquevousvoulez/transfert
$ setfacl -Rm d:g:entreprise:rX /ouquevousvoulez/sauvegarde
$ setfacl -Rm d:g:entreprise:rwX /ouquevousvoulez/transfert

Attention, les ACLs ne retirent pas les droits par défaut, mais ajoutent une nouvelle possibilité. Ils permettent aussi de modifier les droits par défauts des groupes unix. Il peut être intéressant de vérifier ensuite les droits sur les répertoire via un getfacl /ouquevousvoulez/sauvegarde.


J’ai fait cette présentation à postériori, elle n’est sans doute pas exempt d’erreurs ou d’approximation. Elle me sert de base à une gestion complète des droits des utilisateurs d’une petite entreprise d’une 15aine de personne. Il doit être possible de créer un script pour l’ensemble du processus d’ajout d’un nouvel utilisateur avec ses droits, cependant celui ci risque d’être trop spécifique à une entreprise en particulier. Il est sans doute possible de lier cette solution avec des utilisateurs LDAP


[1A voir concernant sftponly : Un pas de plus vers la démocratisation du sftp

[2via la commande mount

[4activé dans la plupart des distributions modernes, si ce n’est pas le cas vous pouvez consulter lea-linux.

Messages

    • Oui, sauf que openssh, mount et le système des ACLs de Linux sont, je pense, plus proche du noyaux. Et ils sont inclus dans tous les dépots de base directement.

      De plus MySecureShell ne remplace mount/bind , si ? ni les ACLs complètes ?
      Par contre , il ajoute le contrôle de la bande passante. Mais je n’en ai pas besoin, donc sftp-only me suffit. :)

      Mais sinon, oui, il existe mysecureshell, mais c’est loin d’être les seules solutions pour le chroot sftp:)

Un message, un commentaire ?

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.