PAM est LE système
d'authentification utilisé en standard sous Linux. La
puissance de cet outil est sans limite mais il n'est pas toujours
bien documenté ce qui a tendance à le desservir. En
guise d'introduction, arrêtons nous tout d'abord sur les
motivations qui ont entraîné la création de PAM.
A l'origine, sous Unix (et dans les
premières versions de Linux), le fichier qui centralisait la
gestion des utilisateur était /etc/passwd. Il contenait nombre
d'informations sensibles, dont le mot de passe chiffré. Or,
pour pouvoir utiliser une machine Unix, la première chose
à
faire était de s'authentifier via le programme login
(dernier programme lancé par init). Ce programme avait
donc été développé pour parser le fichier
/etc/passwd.
Cependant, avec le temps, on s'est
apercu que stoquer les mots de passe utilisateur dans un fichier en
lecture pour tout le monde pouvait représenter un trou de
sécurité (les machines personnelles étant de
plus en plus aptes à effectuer du brute force pour retrouver
des mots de passe). Cette constatation a eu pour conséquence
la création d'un fichier de mot de passe déporté
appelé /etc/shadow (date).
Seulement, login devait être
réimplémenté pour prendre ce changement en
considération. Il en était en fait de même pour
tous les programmes qui nécessitaient une authentification
(ftp, su, sudo...).
Par la suite(date),
on s'est appercu que disposer d'un fichier plat pour
l'authentification pouvait représenter une certaine limite
lorsque l'on manipulait des dizaines de miliers de comptes. D'autres
base de données furent donc été utilisées,
telles que les annuaires. L'idée fut révolutionnaire
mais le problème était qu'encore une fois, il fallait
réécrire certaines parties du code d'authentification
des applications concernées.
Ces constatations faites (quelques
heures de génie logiciel et quelques centaines de miliers de
lignes de code plus tard), les développeurs du noyau Linux ont
eu l'idée de déporter toute la couche
d'authentification en dehors des programmes en ayant besoin. Ils ont
donc créer les Pluggable Authentification Modules.
Linux PAM est un jeu de bibliothèques
dynamiques gérant des points précis du processus
d'authentification. Nous verrons ci-après que lorsque nous
parlons d'authentification, nous ne nous limitons pas au simple
challenge login/mot de passe, mais bien à un ensemble de
points d'authorisation pouvant affecter aussi bien l'authentification
à proprement parler que les sessions ou la gestion des mots de
passe.
Une application peut donc être
développée pour se lier dynamiquement à ces
bibliothèques et donc accéder à des
fonctionnalités déjà implémentées
et stables. A ce titre, Linux PAM met à la disposition des
développeurs une API détaillée des fonctions
disponibles. <POINTEUR>
Pour information, ces bibliothèques se trouvent généralement
dans le répertoire
/lib/security.
Du point de vue de l'administrateur
système, cela lui permet de configurer le comportement à
tenir pour toutes ses applications nécessitant une
authentification. La seule restriction étant que l'application
soit « PAM enabled », c'est a dire qu'elle soit
développée pour utiliser les librairies PAM. Se
reporter à la documentation de l'application en cas de doute.
L'administrateur peut donc s'il le
souhaite définir que pour un service donné (par exemple
xdm), l'authentification se fera en 3 étapes distinctes
(matérialisées par l'utilisation de 3
bibliothèques
dynamiques, donc 3 modules) auquel il passera des arguments de
configuration.
Il peut donc choisir exactement sa
propre politique d'authentification pour cette application,
indépendamment de celle-ci.
Dans la terminologie PAM, configurer
une application revient a configurer l'accès au service.
Ainsi, si vous installez proftpd ou wuftpd, vous fournirez le service
ftp à vos utilisateurs.
Tout les services sont configurés
dans le répertoire /etc/pam.d/ où chaque fichier
détaille les politiques d'authentification liées à
ce service.
Afin de simplifier l'utilisation et la compréhension du rôle de chaque module, les taches d'authentification sont divisées en 4 groupes indépendants :
Un service est donc divisé en 4
groupes. A chaque groupe, on assigne un ou plusieurs modules.
Bien qu'en théorie, ces groupes
semble bien délimiter chaque tache du processus
d'authentification, le lecteur devra garder à l'esprit que
pour certains modules, la distinction de l'emplacement du module
parmi ces 4 groupes n'est pas toujours aisée, d'autant plus
qu'un module peut intervenir dans plusieurs groupes. Pour
connaître
précisemment les possibilités offertes par un module
pour chacun des groupes, il faut lire les docs du dévellopeur
du module en question. Généralement, le synopsis de
l'utilisation d'un module est fourni dans sa page de man.
Pour résumer:
La première idée qui
vient généralement à l'esprit d'un
administrateur en matière de sécurité est de
définir qui peut accéder physiquement à une
machine. Pour cela, nous allons configurer 2 accès :
Ces applications étant
« PAM
enabled », nous pouvons à loisir définir la
politique de sécurité que nous désirons.
[seb@localhost seb]$ cat
/etc/pam.d/login
#%PAM-1.0 : login service
auth required pam_nologin.so
auth required pam_access.so
#auth required pam_securetty.so
auth required pam_stack.so
service=system-auth
account required pam_stack.so
service=system-auth
password required pam_stack.so
service=system-auth
session required pam_stack.so
service=system-auth
session optional pam_console.so
Comme nous l'avons évoqué
précédemment, chaque service (défini par le nom
du fichier) utilise des modules (3ème colonne), répartis
en groupes (1ère colonne). De même, certains modules
peuvent être utilisés plusieurs fois, dans des groupes
différents, leur comportement étant différents.
Dans les exemples fournis ci-dessus,
nous pouvons voir l'utilisation du module pam_stack dans quasiment
tout les groupes d'authentification. Ce module est un peu particulier
puisqu'il n'a pour objectif que de renvoyer l'authentification au
module passé en argument. Il permet ainsi de définir un
comportement commun à beaucoup de services, idéal pour
les configurations simples ou homogènes.
Si vous modifiez la configuration du
module system-auth, tout les autres modules qui l'utilisent à
l'aide de pam_stack seront modifiés.
Un autre point important de la
configuration des fichiers de services concerne l'empilement des
modules par ordre de lecture. Ainsi, dans l'exemple ci-dessus, dans
le groupe d'authentification, le module pam_nologin sera
évalué
avant le module pam_access, lui même évalué avant
pam_stack. Ceci a une importance lorsque l'on considère que
l'on peut définir quelle sera la conséquence de la
réussite de l'utilisation d'un module.
Nous avons la possibilité de
définir 4 type d'obligation de réussite à tenir
:
Si l'on synthètise toutes les
notions que nous venons d'aborder, la configuration d'une politique
de sécurité que l'on applique à un service passe
par l'utilisation d'un ou plusieurs modules, renseignés dans
un fichier situé dans /etc/pam.d. Dans ce fichier, chaque
ligne informe PAM d'utiliser une fonctionnalité d'un module
selon le groupe, inscrit en début de ligne (auth,session...).
PAM va lire séquentiellement les lignes de chaque groupe et va
confronter l'obligation de réussite définit par
l'administrateur (required, requisite...) au code retour renvoyé
par la librairie et décider de continuer ou pas, selon le
résultat.
Il est important d'indentifier ce qui
donne lieu à une intéraction avec l'utilisateur, par
exemple un module du type pam_unix.so et ce qui ne fait qu'appliquer
un traitement (pam_env) pour fixer le drapeau de contrôle.
Prenons un exemple simple. Imaginons
que nous voulions définir le scénario suivant pour
l'authentification avec gdm :
Nous nous intérressons donc qu'à la partie authentification, chaque ligne que nous renseignerons seront donc précédées par «auth » :
auth required pam_env.so //
Défini
l'utilisation des variables d'environnements utilisateurs
auth required pam_unix.so // Utilise
la procédure standard d'authentification sous Linux
auth required pam_nologin.so // Il
doit faire partie des utilisateur ayant droits de login
auth required pam_deny.so
Lorsque l'utilisateur Boulay va vouloir se logger sur la machine, PAM va vérifier les points suivants : La première entrée de la pile concerne le module pam_env. Celui-ci définit des variables d'environnements renseignée dans le fichier /etc/environnement. A priori, aucune erreur ne peut être générée à ce stade, la lecture de la pile continue. Le module pam_unix va gérer l'authentification style Unix, c'est à dire qu'il va lire /etc/passwd et /etc/shadow pour valider le challenge login/mot de passe. En plus, nous fournissont en argument que le mot de passe nul n'est pas acceptable. Si Boulay réussi à prouver par ce mécanisme qui il est réellement, PAM va continuer la lecture de la pile. Le dernier module utilisé pour l'authentification est pam_deny qui ca refuser systèmatiquement la demande de connexion. A priori, comme pour pam_env, le résultat sera toujours valide. Le résultat total de la pile est valide, donc l'utilisateur peut accéder au service. Login va forker et lui executer un shell, lui donnant accès à la machine.
Après avoir vu comment s'organise la configuration du
comportement de PAM pour un service simple, nous allons ici
détailler
quelques exemples de configuration pour augmenter significativement
la sécurité de certain programme.
Par défaut, les distributions accepte que n'importe quel
utilisateur puisse demander d'accéder à une session
super utilisateur en invoquant la commande su. Pour n'accepter que
les utilisateurs membres du groupe wheel, ajouter dans le service su
(/etc/pam.d/su) la ligne suivante :
auth required pam_wheel.so use_uid
Et comme PAM est modulaire, il va ainsi en être de même
pour chaque service. Vous pouvez donc definir que pour tel service,
seul les utilisateurs membres du groupe wheel pourront
s'authentifier.
Avec l'exemple ci-dessus, on comprend aisément qu'il est
désormais très simple d'appliquer des droits
d'exécution selon un service et un utilisateur donné.
Un des problèmes récurrents sous Unix est
l'utilisation de certains programmes C minimalistes pouvant entrainer
un disfonctionnement de la machine. Ainsi, comme il est souvent le
cas dans les écoles ou universités scientifiques, il
arrive que des étudiant utilise le célebre fork Bomb
(while(1) fork() ), entrainant la machine dans un déluge de
création de processus, ne lui permettant plus de répondre
aux actions légitimes.
Le module pam_limits.so permet heureusement de limiter les
ressources utilisées par des utilisateurs. Ce module, une fois
défini dans le service que l'on souhaite utiliser, doit
être
configurer, en éditant le fichier /etc/security/limits.conf.
Ce module travail dans le groupe session, nous éditons donc
/etc/pam.d/{gdm,kdm,login} selon le gestionnaire utilisé :
session required /lib/security/pam_limits.so // Sans arguments, utilise le fichier /etc/security/limits.conf
Puis, en editant le fichier limits.conf :
#<domain> <type> <item> <value> boulay hard fsize 100000 // Défini une taille maximal d'utilisation de disque pour l'utilisateur boulay @etudiant hard nproc 30 // Defini un nombre maximal de processus en cours pour le groupe d'utilisateur etudiant
Ainsi, pendant chaque session l'utilisateur boulay ne pourra pas
créer de fichier d'une taille superieure à 10Mo et les
etudiant ne pourront pas lancer plus de 30 processus. Attention
toutefois aux limites que vous souhaitez définir sachant
qu'avec des environnements tel que kde ou gnome, de nombreux
processus en tache de fond sont éxécutés...
Par sa puissance PAM peut paraître au premier abord assez complexe à utiliser, d'autant qu'une erreur peut rapidement vous empecher d'accéder à votre machine (seul un reboot en single user pourra vous aider dans ce cas). Néanmoins, le nombre important de modules officiels et non officiels <POINTEUR> permettent de rendre les taches d'authentification sous Linux très versatiles. Vous pouvez facilement intégrer une authentification par LDAP, NDS, ou auprès d'un serveur NT ou encore par biométrie sans avoir modifier le code des services.
|
|
|
|
|
| First | Previous | Post comment | Next | Last |