Tout ce que vous avez toujours 
voulu savoir sur la sécurité sous
SAMBA
sans jamais ôser le demander



La grande majorité des documentations concernant Samba expliquent souvent comment installer un serveur samba basique avec deux partages de fichiers et tout le monde qui fait ce qu'il veut dessus, parce que l'essentiel est que ça tourne, et qu'on accède au fichier. Il existe de très bonnes docs qui détaillent très bien les fonctions de sécurisation grâce au fichier smb.conf, mais qui négligent franchement l'intégration des partages avec la sécurité unix. Il n'existe aucune doc qui explique l'interraction entre les partages, la sécurité unix, et les acls posix.
Ce document en devenir espère vous donner une meilleure compréhension de tout ça. Il n'a pas vocation de remplacer la page de manuel de smb.conf, il n'a pas non plus pour vocation de vous expliquer en long et en large toutes les méthodes d'installation et de compilation de samba, parce qu'il existe d'excellents documents pour ça. Sa vocation est d'apporter aux débutants sous samba une vision d'ensemble concernant l'accès aux objets dans samba, et aux administrateurs qui l'exploitent le petit plus qui leur donnera une meilleure apréhension du produit  (s'ils avaient un peu le nez dans le guidon.)


Quelque chose qui marche de suite.

Pour les feignasses qui estiment qu'elles n'ont pas de temps à perdre à lire de la documentation, que j'ai passé plusieurs dizaines d'heures à écrire, voici un exemple de fichiers smb.conf et le paramétrage qui va avec. Ca devrait marcher dans presque tous les cas.

En console
 dans smb.conf
 
#mkdir /partage
#chmod 777 /partage
vous créez maintenant votre fichier smb.conf
vim /etc/samba/smb.conf. Vous y mettez tout
 ce qu'il y a dans la partie de droite.
#/etc/rc.d/init.d/samba restart
(ou)             /smb restart
(ou) 
#/etc/init.d/samba restart
(ou)        /smb restart
 [global]
        workgroup = MARCEL
        netbios name =  PAGNOL
        security = user
       
[partage]
        path = /partage
        public = yes
        read only = no

Votre groupe de travail s'appelle MARCEL et votre serveur samba s'appelle PAGNOL. le partage s'appelle "partage", et vous pouvez y mettre tout ce que vous voulez.

Voilà. Vous pouvez entrer et écrire dans votre partage. Vous pouvez refermer ce document, vous n'avez rien apris, vous n'avez rien compris. Merci quand même et bonjour chez vous.  ;-) Non? Vous restez? Vous êtes rassurés, vous avez un partage pour mettre vos divx, vous avez donc désormais le temps de comprendre comment ça marche? Par ici pour le sens de la visite, ça commence de suite.

Un système de sécurité Multi-couche.


Ce qu'il est nécessaire de comprendre avant toute chose, c'est que l'accès aux objets sous samba fonctionne en couches. Il y en a au moins deux: la couche samba, et la couche système unix. Lorsque l'on tente d'accéder à un objet, il faut que celui-ci existe à la fois au niveau du serveur samba, sinon, on ne le voit pas dans le voisinage réseau, mais aussi au niveau unix, parce que samba est un serveur qui s'appuie sur des objets réels du système. En effet il s'agit d'un serveur de fichier (principalement), les fichiers reposent sur...  ...le système de fichier, et l'accès à ces fichier unix. L'accès aux objets requiert donc que cet accès soit possible pour les utilisateurs samba, et pour les utilisateurs du système.

C'est pour cette raison qu'il faut une double base utilisateurs.
La première est la base des utlisateurs unix stockée (sur la majorité des sytèmes) dans /etc/passwd.
La deuxième est la base des utilisateurs samba, qui se trouve dans le fichier smbpasswd (le plus souvent dans /etc/samba/smbpasswd).
Il existe une 3ième base d'utilisateurs qui recence d'éventuels alias d'utilisateurs existants dans smbpasswd, il s'agit le plus souvent du fichier smbusers.

Voilà. Vous venez de comprendre un des fondements de Samba. Notez bien que sur un serveur Windows, le fonctionnement sensiblement le même:
On commence par permettre aux utilisateurs d'entrer dans le partage, et ensuite, on leur permet d'accéder à l'objet sur le système de fichier.

Passons à présent à des concepts de sécurité plus large.

Les différents modèles de sécurité

