Je vous remercie pour l'ensemble de vos commentaires très intéressant. Je vais essayer de répondre:
Notre objectif est de donner la possibilité aux utilisateurs de controller les privilèges qu'ils passent aux programmes. Avec notre module en l'état actuel, l'utilisateur doit au préalable connaitre les privilèges demandés par un programme, ensuite définir les roles dans le fichier de configuration et à la fin utiliser sr avec le role défini pour lancer le programme. C'est un peu laborieux, j'accepte. Mais Nous souhaitons faire évoluer notre module pour rendre la tache facile aux utilisateurs. En particulier, nous souhaitons étendre le kernel de Linux pour enrichir la fonction cap_capable dans le kernel. Si vous regardez le code source de cette fonction, vous réalisez qu'il ne fait pas grande chose à part vérifier l'existence des privilèges dans le set effective des processus. Nous souhaitons développer cette fonction pour nous indiquer les privilèges demandés par les processus et les ressources utilisées avec ces privilèges. Quand on obtient cette information nous pourrons alors automatiser le choix des roles pour l'utilisateur. Par exemple, lorsqu'un programme demande l'accès à une ressource privilégiée, cap_capable va nous rendre des informations que nous croisons avec les infos dans le fichier capabilityRole.xml pour indiquer au utilisateur le role qu'il doit utiliser ou définir dans le fichier xml. Nous devons également étudier tous les programmes de bases qui viennent avec Linux et définir des roles basiques qui permettent aux utilisateurs standard d'utiliser ces roles.
Concernant l'amerlioration du sudo, je ne vous pas cache c'était notre volonté au départ. Simplement nous avons changé notre avis car le code sudo est assez compliqué, il nous fallait du temps pour l'étudier correctement et on n'était pas sûr des impacts de modification du code. Du plus, nous avions la volonté de faire un module composé de plusieurs outils. Pour l'instant notre module est composé d'un seul outil, mais nous souhaitons ajouter d'autres outils comme roleadd, rolemodify, sr_admin, etc..chacun de ces outils va avoir un role administratif associé défini par défaut dans le fichier xml.
Concernant l'installation et la configuration, nous allons travailler pour les rendre plus génériques. Un seul problème, il me faut des contributeurs pour améliorer ce travail car je n'ai pas personnellement assez du temps pour finir toutes ces améliorations.
[^] # Re: Petite question ...
Posté par samerw . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 10. Dernière modification le 07 septembre 2018 à 14:26.
Bonjour,
Je vous remercie pour l'ensemble de vos commentaires très intéressant. Je vais essayer de répondre:
Notre objectif est de donner la possibilité aux utilisateurs de controller les privilèges qu'ils passent aux programmes. Avec notre module en l'état actuel, l'utilisateur doit au préalable connaitre les privilèges demandés par un programme, ensuite définir les roles dans le fichier de configuration et à la fin utiliser sr avec le role défini pour lancer le programme. C'est un peu laborieux, j'accepte. Mais Nous souhaitons faire évoluer notre module pour rendre la tache facile aux utilisateurs. En particulier, nous souhaitons étendre le kernel de Linux pour enrichir la fonction cap_capable dans le kernel. Si vous regardez le code source de cette fonction, vous réalisez qu'il ne fait pas grande chose à part vérifier l'existence des privilèges dans le set effective des processus. Nous souhaitons développer cette fonction pour nous indiquer les privilèges demandés par les processus et les ressources utilisées avec ces privilèges. Quand on obtient cette information nous pourrons alors automatiser le choix des roles pour l'utilisateur. Par exemple, lorsqu'un programme demande l'accès à une ressource privilégiée, cap_capable va nous rendre des informations que nous croisons avec les infos dans le fichier capabilityRole.xml pour indiquer au utilisateur le role qu'il doit utiliser ou définir dans le fichier xml. Nous devons également étudier tous les programmes de bases qui viennent avec Linux et définir des roles basiques qui permettent aux utilisateurs standard d'utiliser ces roles.
Concernant l'amerlioration du sudo, je ne vous pas cache c'était notre volonté au départ. Simplement nous avons changé notre avis car le code sudo est assez compliqué, il nous fallait du temps pour l'étudier correctement et on n'était pas sûr des impacts de modification du code. Du plus, nous avions la volonté de faire un module composé de plusieurs outils. Pour l'instant notre module est composé d'un seul outil, mais nous souhaitons ajouter d'autres outils comme roleadd, rolemodify, sr_admin, etc..chacun de ces outils va avoir un role administratif associé défini par défaut dans le fichier xml.
Concernant l'installation et la configuration, nous allons travailler pour les rendre plus génériques. Un seul problème, il me faut des contributeurs pour améliorer ce travail car je n'ai pas personnellement assez du temps pour finir toutes ces améliorations.