Je voudrais vous rappeler que pledge(2) a été implémenté dans OpenBSD en 2015, et unveil(2) en 2018.
Grosso modo, ces fonctions permettent d'exécuter des programmes de manière sécurisée même quand les permissions ne le sont pas, ce qui rend Wayland un peu superflu, et peut paraître inutile pour de l'auto-hébergement de serveurs jusqu'au moment où on se rappelle que les environnements d'entreprise sont complexes, que des administrataires systèmes peuvent gérer 2000 serveurs ou plus, et que ces appels systèmes permettent de nous protéger d'une fuite de données, notamment dans des contextes capitalistes de réduction des coûts de maintenance (et donc de risques d'erreurs humaines accrus).
1/3
⭐1
Le principe de moindre privilège veut que l'on exécute chaque programme avec un utilisateur Unix dédié, dit « système », dénoté par un tiret bas avant le nom (par exemple _www). Par exemple, dans Absolute OpenBSD Michael W. Lucas donne l'exemple du serveur utilisé pour l'infrastructure d'OpenBSD, dont le serveur web n'a notamment pas de permissions d'écriture ; outre différents dispositifs de sécurité (pas de possibilité de se connecter ou de lancer une invite de commande), même si on piratait leur serveur web, on ne pourrait pas en faire grand-chose.
Ça correspond à un chmod 400, qui correspond en retour à l'usage de l'appel système pledge(2) dans lequel le programme dit au système d'exploitation ne pas avoir besoin de modifier des données, donc s'il était piraté on ne pourrait pas en faire grand-chose.
Pour le dire de manière très grossière et très schématique, unveil(2) et pledge(2) permettent d'exécuter des programmes de manière sécurisée, même si ils sont lancés en tant qu'administrateur 😁
Et comme ces appels systèmes font partie du code source du programme, même dans un contexte d'entreprise ils fournissent un filet de sécurité permettant, encore une fois, de limiter les risques de fuites de données, de rançongiciel, etc.
Et on parle parfois d'infrastructures critiques comme celles d'hôpitaux !
2/3
⭐1
Donc pourquoi est-ce que ces appels systèmes ne sont pas encore implémentés dans Linux ? Ça fait 8 ans depuis l'implémentation de pledge(2), et 5 ans depuis celle d'unveil(2) dans OpenBSD…
Je n'en connais pas les détails, mais je tiens à attirer l'attention sur l'aspect bénévole des contributions aux logiciels libres, la plupart des contributaires à temps plein au noyau Linux étant payé·es par des entreprises comme Intel, Red Hat, etc. Les committers au projet OpenBSD sont elleux-mêmes des bénévoles, des hobbyistes… Donc j'imagine que le manque de financement des logiciels libres jouerait effectivement un rôle dans le manque de traduction de la documentation, mais aussi dans ce manque d'implémentation de nombreuses innovations OpenBSD, AMHA.
Je pense aussi aux intérêts corporate de Red Hat, qui ont exclu des dépôts Fedora doas(1) (implémenté en 2015) jusqu'en 2020 et signify(1) (implémenté en 2013) jusqu'en 2021, prétextant dans ce dernier cas des manques de compatibilité et de sécurité, qui étonnent un peu dans les communautés concernées.
Je comprends que Fedora soit financé par Red Hat pour tester leurs technologies émergentes, ce qui justifie l'exclusion de programmes non compatibles de leurs dépôts, comme mpd(8) qui entrait en conflit avec PulseAudio. Mais cette entreprise reste patronale, et caractérisée par un besoin de nous empêcher de rêver d'une informatique réellement libérée, dans le même sens qu'une agriculture communale et locale : ça leur fermerait des marchés.
Le développement des logiciels libres et plus encore des logiciels propriétaires est caractérisé par une relative ignorance des bonnes pratiques, par exemple on me recommande des logiciels en ligne de commande comme kiln(1) qui mettent toute leur documentation dans la page de manuel dédiée à l'interface en ligne de commande, alors que la section 7 correspondrait à une description générale et à la compatibilité avec les templates Go, la section 5 au fichier de configuration config.toml, etc., ce qui rend son manuel très peu lisible et très peu accessible.
Donc on a une situation où se mêlent un manque de financement et donc des contributions non-contractuelles, basées sur le volontariat, caractérisées par une ignorance généralisée des bonnes pratiques, notamment en raison de la pauvreté de nos infrastructures communautaires et d'information (dont les récènes), et des contributions contractuelles, marquées par des intérêts corporate, qui AMHA n'intègrent pas le fait de nous montrer qu'une cinquantaine de hobbyistes scrupuleux·ses quant aux bonnes pratiques peuvent être à l'origine des trois quarts des innovations côté administrataire système en sécurité informatique (sudo(8), doas(1), OpenSSL, LibreSSL, signify(1), unveil(2), pledge(2), etc.).
3/3
