Vous souvenez-vous de PAM (Pluggable Authentication Modules) ? En plus des nombreux modules déjà présentés, on trouve pam_exec qui permet d'exécuter une commande arbitraire. A partir de là on peut faire pas mal de choses, comme par exemple une notification à chaque session ouverte par un utilisateur (connexion ssh, su, sudo, etc.).

Notification de connexion

Nous allons créer une règle utilisant le module pam_exec pour exécuter un script de notification à l'ouverture d'une nouvelle session.

Script de notification

D'après le manuel de pam_exec, les informations PAM sont passées au script à l'aide des variables d'environnement : PAM_RHOST, PAM_RUSER, PAM_SERVICE, PAM_TTY, PAM_USER et PAM_TYPE. Concevons donc un script simple qui :

• ne s'intéresse qu'au cas de l'ouverture d'une nouvelle session, soit le type PAM open_session
• récupère les informations et les envoie par mail à l'administrateur

#!/bin/sh
[ "$PAM_TYPE" = "open_session" ] || exit 0
{
  echo "User: $PAM_USER"
  echo "Ruser: $PAM_RUSER"
  echo "Rhost: $PAM_RHOST"
  echo "Service: $PAM_SERVICE"
  echo "TTY: $PAM_TTY"
  echo "Date: `date`"
  echo "Server: `uname -a`"
} |mail -s "`hostname -s` $PAM_SERVICE login: $PAM_USER" root

On peut sauver ce script sous /usr/local/bin/pam-notify-login et n'oublions pas de le rendre exécutable :

# chmod a+x /usr/local/bin/pam-notify-login

Remarque : vous aurez besoin d'une version récente des modules PAM pour avoir la variable d'environnement PAM_TYPE envoyée par le module pam_exec. En effet celle-ci n'a été ajoutée qu'à partir de la révision 1.8. Concrètement Debian lenny ne l'a pas (libpam-modules 1.0) alors que squeeze l'a (libpam-modules 1.1).

Règle pam_exec

Après consultation de la documentation Linux-PAM, voici la règle à utiliser :

session    optional     pam_exec.so    /usr/local/bin/pam-notify-login

Il faut maintenant l'ajouter à tous les services interactifs (donc pas cron) qui utilisent PAM : SSH, login, su, sudo, etc. Sous Debian (et certainement d'autres distrib), on peut le faire grâce au fichier /etc/pam.d/common-session qu'incluent les services intéractifs. On ajoute donc cette règle à la fin du fichier.

Attention cependant si vous utilisez sudo sous Debian, un petit oubli fait que la règle de sudo n'inclut pas ce fichier. On doit donc rajouter la règle à la main dans /etc/pam.d/sudo en attendant mieux.

Une fois les règles ajoutées, essayez de vous connecter en SSH, de faire un su ou un sudo : vous devriez recevoir la notification par mail.

PS : Ceci est un billet invité, s'il vous a plu, vous pouvez aller lire la prose de StalkR en version originale sur son site.

Si vous avez aimé, il y a aussi :

1. En vrac (20)
2. En vrac (22)
3. Connaitre les protocoles : POP

Sous linux la gestion des droits des processus est héritée de posix et donc extrêmement simple.

Si on exclut les modules de sécurité comme SELinux, il n'y a que deux systèmes. Seul le premier est véritablement connu.

Les droits unix

Un processus porte en lui-même 2 informations associées à ses droits : un utilisateur et un groupe. Ceux-ci permettent de déterminer ses actions possibles sur les fichiers (donc partout puisque tout est fichier) avec les attributs correspondants.

Malheureusement tout n'est pas fichier, pour le reste il existe une distinction entre les processus d'uid 0 (root) et les autres. Cette distinction donne des droits supplémentaires au processus root lors de ses appels système, par exemple l'écoute sur un port inférieur à 1024 ou la possibilité de redémarrer une machine.

Ces droits sont hérités d'un processus à un autre sauf dans 2 cas :

• un fichier exécuté a le bit suid alors on change l'uid du processus (augmentation des droits en général vers root)
• le processus a l'uid root et demande à en changer (réduction des droits, par exemple pour login)

