Comprendre les permissions

Cette page vise à donner un aperçu de qui a le droit de faire quoi sur le serveur LDAP lors de son premier lancement. Les ACL sont configurables en modifiant la configuration. On pourra en ajouter, mais on gardera cette configuration.

Pour comprendre ce qui suit, on pourra lire la documentation sur les ACL ainsi que la documentation sur la configuration générale.

Lorsque l’on lance le serveur LDAP pour la première fois, on trouve trois bases de données :

• frontend, une base de données spéciale qui contient les caractéristiques qui seront appliquées à toutes les autres base de données
• config, une base de données spéciale qui contient entre autres les permissions liées à la configuration
• mdb, qui contient la configuration des entrées que l’on utilise. En effet, son attribut olcDbDirectory vaut /var/lib/ldap, qui est le chemin de notre base de données, et son attribut olcSuffix est à dc=picasoft,dc=net, ce qui indique que toute requête concernant un DN qui termine par dc=picasoft,dc=net sera traitée par cette base de données.

Les entrées correspondante se voient dans la configuration :

Les ACL définies ici sont appliquées par défaut à toutes les autres bases de données, et susceptibles d’être écrasées.

On trouve les ACL suivantes :

to * 
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage 
  by * break
  
to dn.exact="" 
  by * read
  
to dn.base="cn=Subschema" 
  by * read

Qui indiquent respectivement que :

• L’utilisateur root (ici dans le conteneur LDAP) a le droit de modifier l’ensemble des entrées du serveur
• N’importe qui a le droit de lire le Base DN, qui contient des informations sur les extensions utilisables avec le serveur LDAP, par exemple
• N’importe qui a le droit de lire l’entrée cn=Subschema, qui contient des informations sur les schémas chargés sur le serveur LDAP.

À titre d’exemple, voici ce qu’a le droit de voir un utilisateur quelconque voire non-authentifié.

Même chose que pour frontend, et on retrouve en plus les attributs suivants :

• olcRootDN : cn=admin,cn=config
• olcRootPW : XXX

Ces attributs spécifient que le DN cn=admin,cn=config n’est sujet à aucun contrôle d’accès pour la base de données config. En d’autres termes, en se connectant avec cn=admin,cn=config, on peut tout faire avec cn=config (i.e. modifier la configuration).

Cette configuration est réalisée par l’exécution de ce LDIF présent dans l’image sur laquelle nous nous basons.

La configuration initiale est réalisée par l’exécution de ce LDIF de l’image Docker sur laquelle nous nous basons.

On retrouve deux ACL intéressantes :

to attrs=userPassword,shadowLastChange 
  by self write 
  by dn="cn=admin,dc=picasoft,dc=net" write 
  by anonymous auth 
  by * none

Ici, on indique que les attributs userPassword et shadowLastChange (utilisés notamment pour s’authentifier sur les machines et les services, car il faut bien pouvoir vérifier le mot de passe) :

• Peuvent être lus modifiés par soi-même (je peux changer mon mot de passe) et par l’administrateur (cn=admin)
• Peuvent être utilisés pour les mécanismes d’authentification
• Ne peuvent être lus par personne d’autre

En gros, je ne peux pas lire le mot de passe d’un autre utilisateur : je peux seulement essayer de m’authentifier, sans jamais avoir les droits de lecture sur le mot de passe.

Les ACL sont traitées dans l’ordre et le traitement s’arrête au premier match. Ainsi, tout ce qui concerne userPassword est traité ci-dessus, et ce qui suit s’applique à tout ce qui ne concerne pas userPassword :

to * 
  by self read 
  by dn="cn=admin,dc=picasoft,dc=net" write 
  by dn="cn=nss,dc=picasoft,dc=net" read 
  by * none

Ici, on indique que :

• Je peux lire tous les attributs de mon entrée (par exemple, si je me connecte en tant que qduchemi, mon entrée est un posixAccount, et je peux lire mes attributs sshPublicKey, sn, etc).
• L’administrateur (cn=admin) peut lire et écrire toutes les entrées
• L’utilisateur en lecture seule (cn=nss) peut uniquement lire toutes les entrées
• Les autres ne peuvent rien faire

On peut vérifier empiriquement ces ACL en faisant des requêtes sur le LDAP, avec la syntaxe suivante :

snippet.bash

ldapsearch -x -b "<base de la recherche>" -D "<DN pour l'authentification>" -H ldaps://ldap.picasoft.net:636 -W

Par exemple, j’essaye de lire les attributs de mon utilisateur :

snippet.bash

ldapsearch -x -b "cn=qduchemi,ou=People,dc=picasoft,dc=net" -D "cn=qduchemi,ou=People,dc=picasoft,dc=net" -H ldaps://ldap.picasoft.net:636 -W
 
dn: cn=qduchemi,ou=People,dc=picasoft,dc=net
objectClass: authorizedServiceObject
[...]
objectClass: top
cn: qduchemi
gidNumber: 501
homeDirectory: /home/users/qduchemi
[...]
userPassword:: <REDACTED>

On constate que j’ai bien accès à toutes les données de mon utilisateur, y compris mon mot de passe.

J’essaye de lire les données d’un autre utilisateur :

snippet.bash

ldapsearch -x -b "cn=kyane,ou=People,dc=picasoft,dc=net" -D "cn=qduchemi,ou=People,dc=picasoft,dc=net" -H ldaps://ldap.picasoft.net:636 -W
 
# search result
search: 2
result: 32 No such object

Je n’ai pas le droit : ok.

J’essaye de lire les données d’un compte quelconque avec l’utilisateur nss :

ldapsearch -x -b "cn=qduchemi,ou=People,dc=picasoft,dc=net" -D "cn=nss,dc=picasoft,dc=net" -H ldaps://ldap.picasoft.net:636 -W

dn: cn=qduchemi,ou=People,dc=picasoft,dc=net
objectClass: authorizedServiceObject
[...]
cn: qduchemi
gidNumber: 501
homeDirectory: /home/users/qduchemi
[...]

On constate que l’utilisateur nss peut lire les entrées, mais qu’elles ne contiennent pas l’attribut userPassword, grâce à la première ACL.