Ce n'est un secret pour personne que Samba imite le système de partage des machines microsoft. Quand on créé un partage, on la possibilité de ne donner l'accès à personne (on se demande bien où se trouve l'intéret), ou de donner l'accès à tout le monde (partage de la boite de chocolat), ou de donner l'accès à certaines personnes seulement (partage de votre voiture). Pour les deux premiers cas, on voit mal l'intéret de débattre.
Pour le dernier cas, on va affiner.
Comment va-t-on permettre l'accès ou non à la voiture?
    -Première solution: Il faut un clé. Tous ceux qui ont la clé peuvent utiliser la voiture. Au niveau des partages smb, on appelle ça une sécurité de niveau ressource.
    -Deuxième solution, on met un gardien près de la voiture, qui va permettre à certaines personnes de l'utiliser, et pas à d'autres. C'est une sécurité de niveau utilisateur

Sécurité de niveau partage, et sécurité de niveau utilisateur

La sécurité au niveau ressource est typiquement celle implantée au départ pour les machines de type Windows 95-98-Millenium.
De quoi s'agit-il?: Au moment du partage, on définit un mot de passe pour la partage, pour la lecture, ou l'écriture/lecture. C'est effectivement très simple, mais ça a un assez gros inconvénient: Si votre voisin connait le mot de passe il accède aux données. En clair, il suffit de faire une copie de la clé de contact pour démarrer.

La sécurité au niveau utilisateur est celle liée aux machines de type Windows NT-2000-XP
Ici, on ne rentre plus comme dans un moulin: On va pouvoir mettre en oeuvre une sécurité plus fine. Manu a le droit de conduire la voiture, Simone a le droit de monter dedans, tandis que les autres ne peuvent que la regarder. Maintenant, il ne suffit plus de voler la clé, il faut surtout être la bonne personne. La seule manière de piquer la Porche de papa, c'est de se faire passer pour papa.
En termes plus informatiques, il y a une base de comptes avec les noms des utilisateurs, et on autorise (ou pas) des utilisateurs ou des groupes d'utilisateurs.
A première vue, la différence n'est pas bien grande. Il suffit de connaitre le nom de l'autre personne, et éventuellement son mot de passe pour accéder aux fichiers de la paye. De ce point de vue, c'est vrai. Mais résumons un peu les choses avant de reprendre:
Dans le premier cas, n'importe qui pourvu que le mot de passe soit bon.
Dans le deuxième cas, uniquement la bonne personne.

Cela fait qu'une machine de type Windows NT qui tente d'accéder à une machine de type Windows 95 pourra fournir n'importe quel nom d'utilisateur, pourvu que le mot de passe soit bon. Cela fait aussi que pour qu'un utilisateur se connecte depuis une machine Windows 98 à une machine de type NT, il faudra d'abord que cet utilisateur se soit connecté sur la machine Windows 98 avec le nom d'un utilisateur existant aussi sur la machine NT et autorisé à accéder au partage! Imaginons que vous avez l'habitude d'utiliser votre PC sous Windows 9x avec l'utilisateur vandamme, mais que le partage sur la machine Windows NT ne soit accessible qu'à l'utisateur noris, vous serez obligé de fermer la session vandamme et de la réouvrir sous le nom noris pour pouvoir utiliser le partage sur la station NT.

Sur samba la décision du mode ressource ou du mode utilisateur se fait avec l'option security =.
security = share définit une sécurité au niveau ressource, comme pour une machine Windows 9x
security = user définit une sécurité au niveau utilisateurs, comme pour une machine de type Windows NT

Voilà. Vous venez enfin de comprendre à quoi sert véritablement cette maudite option du fichier smb.conf.
Hep là!! C'est loin d'être fini, retournez vous assoir, ce n'est pas l'heure de la récré.

Le mode "share" peut sembler idéal pour un réseau domestique. Il y a cependant des inconvénients à l'usage de ce mode. En effet, le démon smbd, essaierai toujours de faire correspondre un utilisateur Unix existant avec le client. Il utilise plusieurs moyens pour tenter de faire correspondre les deux, comme récupérer le nom netbios du client, ou le nom d'utilisateur éventuellement fourni lors d'une précédente connexion, ou un nom de la liste user, ou le nom du service....  Cela fait qu'il n'est pas évident dans ce mode de savoir quel est le nom d'utilisateur qui a réellement été utilisé. Le mode share sera essentiellement utilisé pour des serveurs d'impression avec des imprimantes en libre service.
Pour le reste, je vous conseille d'utiliser le mode "user" qui est d'ailleurs le mode par défaut, actuellement.

Et le mot de passe de l'utilisateur, en mode user, il sert à quoi, alors? Hé bien il ne sert pas véritablement à donner ou non l'accès à la ressource. Il sert surtout à confirmer que l'utilisateur bizarre avec sa casquette nike retournée est bien celui qu'il prétend être, et que donc on peut lui donner accès au partage R&B. En revanche, une fois que l'utilisateur aura bien prouvé qui il est, il pourra accéder aux autres partages de la machine NT sans avoir à re-décliner son identité.
En revanche, dans le cas d'une sécurité au niveau partage, on devra fournir le mot de passe pour chaque nouveau partage explorer, même sur la même machine, et même si le mot de passe est le même pour tous les partage.

C'est là qu'on commence à entrevoir tout l'intéret du mode de sécurité utilisateur: Dans certaines conditions, il suffira de montrer sa carte d'identité une seule fois pour accéder aux ressources de plusieurs partages différents sur plusieurs machines différentes. L'autre intéret, le voici: A partir du moment où on est certain d'avoir affaire à la bonne personne, il est tout à fait possible de lui proposer tous les services qui lui sont dûs, sans que celui-ci ait besoin de venir les demander.

Cela nous conduit directement à la problématique de sécurité suivante: sécurité éclatée, ou sécurité centralisée? En d'autres termes, groupe travail ou domaine?


Les notions de groupe de travail et de domaine.

Imaginons

Problématique d'insertion dans un domaine NT: "security = server" ou "security = domain"?


L'interraction entre le partage et le système de fichier


-Interraction classique sans acls

Par défaut
Avant de commencer toute explication, je prends pour base qu'au niveau de votre smb.conf, il y a une section [global] minimale qui permet de voir les partages.
Je prends aussi pour base que vous avez au moins un partage existant avec un paramétrage minimal du type:
[testacl]
        path = /_data/testacl
Qui définit donc le nom du partage et le chemin du répertoire dans le système de fichier.
drwxr-xr-x    2 root     root            6 Nov 14 16:49 testacl

- Interraction avec les acls





Domaine samba

permissions héritées.

Sauvegarde de la configuration de Samba.

Sauvegarde d'une machine windows via samba