Les capabilities

C'est ici que ça devient intéressant. Sous linux, un processus dispose aussi d'un ensemble de droits spécifiques que peu de gens connaissent.

En supposant que votre noyau soit compilé pour (c'est en général le cas), il associera à chaque processus (pour être précis, chaque thread) un champ de bits lui listant ses droits (dont celui de garder le silence). Ce champ est hérité d'un processus à un autre et, miracle, il peut être associé à un fichier exécutable comme le bit suid.

Le concept est donc le même que pour le couple utilisateur/groupe. Ces droits peuvent changer dans les cas suivants :

• un fichier exécuté a un ensemble de capabilities associé sur le filesystem alors on lui donne les droits associés (augmentation des droits)
• le processus a des droits demande à ne plus les avoir (réduction des droits)
• un processus fils est créé et les droits ne sont pas héritables (non transmission des droits)
• le processus demande des droits supplémentaires qui sont autorisés mais non effectifs

Quels sont ces droits ?

En pratique ces droits ne sont qu'une subdivision des droits de root. Un découpage du bit suid si vous préférez.

On peut en trouver une petite liste dans man 7 capabilities

Comment qu'on fait ?

3 outils sont importants pour travailler avec les capabilities :

• getcap : lire les capabilities d'un binaire
• setcap : modifier les capabilities d'un binaire
• getpcaps : lire les capabilities d'un processus qui tourne

A quoi ça sert ?

Ça sert à ne plus donner les droits root à un programme qui veut juste pouvoir faire un ping. C'est-à-dire qu'il est maintenant possible de réduire les autorisations données à un programme et donc sa sensibilité.

Après une vérification de vos binaires, vous pouvez donc avoir une installation pour laquelle plus aucun binaire n'est suid root !

Vous pouvez créer un logiciel ayant besoin d'une fonction qui n'est accessible que par root et ne lui donner que les droits nécessaires, et ainsi limiter l'impact sur vos utilisateurs en cas de faille.

Dans ma distribution préférée pour quand ?

Je ne peux pas vous répondre, les capabilities existent dans le noyau depuis très longtemps et pourtant les distribution ne semblent pas pressées de s'y convertir (en fait c'est prévu pour fedora, comme quoi mes articles sont d'actualité :-).

Il y a deux explications possibles. La première c'est qu'un noyau n'a pas nécessairement le support des capabilities, ce qui risque de limiter fortement le fonctionnement de la distribution si un utilisateur devait booter sur un tel noyau (mais bon c'est déjà le cas pour d'autres fonctionnalités).

La deuxième c'est que le système de capabilities est un peu plus compliqué que je l'ai décrit. En effet, les capabilities peuvent être "permitted", "inherited" ou "effective" ou une combinaison des 3. Et là c'est l'erreur bête, commune aux outils de sécurité, on complexifie les choses sans apporter beaucoup de valeur ajoutée. Un simple héritage aurait permis à tout un chacun de comprendre et mettre en place des capabilities ...

Si vous avez aimé, il y a aussi :

1. Access Control List
2. Access Control List (bis)
3. Une faille de sécurité

Maintenant que nous connaissons le processus de boot, si on examinait ce processus d'un point de vue de la sécurité !

Lorsqu'on parle de sécurité, il faut d'abord savoir dans quel cas on se positionne et de quoi on cherche à se prémunir. Ici, je considère que le système lui-même est sécurisé. Je suppose que l'attaquant est devant la machine et cherche un accès root.

On considère que chaque élément est sécurisé pour ce qui est de ses propres fonctionnalités, ce qui veut dire que si le bootloader est protégé par mot de passe, il n'y a pas de faille dans le bootloader lui-même permettant d'outrepasser ce mot de passe. Nous nous attacherons donc à chercher ce qui peut être détourné dans le flux d'exécution en entrée et en sortie de chaque élément.

Je vais commencer par la fin, du plus facile au plus difficile.

rc

Rc est lancé par init et ne prend ses paramètres que de init. Ceux-ci sont fixés en dur dans /etc/inittab. Son démarrage ne peut donc être détourné que d'une façon : par modification du contenu du disque. GoTo partition /

Parmi ces paramètres il y a le paramètre 1 qui lance rc dans le runlevel 1, ce qui dans la plupart des cas se termine par un sulogin. Ouf on est protégé par le mot de passe root.

Mais vérifiez bien, dans certains cas il se termine par un simple shell et donc réussir à passer un tel paramètre permettrait à l'attaquant un accès root à votre machine.

Pour passer 1 en paramètre GoTo init

init

Init est lancé par le noyau après lecture de la racine. Il lit sa configuration dans /etc/inittab. Il peut donc être détourné par modification du disque : GoTo partition /

Parmi les paramètres qu'on peut lui passer il y a 1 et S, 1 renvoie au problème ci-dessus et S lance lui-même sulogin, donc même vérification. Ces paramètres viennent du noyau : GoTo noyau

Init est un binaire choisi par le noyau, or il est possible de dire au noyau de changer d'init à travers le bon paramètre. Par exemple, je peux ajouter init=/bin/sh aux paramètres du noyau pour qu'init ne soit jamais lancé qu'un shell apparaisse à sa place. Ça y est je suis root ! C'est d'ailleurs la technique pour changer de mot de passe root lorsque vous l'avez perdu.

Pour changer d'init GoTo noyau.

Init peut aussi être lancé par initrd, il souffre dans ce cas exactement des mêmes problèmes que lorsqu'il est lancé par le noyau : GoTo initrd.

Note upstart, initrdng... :
Il se peut (et ca va être de plus en plus courant) qu'init ou rc soit remplacé par autre chose, type upstart. Dans ce cas seul les noms des paramètres et le format des fichiers change. Mais les impacts sont exactement les mêmes.

Initrd

Initrd prend ses paramètres de la ligne de commande du noyau, mais généralement (il y a plein d'initrd différents) ils sont passés tels quels à init.

D'autre part initrd peut être chargé par 2 moyens, j'ai décrit le bootloader comme un moyen mais le noyau peut aussi charger lui-même l'initrd si on lui demande (avec le paramètre initrd=). On peut donc détourner son chargement par plusieurs moyens : GoTo noyau, GoTo bootloader.

Il est aussi possible de modifier directement l'initrd, par exemple lors d'une réinstallation distante. Celui-ci contenant tout ce qu'on veut, modifier son contenu permet de lancer n'importe que processus ... GoTo partition /boot

Noyau

Le noyau en lui-même ne vous rend pas root mais rien ne vous empêche d'y faire une modification pour qu'il vous fasse root une fois le système chargé.

Le noyau est chargé depuis la partition /boot donc une modification de cette partition et c'est gagné : GoTo partition /boot

Le noyau prend ses paramètres du bootloader, parmi ceux-ci de nombreux paramètres permettent de détourner le système : root= init= initrd= et surement bien d'autres. GoTo bootloader

Partition /

Jusque là, nous n'avons évoqué que les risques mais pas encore de faille. C'est parce qu'aucune interférence de l'utilisateur n'a été possible, tout est automatisé. Mais ça va changer.

Lors du montage de la racine, il y a une interférence possible : le disque contenant / peut avoir été modifié, voire remplacé, pour modifier /etc/inittab, /sbin/init, /etc/init.d/rc ou toute autre chose.

Pour éviter ce problème, il y a deux possibilités :

• mettre un cadenas sur la machine pour garantir l'intégrité physique du disque
• chiffrer le disque

Dans le premier cas, le problème est remonté aux autres couches pour garantir l'intégrité logique et éviter qu'on réussisse à booter sur un autre OS pour modifier le disque. GoTo bootloader.

Dans le deuxième cas, le chiffrement (par exemple avec luks ou truecrypt) doit être assuré par une clé.

• si cette clé est sur la machine et son mot de passe aussi : elle est dans un élément de boot (initrd, partition de boot ...) on reporte le problème GoTo partition /boot
• si cette clé ou son mot de passe n'est pas sur la machine (carte à puce, mot de passe, clé usb ...) alors il y a besoin d'un personne présente à chaque boot ...
• le chiffrement peut aussi être assuré par une puce (TPM) qui ne quitte pas la machine, auquel cas, on garanti que le disque ne quittera pas la machine pour être lu ou modifié (mais pas de garantie contre le formatage), par contre il peut être lu sur place par un autre OS.

Dans tous les cas, seul le démarrage post-noyau est préservé, pour le reste GoTo bootloader.

bootloader

Le bootloader est la source de tous les maux. C'est en effet par lui que l'utilisateur a tout loisir de modifier des paramètres de démarrage.

Le bootloader passe ses paramètres au noyau qui les passe à l'initrd qui les passe à init. Ces paramètres viennent de la configuration du bootloader mais pour un certain nombre de bootloader ils peuvent être directement demandés à l'utilisateur. Dans ce cas il y a moyen d'interdire cette modification à travers un mot de passe. Par exemple grub.

Le bootloader charge sa configuration puis choisit et charge le noyau et l'initrd, tout ceci depuis la partition de boot. Dans tous les cas il doit lire une version non chiffrée, ce qui interdit le chiffrement de cette partition.

Pire, le bootloader est incapable de savoir que le disque n'a pas changé. Donc un simple ajout de disque permet de le faire booter sur un noyau/initrd différent.

Vous ne pouvez presque rien y faire: GoTo partition /boot.

Bon en supposant qu'il n'y a pas de problème, le bootloader est chargé par le bios, il peut donc être détourné : GoTo Bios.

Partition /boot

J'inclue dans la définition de la partition de boot tout ce qui contient la configuration du bootloader, le bootloader lui-même, le noyau et l'initrd, même si ils peuvent être physiquement à des endroits différents. Protéger la partition de boot est très complexe, car tout doit être accessible en clair depuis des outils ayant des fonctionnalités très restreintes.

Les possibilités sont :

• sceau physique sur la machine
• TPM

Mettre un gros cadenas sur la machine permet d'éviter une lecture ou une modification de /boot. Mais il on ne se prémunit pas d'une personne un peu patiente avec un accès complet à la machine.

La dernière solution, complexe à mettre en place et sans garantie absolue est d'utiliser une puce TPM qui va vérifier (mesurer) le bootloader à chaque étape de son chargement, puis vérifier chaque élément que le bootloader charge avant de lancer le noyau.

Bios

Le bios s'exécute tout seul depuis lui-même, il se charge puis lis ses paramètres. Parmi ces paramètres il y a la séquence de boot, qui peut elle-même être modifiée par l'utilisateur.

Il est donc possible, voire facile de dire au bios de booter sur une clé USB et de prendre le contrôle du disque et donc de la machine. Pour éviter ce cas de figure il est possible de mettre un mot de passe au bios. Ainsi on est sûr de booter sur le bon disque, mais seulement s'il y a un cadenas sur la machine puisque le bios ne vérifie pas que le disque n'a pas été remplacé.

GoTo Matériel.

Matériel

Il est possible de changer le bios lui-même. Et ce de plusieurs façons. Si c'est un flash, il est possible de le remplacer logiciellement, si c'est une rom il est possible de la remplacer matériellement.

Et enfin le plus simple pour remplacer le bios est de remplacer la carte mère. Hop ni vu ni connu ...

Pour se protéger de cela ? Le cadenas ... ou la puce TPM, dont la mise en place est toujours très complexe et non garantie.

Conclusion

Résumons-nous car cet article commence à être un peu long. Différencions les cas dont on veut se protéger.

Accès réseau

Si l'attaquant n'a accès à la machine que par le réseau, on est tranquille pour ce qui est de la séquence de boot : No problemo.

Accès KVM

Si l'attaquant n'a accès à la machine que par KVM (pas de possibilité de toucher aux périphériques). Mettre un mot de passe sur le bootloader, le bios et vérifier que le mode rescue demande le mot de passe root devrait suffire. En effet les seul moyen d'attaque sont les paramètres de lancement du système.

N'oubliez pas que le simple accès KVM permet des choses comme le reboot via les magic keys

Accès cadenassé

Si on suppose que l'attaquant peut apporter un CD ou une clé usb sur le système, paramétrer le bios pour booter sur un disque et y mettre un mot de passe est un moyen simple à mettre en place pour éviter le boot sur un autre système.

Mais attention, il ne faut pas que l'utilisateur puisse ouvrir la machine, il pourrait réinitialiser le bios.

Accès au disque sans droit de boot

A partir du moment où l'attaquant a accès au disque c'est presque foutu. Si l'attaquant n'est pas une personne autorisée à booter la machine, il est possible de chiffrer le disque avec une clé qui ne se trouve pas sur le disque. Il faudra alors la rentrer à chaque démarrage. L'attaquant ne disposant pas de cette clé, il me pourra ni lire ni modifier les données où le système. Mais c'est déjà une solution assez contraignante.

D'autant plus que pour être complète cette solution doit garantir le noyau et l'éventuel initrd sur lequel on boote et donc vérifier soi même à chaque boot qu'on utilise une partition de boot non modifiée.

On en arrive au dernier cas ...

Accès complet

Lorsque l'attaquant a un accès complet à la machine, il n'existe qu'un moyen de se protéger (et encore) : la puce TPM.

Elle permet de :

• protéger le bios d'un changement
• protéger le bootloader d'un changement
• protéger le noyau d'un changement
• protéger le contenu du disque d'un changement

Mais tout cela est compliqué et nécessiterait un autre article que je ne suis pas encore prêt à faire, je n'ai même pas de puce TPM chez moi.

PS : Notez une dernière chose que je n'ai pas abordé, le chiffrement des données. Le chiffrement du disque contenant les données (/home et /srv selon vos besoins) devient obligatoire dès qu'on prévoit qu'il y aura un accès physique. Il doit de préférence se faire avec un moyen propre à l'utilisateur (mot de passe / clé / carte à puce ...) pour éviter les attaques à travers le boot de l'OS.

PPS : Considérez qu'a partir du moment où quelqu'un a un accès physique à votre machine c'est mort.

PPPS : Sauf si votre machine est une carte à puce.

PPPPS : Et encore ...

Bon courage !

Si vous avez aimé, il y a aussi :

1. Processus de boot
2. Mesurer le temps de boot
3. Réinstallation distante

Il y a quelques années, le format de stockage des mots de passe unix a changé, permettant de passer du trop simple DES à un algorithme de votre choix. Au passage le stockage s'est fait dans /etc/shadow pour limiter encore plus l'accès à la version chiffrée de ces mots de passe.

Traditionnellement on utilise un hashage MD5 des mots de passe, ce qui se reconnaît par un $1$ au début des mots de passe dans le fichier shadow.

Mais il se peut que vous n'ayez plus confiance en MD5, dans ce cas, rien ne vous empêche d'utiliser un autre algorithme. C'est très simple; il suffit de modifier /etc/pam.d/common-password ou l'équivalent de votre distribution avec la ligne suivante :

password   sufficient  pam_unix.so min=4 sha256

Et changez votre mot de passe, vous verrez alors le préfixe devenir $5$ dans le fichier shadow. Les valeurs possibles sont les suivantes :

• md5 : $1$
• sha265 : $5$
• sha512 : $6$
• blowfish : $2a$ (déclaré comme fonctionnel seulement sur certaines distributions)

Si la valeur n'est pas comprise par pam_unix c'est la valeur par défaut (MD5) qui sera utilisée.

Sinon tant que vous êtes là à regarder bêtement votre configuration pam, profitez-en pour mettre en place pam_cracklib.

Si vous avez aimé, il y a aussi :

1. Détecter les mots de passe faible
2. Génération automatique de mots de passe (bis)
3. Générer des mots de passe

Suite de la formidable série :

Et après les comptes ?

Il est aussi possible d'utiliser libnss-ldap pour autre chose que pour les comptes utilisateurs. La bibliothèque NSS étant une bibliothèque générique de résolution de nom, il est possible d'utiliser le ldap pour :

• les groupes (attention pas de login pour newrp à travers pam de prévu)
• les noms de machine
• et d'autres qui ne pas très intéressants pour l'instant ...

Pour cela, rien de plus facile, tout est déjà fait, il suffit de modifier la ligne correspondante dans /etc/nsswitch.conf et de commencer à peupler le LDAP.

Un groupe est définit comme suit :

objectClass: posixGroup
cn: mongroupe
description: goupe a moi
gidNumber: 1000
memberUid: peck
memberUid: amiami

Notez que la description est optionnelle et que les membres sont décrits par uid. Le userPassword est aussi disponible mais n'est pas utilisable actuellement pour les groupes du système.

Exemple de machine (plus besoin de DNS local ;-) :

objectClass: ipHost
cn: mamachine
ipNetworkNumber: 1.2.3.4

S'adapter à l'existant

Il est possible que vous ayez à gérer un serveur ldap existant avec ses comptes et son propre schéma (active directory ?). C'est pourquoi il existe des options de mapping dans la configuration de pam_ldap et nss_ldap.

Ces options sont assez simples, il s'agit de reparcourir votre schéma et pour chaque entrée nécessaire pour le système, expliquer au fichier de configuration quel est le nom de l'attribut ou de la classe que vous utilisez sur le ldap. Ceci est à faire une fois pour nss et une fois pour pam.

Les commandes sont :

• nss_map_objectclass : changer une classe utilisée par libnss-ldap
• nss_map_attribute : changer un attribut utilisé par libnss-ldap
• nss_default_attribute_value : donner une valeur par défaut à un attribut (pratique pour le shell par exemple)
• pam_login_attribute : change l'attribut servant à matcher le login pendant l'authentification
• Il n'est pas possible de changer l'attribut utilisé par pam pour le mot de passe (normal c'est le serveur ldap qui gère).

Les classes modifiables (en restant dals le domaine utilisateur/groupe) sont

• posixAccount : utilisateur ayant un compte unix
• shadowAccount : utilisateur ayant un système avancé de gestion de mot de passe
• posixGroup: groupe unix

Les attributs modifiables sont : uidNumber, gidNumber, gecos, homeDirectory, loginShell, shadowLastChange, shadowMin, shadowMax, shadowWarning, shadowInactive, shadowExpire, shadowFlag, memberUid

Plus de détails (et plus de clesses) dans la RFC 2307.

La configuration fournie avec le paquet donne des exemples pour les différents systèmes existants (aix, microsoft ...)

libnss-ldapd

Maintenant vous pourriez avoir d'autres problèmes, comme la performance ou quelques hoquets du réseau qui coupent des connexions. La solution traditionnelle pour cela est d'installer nscd qui fera un cache et vous évitera ces problèmes (et peut en créer d'autres puisque c'est un cache).

Mais il existe une autre solution : libnss-ldapd, notez bien le 'd' final. C'est une version de libnss-ldap réécrite pour parler à un démon qui est le seul à parler avec le serveur ldap. Ça a l'avantage de mutualiser les requêtes dans une seule connexion et donc d'éviter pas mal de problèmes, surtout en cas de forte charge.

Petit inconvénient pour les puristes, ça ouvre une faille potentielle (inconnue à ce jour) pour un utilisateur qui voudrait devenir administrateur via le serveur ldap, puisque ce n'est plus le noyau qui vérifie les droits root d'administration mais le démon.

Le démon se configure dans /etc/nss-ldapd.conf. La syntaxe est la même que pour pam_ldap et libnss-ldap, le contenu ne doit pas changer.

Le démon est du coup assez important, il faut vérifier qu'il est lancé (monitorer toussa ...). Il s'appelle nslcd.

Sécurité et performances

Si vous avez beaucoup d'utilisateurs vous pouvez vouloir restreindre les recherches.
Si vous avez des utilisateurs qui ne doivent pas tous avoir accès au système, vous pouvez vouloir restreindre les recherches.

C'est pourquoi nss et pam fournissent des directives pour réduire la taille des recherche et donc la liste des utilisateurs :

• base : réduit l'accès à toutes les commandes LDAP à une seule branche
• scope : indiquer si la recherche doit tester les sous branches ou non
• nss_base_<map> : permet d'indiquer à ldap de se limiter à une requête pour un type donné de résolution, map peut valoir passwd, shadow ou group (ou hosts, services, networks, protocols, rpc, ethers, netmasks, bootparams, aliases ou netgroup). Exemple : nss_base_passwd ou=users,dc=linux-attitude,dc=fr?sub?uid>1000
• pam_filter : permet de modifier la partir filtre pour pam (pas besoin de modifier le reste car il n'y a qu'une requête faite par pam). Exemple : pam_filter uid>1000

Si vous avez aimé, il y a aussi :

1. Comptes ldap (1)
2. Comptes ldap (3)
3. Comptes ldap (2)

Désolé, j'ai oublié la suite de la série LDAP. On peut faire un peu mieux que la dernière fois.

Changer son mot de passe

Nous n'avons pas activé le changement de mot de passe. Pour cela, c'est assez simple, il suffit de modifier common-password (cela peut être ailleurs pour certaines distributions ...) :

password   sufficient   pam_unix.so nullok obscure min=4 max=8 md5
password   sufficient   pam_ldap.so

Il faut aussi modifier /etc/pam_ldap.conf pour que pam ne modifie pas directement le mot de passe, mais utilise les fonctions de ldap prévues à cet effet. Cela permet qu'il ne soit pas stocké en clair, mais avec la méthode définie dans la configuration de ldap ({SSHA} par défaut).

# A ajouter dans /etc/pam_ldap.conf
pam_password exop

Et voilà vous pouvez tester la commande passwd. Mais vous constaterez qu'il y a quelque chose qui cloche. Si vous lancez la commande en root, l'ancien mot de passe vous est quand même demandé. C'est parce que vous n'avez pas les droits d'administrateur sur le ldap.

Pour remédier à cela, il vous faut un compte ldap qui a le droit de modifier le champ password des autres utilisateurs, par exemple l'administrateur ldap. Puis renseignez ce compte dans pam_ldap.conf :

# /etc/pam_ldap.conf
# Il faudra stocker le mot de passe correspondant en clair dans /etc/pam_ldap.secret
# Ce fichier doit appartenir à root et être en mode 600
rootbinddn cn=admin,dc=linux-attitude,dc=fr

Ça y est vous êtes prêts.

chsh, chfn, adduser

Les utilisateurs ont le droit de changer leur shell ainsi que leurs informations personnelles. Pour cela ils ont les commandes chsh et chfn.

Malheureusement ces commandes manipulent /etc/passwd. Le paquet libpam-ldap fournit des script pour remplacer ces commandes, mais ils sont un peu basiques et nécessitent libnet-ldap-perl (Net::LDAP). Vous pouvez vous baser dessus pour faire les votres si vous pensez que ces fonctionnalités sont indispensables pour vos utilisateurs. On les trouve dans /usr/share/doc/libpam-ldap/examples/ . un certain nombre de paramètres sont codés en dur et peu de vérifications d'erreur sont faites.

Si vous modifiez vos binaires dans /usr/bin sur debian, faites attention la prochaine mise à jour risque de les remplacer. Pour éviter ce problème, il existe la commande dpkg-divert :

# On fait croire aux paquets qu'ils installent /usr/bin/chfn alors qu'ils installent en réalité /usr/bin/chfn.old
$ dpkg-divert --add --rename --divert /usr/bin/chfn.old /usr/bin/chfn
# voila, vous pouvez maintenant remplacer /usr/bin/chfn

Autre problème, adduser ne comprend pas non plus le ldap. Ici le problème est le même mais la solution un peu meilleure. Un paquet ldapscripts est disponible et il contient des commandes comme ldapadduser pour vous faciliter la création d'utilisateurs ldap. Les commandes sont configurées dans /etc/ldapscripts/ .

Tout ceci pourrait s'améliorer dans de prochaines versions, un patch a l'air en cours de développement pour le paquet shadow (qui contient ces outils) qui utiliserait la libnss pour effectuer ces actions. Les commandes fonctionneraient donc directement.

Quelques remarques

Depuis que nous avons des vrais comptes systèmes basés sur le ldap nous sommes contents. Mais quelques petites choses tout de même :

• Gardez le compte root sur le système, on ne sait jamais, si le ldap tombe, vous seriez bien embêtés
• Faites attentions aux droits dans le ldap, ils impactent les fonctionnalités des commandes systèmes (droit de lister les autres utilisateurs par exemple)
• Avec un serveur distant, le ldap devient une forme de NIS
• Vous pouvez utilisez la réplication ldap pour résister aux crash
• Vous pouvez toujours garder une mot de passe local au cas où le ldap ne marche pas (pam fait les 2)
• Vous pouvez vous connecter à un controleur de domaine windows
• Si vous avez de problèmes les logs d'authentification sont dans /var/log/auth.log
• Vous pouvez vouloir ne mettre en place que l'authentification via pam et ne pas utiliser libnss. Ce cas correspond à des utilisateurs virtuels (comme pour le ftp) qui n'utiliseront pas alors de vrai compte sur le système.

Si vous avez aimé, il y a aussi :

1. Comptes ldap (2)
2. Comptes ldap (1)
3. Comptes ldap (4)

Hier nous avons créé un compte sur le ldap. Bien, mais on ne pouvait pas en faire grand chose. Il faut maintenant pouvoir se connecter. Il est théoriquement possible de tout faire avec libnss mais c'est à la fois plus difficile et moins fonctionnel qu'avec pam.

Comme vous le savez l'authentification sous linux se fait avec PAM. Nous allons donc utiliser un module dédié : libpam-ldap (cool le paquet porte le même nom).

LDAP

Cette fois ne nous force à utiliser aucun objectClass, mais comme il sait utiliser les attributs de la classe shadowAccount, on peut utiliser celle-ci pour se simplifier la vie.

Ajoutons le mot de passe à notre utilisateur. On crée le mot de passe LDAP à la main, mais par la suite vous verrez que ce n'est pas indispensable.

$ slappasswd -s test
{SSHA}l5X6sBFomfk3tk02HEMWK4YLep7pqZDk

On ajoute ce mot de passe à l'utilisateur déjà créé :

$ ldapmodify -x -D "cn=admin,dc=linux-attitude,dc=fr" -W
dn: uid=peck,ou=people,dc=linux-attitude,dc=fr
changetype: modify
add: userPassword
userPassword: {SSHA}l5X6sBFomfk3tk02HEMWK4YLep7pqZDk

Un test de connexion avec ldapsearch vous montrera que le mot de passe est bien pris en compte :

$ ldapsearch -x -D "uid=peck,ou=people,dc=linux-attitude,dc=fr" -w test "uid=peck"

PAM

Maintenant il faut expliquer gentiment à PAM d'aller faire son authentification en utilisant LDAP. Pour cela hop, configuration dans /etc/pam.d/common-*. Certaines distributions devront peut-être configurer chaque élément un par un : su, login, ssh ...

# common-auth
# attention, le pam_unix devient sufficient
auth    sufficient    pam_unix.so nullok_secure nodelay
# use_first pass permet de ne demander qu'une fois les mot de passe pour les 2 modules
auth    sufficient    pam_ldap.so use_first_pass 

# common-account
account    required    pam_unix.so
account    sufficient   pam_ldap.so

# common-session
session    required    pam_unix.so
session    optional    pam_ldap.so

Maintenant attaquons-nous au fichier de configuration proprement dit : /etc/pam_ldap.conf. En voici l'essentiel :

# /etc/pam_ldap.conf
base ou=people,dc=linux-attitude,dc=fr
uri ldap://127.0.0.1/
ldap_version 3

Vous remarquerez que pam_ldap.conf et libnss-ldap.conf ne rentrent jamais en conflit. Vous pouvez faire un lien de l'un vers l'autre ou modifier la configuration pour que ce soient les mêmes fichiers. Cela peut vous éviter quelques désagréments.

Test

Maintenant tout marche, même l'authentification. Faites le test :

$ su - peck
Password:
$ id
peck

Youpi, ça marche même en ssh. Bon c'est bien gentil, mais c'est encore un peu léger. La prochaine fois , on voudrait pouvoir faire encore plus.

Si vous avez aimé, il y a aussi :

1. Comptes ldap (1)
2. Comptes ldap (3)
3. Comptes ldap (4)