Re: Petite question ...

Des différents points abordés par plusieurs commentaires, il m'apparait un élément, peut être je me trompe mais je le soumet à la sagacité des autres lecteurs et à la votre :

Il semble qu'il y a une incompréhension dû à l'objectif expliqué :
D'une part cela cause d'un objectif vague, une "réduction de la surface des droits accordés" ;
D'autre part cela cause d'implémentation, et d'autres systèmes ;
Et enfin on revient sur votre postulat de base et votre descriptif d'introduction.

La situation est déjà assez complexe : droits unix de base souvent mal utilisés (il est pourtant simple, par exemple, de ne pas donner un droit de lecture tout en accordant un droit d'écriture, mais ce n'est pas très pratique :p en l'état), attributs étendus (utilisés aussi bien, par exemple, pour le system acl que pour la security selinux), auxquels s'ajoutent parfois les capabilities (pour éviter, par exemple, un bit_suid sur la commande ping). D'ailleurs j'ai une question simple : lors de la création d'un nouveau groupe, comment définit on les capablities qu'on accorde à ce groupe ? :p

Donc si j'ai bien compris votre postulat de base peut être résumé en : «on ne touche presque rien au système existant» (sinon, et si votre objectif avait été la "réduction de la surface des droits accordés", vous auriez peut être procéder autrement en utilisant massivement des combinaisons fines et nombreuses entre des utilisateurs et des groupes pour les logiciels et des acl en plus pour les arborescences, cette solution suffit mais elle nécessite de modifier les post-install des paquets, au final d'entretenir une distrib, presque, mais reste moins couteuse que de modifier les logiciels eux-mêmes tel que le pratique OpenBSD pour aller plus loin). Vous partez du constat de l'existant en matière de distribution, presque tout est root:root pour les logiciels, seuls trois ou quatres binaires ont des cap déclarées, et les programmes plus ou moins bien fait demandent eux mêmes et/ou font de l'abandon de privilèges.
Ce postulat de base est important, primordial, et je ne doute pas qu'il puisse être exprimé autrement, mieux, plus finement, pour dire quelque chose comme "on travaille sur la distrib telle qu'on l'a, et on ne la refait pas".

Ensuite votre introduction peut être résumée en "remplacer sudo par quelque chose qui prenne en charge les possibilités offertes par le système des capabilities", finalement. Et cet angle d'attaque est, je trouve, imho tout ça, particulièrement intéressant, et pertinent.

Vue ainsi cela ressemble à la continuation logique de l'élimination des bit_suid en utilisant les capabilities. Vous le proposez de manière dynamique, sans toucher à la distrib, et facilement configurable.

Critiques générales :
Si le modèle du super-utilisateur est si utilisé c'est parcequ'il correspond au besoin de la plupart des usages, qui restent finalement assez simples. Que cela soit sur un serveur web, un serveur de vm ou un ordinateur personnel, ce modèle simple et loin des possibilités du système suffit pourtant. La crainte est donc que, même avec une certaine simplicité de configuration, cela ne soit pas ou peu utilisé sans proposer des politiques par défaut déjà prêtes (ce que fait, pour un autre objectif et un autre type d'implémentation, firejail, ou encore différent : suricata). Quant à demander d'utiliser une commande préalable à tout autre, cela restreint bien probablement l'usage de sr à quelques environnements multi-utlisateurs / multi-administrateurs où le cloisonnement de responsabilités est primordial. Mais également très intéressant pour un ordinateur personnel, dès lors que des règles sont livrées établies et maintenus (comme le disait Linus : c'est stupide d'être root pour configurer une horloge, une carte graphique ou une imprimante sur son PC personnel) : pour ce cas aussi il y a une voie ..

Ces deux critiques posés, il semble nécessaire de répéter que je trouve votre approche de remplacer sudo par un utilitaire de gestion des capablities particulièrement pertinent. Alors une question : qu'est ce qui a fait que vous ayez choisi de développer un module à part plutôt que de contribuer à sudo ? (il n'y a ni malice dans la question, ni bonne ou mauvaise réponse, juste une demande d'info)

Enfin, deux remarques sur le configure et le déclaratif pam : dans le configure il y a un mélange entre dépendances nécessaires à la compilation et post-installation, envisagez vous de séparer les deux ? Par exemple avec un simple readme pour dire ce dont il a besoin, et ensuite une bascule des cp et chmod dans le Makefile ? Ensuite concernant la règle pam : elle n'est pas distro agnotisque, mais elle est très simple donc envisagez vous de la rendre plus générique ? Ces points font qu'en l'état actuel il n'est pas possible d'utiliser immédiatement votre module sur autre chose qu'une Debian. Enfin, vu qu'il a un besoin strict de pam, il ne sera pas possible de l'utiliser sur une Slackware par exemple. Du coup, il serait peut être bien d'ajouter une note à ce sujet car sr n'est pas "pour linux", mais pour une distrib basée sur Debian (pour le moment du moins) et qui a pam.