Cette approche est passionnante, bien que non simple ni cadrée en terme d'effort à consentir (h, j, s, m ?).
(en parlant d'un programme en C utilisant des appels systèmes et setuid)
L'effort à consentir dépend fortement de la compétence du codeur, de son accès à une documentation à jour, etc....
Pour quelqu'un d'habitué à coder sous Linux (par exemple l'auteur des logiciels libres sudo ou super) l'effort devrait se compter en jour ou une semaine, mais pas des mois.
Car elle invite à considére les internes du système utilisé quotidiennement.
Mais avant ça, la question me semble être :Est-qu'un fichier truc.desktop qui contient 'Terminal=true' et surtout 'Exec=sudo /usr/local/bin/truc'qui déclenche l'appel d'une fenêtre d'un agent de sécurité (lequel attend le pwd du sudoer présumé),pose ou non un problème de sécurité ? (Vs un 'sudo truc' en CLI, dont je crois qu'il fait la même chose)
Peut-être, dans le cas où le $PATH a été modifié par maladresse (ou malveillance).
Et on peut aussi soupçonner (ou auditer) le code du noyau Linux
ou de la librairie GNU libc ou musl-libc.
Et on apprendrait des choses à étudier le code (en logiciel
libre) des commandes sudo en https://github.com/sudo-project/sudo
Enfin, le contexte applicatif est essentiel: si on code un petit
service web nécessaire à une boutique de fringues, c'est très
différent de coder (ou de valider) par exemple un respirateur
Covid en open source. https://github.com/Recovid
(que j'ai eu l'honneur d'expertiser avec des collègues du CEA LIST, mon employeur).
Librement
-- Basile Starynkevitch <basile@starynkevitch.net> (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ & refpersys.org