Linux Attitude

Niveau :      
Résumé : pam_exec

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

Niveau :      
Résumé : setcap ; getcap ; getpcaps

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.

Niveau :      
Résumé :

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

Niveau :      
Résumé : pam_unix sha512

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.

Niveau :      
Résumé :

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

Niveau :      
Résumé : libmap-ldap ; passwd ; chsh ; chfn ; adduser

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.

Niveau :      
Résumé : libpam-ldap

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"