Les utilisateurs de Linux et macOS connaissent sudo, un programme qui permet d’exécuter une commande en tant qu’un autre utilisateur, généralement root (l’administrateur). Bien que sudo puisse être installé sur OpenBSD, on utilise plutôt doas, qui fait partie du système.

Pourquoi j’ai voulu contribuer à doas

Lorsqu’on configure doas via le fichier /etc/doas.conf, on peut utiliser la directive “persist” qui permet de ne pas avoir à retaper son mot de passe pendant 5 minutes. Ainsi si on a plusieurs commandes à taper, on n’est pas obligé de retaper son mot de passe à chaque fois.

Cependant, ce délai de 5 minutes n’est pas paramétrable, c’est un choix de l’équipe OpenBSD. Et c’est justement un sujet qui revient sur la table de temps en temps (comme ici ou là ), certaines personnes aimeraient pouvoir choisir le temps pendant lequel le mot de passe n’est pas redemandé.
En général ces personnes souhaiteraient un délai plus long, comme 15 minutes. Moi je souhaitais un temps plus court, que le mot de passe soit mémorisé juste le temps de taper 2-3 commandes, puis qu’il soit oublié.

C’est pourquoi j’ai décidé de me plonger dans le code de doas et de proposer un patch à l’équipe OpenBSD.

Mon patch doas

Si vous voulez simplement accéder au patch, il est disponible sur Github .

L’objectif

Pour que vous compreniez la modification que j’ai proposée, voici comment on peut configurer doas actuellement ( doas.conf(5) ) :

# /etc/doas.conf

# Les membres du groupe wheel sont autorisés à utiliser doas, leur mot de passe
# est mémorisé pendant 5 minutes grâce à persist
permit persist :wheel
# Retour à la ligne nécessaire après la règle

Note : dans mon article dédié à doas sur OpenBSD Desktop , j’ai mentionné qu’il était nécessaire d’ajouter un retour à la ligne (\n) après chaque règle pour qu’elle soit prise en compte. Maintenant que j’ai étudié le parser, en plus de le savoir, je comprends pourquoi.

Le patch que j’ai développé ajoute un paramètre optionnel à persist permettant de choisir pendant combien de secondes le mot de passe est mémorisé :

# /etc/doas.conf

permit persist 60 :wheel
# Retour à la ligne nécessaire après la règle

Pendant 60 secondes, le mot de passe n’est pas redemandé à l’utilisateur, délai plus court que les 5 minutes actuelles. Si le délai n’est pas indiqué dans la configuration, alors le délai de 5 minutes par défaut est utilisé, ce qui fait que ce changement est rétro-compatible, il ajoute une fonctionnalité sans casser l’existant.

Comment j’ai fait

Si vous envisagez de contribuer à OpenBSD, la méthode peut vous intéresser.

  1. OpenBSD utilise CVS mais je préfère Git, alors j’ai cloné le repository depuis Github : git clone https://github.com/openbsd/src.
  2. Comme indiqué dans la documentation , j’ai exécuté les commandes suivantes dans le repo Git : git config diff.noprefix true et git config diff.renames false. Ça a été utile au moment de générer le fichier diff.
  3. which doas m’a indiqué que le programme doas se trouvait dans le répertoire /usr/bin, donc j’ai navigué dans le bon dossier du repository : cd usr.bin/doas/.
  4. Une fois dans le bon dossier j’ai étudié les différents fichiers :
    1. doas.1 et doas.conf.5 sont des pages de manuel, pouvant être lues avec man doas et man doas.conf.
    2. Makefile est le fichier que make utilise pour compiler doas. make obj crée un sous-dossier obj/ et ensuite make compile doas.
    3. env.c contient du code C permettant de gérer l’environnement.
    4. doas.h et doas.c contiennent du code C, la fonction main() se trouve dans doas.c et c’est un bon point de départ pour comprendre comment le programme fonctionne.
    5. parser.y est un fichier un peu spécial, utilisé par yacc . Il définit la grammaire utilisée par le fichier de configuration doas.conf, pour ajouter une option de configuration c’est ce fichier qu’il faut modifier. Pour cela il faut se familiariser avec yacc, car ce n’est pas juste du code C.
  5. Après avoir étudié la documentation, le code, et effectué mes modifications, j’ai généré un diff depuis le dossier usr.bin/doas avec la commande git diff --relative . > doas-persist-timeout.patch.
  6. Enfin, après avoir lu les instructions , j’ai envoyé un e-mail à la mailing list avec mon patch en pièce jointe.

La réponse d’OpenBSD

Quelques heures après avoir envoyé mon message, j’ai eu une réponse de Theo, le fondateur d’OpenBSD, il n’aimait pas l’idée de rendre le délai configurable, et il a donné de bons arguments. Le délai de 5 minutes a été choisi parce qu’il n’est ni trop long pour poser problème ni trop court pour être embêtant, ça permet de garder doas simple, sans compliquer la gestion de la configuration.

Camouflet ? Pas du tout. Bien entendu j’aurais apprécié que le patch soit accepté, mais l’explication du refus a du sens, est cohérente, et surtout j’ai beaucoup appris en creusant le code. Et puis j’ai toujours mon patch, rien ne m’empêche de l’utiliser même s’il a été refusé.

Comprendre la philosophie d’OpenBSD

OpenBSD est un système qui se veut simple, s’il y a moins de fonctionnalités on réduit la surface d’attaque et le nombre de bugs.

La sécurité est au centre de tout, chaque fonctionnalité ajoutée est réfléchie du point de vue de la sécurité, du risque et de la complexité qu’elle apporte. Un exemple parlant est le Bluetooth, qui n’est volontairement pas supporté par OpenBSD.

Dans la lignée de la sécurité il y a la volonté de faire du code correct, et ça passe par des revues de code. Chaque patch est revu par d’autres développeurs afin d’y déceler des problèmes.

Conseils pour contribuer

Voici quelques conseils si vous souhaitez contribuer à OpenBSD :

  1. Lire la documentation. Ça vaut aussi pour les utilisateurs. OpenBSD a une très bonne documentation, man 1 doas pour la commande doas, man 5 doas.conf pour comprendre le fichier doas.conf, mais également man 2 pledge pour en savoir plus sur l’appel système pledge ou encore man 3 getopt pour accéder à la documentation de la fonction C getopt.
  2. Communiquer sur les mailing lists . Il y en a plusieurs, certaines pour des discussions variées, d’autres pour soumettre des patchs.
  3. Accepter le refus. Que ce soit sur OpenBSD ou un autre projet open source, les développeurs ne sont pas obligés d’accepter vos propositions. Ça ne veut pas dire qu’elles sont mauvaises pour autant.

Conclusion

Contribuer à OpenBSD est difficile, mais enrichissant. Même si le patch est refusé, l’apprentissage est précieux et aller jusqu’à la soumission du patch est une victoire en soi.

Besoin d’un expert OpenBSD qui connaît le système de l’intérieur ? Parlons de votre projet .