Le module RAR (Root As Role) implémente une approche basée sur les rôles pour distribuer les privilèges aux utilisateurs. Il fournit une solution qui permet aux utilisateurs de contrôler la liste des privilèges qu’ils accordent aux programmes. Grâce à ce module, les administrateurs peuvent regrouper les privilèges Linux dans des rôles et les donner à leurs utilisateurs. Pour des raisons de sécurité, les utilisateurs n’obtiennent pas les rôles attribués par défaut, ils doivent les activer à l’aide de la commande sr (changer de rôle).
Cependant, la première version du RAR ne fournissait pas à l’administrateur la possibilité de connaître l’ensemble des privilèges qui sont demandés par un programme. Cette deuxième version ajoute l’outil capable qui permet à l’administrateur de disposer de cette information. Nous pensons que cet outil va largement contribuer à l’adoption de RootAsRole.
Nous vous avons proposé l’année dernière le module RootAsRole qui permet de se passer des commandes su et sudo sous GNU/Linux (voir le journal « Linux capabilities : se passer des commandes su et sudo »). En effet, le problème majeur des commandes sudo et su, c’est que cette approche traditionnelle ne respecte pas le principe plus récent de moindre privilège : ces commandes ne permettent pas de contrôler les listes de privilèges (Linux capabilities) à donner aux programmes et/ou utilisateurs.
Le code (GPL v3) et des exemples plus complets sont disponibles sur la page GitHub du projet.
N’hésitez pas à nous envoyer vos retours via le formulaire à disposition (formulaire hébergé sur Google Forms).
Aller plus loin
- Page GitHub de Root As Role (271 clics)
- Formulaire de retour d’information (sur Google Forms) (40 clics)
# RAR vs group/ACL ?
Posté par Nibel . Évalué à 5.
Quel est l'avantage de RAR par rapport aux groupes avec les ACL ?
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: RAR vs group/ACL ?
Posté par totof2000 . Évalué à 2.
A mon avis il n'y a pas d'avantages de l'un sur l'autre : ce sont deux approches différentes.
bientôt, a force d'accumuler ces couches, on va avoir des systèmes inutilisables.
[^] # Re: RAR vs group/ACL ?
Posté par -mat . Évalué à 3.
Ça n'a rien à voir… Les ACL définissent les droits d'accès aux fichiers (en lecture écriture et exécution) là où RAR permet de définir les capacités données à un exécutable (ptrace, kill,…)
[^] # Re: RAR vs group/ACL ?
Posté par Nibel . Évalué à 3. Dernière modification le 25 octobre 2019 à 18:01.
Et les groupes ne définissent pas les droits d'accès à des binaires ?
Chez moi, tout utilisateur qui n'est pas dans le groupe "jeux" ne pourra lancer Steam ou Lutris.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: RAR vs group/ACL ?
Posté par moi1392 . Évalué à 6.
une des différence que je vois, est que du coup, tous les utilisateurs du groupe "jeux" peuvent lancer Steam et faire toutes les opérations qu'il propose.
Avec un controle plus fin, certains utilisateur ne pourraient que lancer les jeux, et d'autres seulement les mettre à jour, et ce, avec le même binaire Steam.
N'ayant qu'un expérience très limité de l'administration d'un système Linux, je ne sais pas dire si c'est une bonne chose ou pas, si cela apporte de la sécurité, flexibilité, simplicité ou autre.
Mais d'un point de vu conceptuel, je trouve cela au moins intéressant.
[^] # Re: RAR vs group/ACL ?
Posté par David Marec (site web personnel) . Évalué à 4.
Ça m'a l'air surtout plus proche de capsicum voire de cloudabi.
# Intéressant
Posté par Sharpshooter . Évalué à -1.
C'est drôlement intéressant tout ça ! Je n'ai jamais trop aimé la commande sudo.
# Mouais mais...
Posté par Naone . Évalué à -2.
A trop vouloir en faire, on s'embrouille..
# orthographe
Posté par Joël Thieffry (site web personnel) . Évalué à 2.
ne founissait par à l’administrateur ⇒ ne fournissait pas à l’administrateur
[^] # Re: orthographe
Posté par gUI (Mastodon) . Évalué à 2.
Corrigé, merci.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# En complément
Posté par Sytoka Modon (site web personnel) . Évalué à 9. Dernière modification le 25 octobre 2019 à 18:26.
Une petite lecture fortement instructive sur les capabilitys : https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-164/Les-capabilities-sous-Linux
Une petite question que je met pose : quid des capabilités fourre tout ? Il me semble que dans le noyau il y a en quelques unes. Ne faudrait-il pas faire le ménage dans le noyau pour que certaines capabilités ne soit pas sur-utilisés par rapport aux autres. De mémoire, il y avait CAP_NET_ADMIN ou CAP_SYS_ADMIN par exemple.
# RAR vs MAC ?
Posté par cluxter . Évalué à 2.
Quelles sont les différences d'un point de vue fonctionnel entre Root As Role et les systèmes de Mandatory Access Control (comme SELinux ou AppArmor) ? Les avantages de l'un par rapport à l'autre, ou si ça n'a rien à voir, en quoi c'est fondamentalement différent ?
Merci
[^] # Re: RAR vs MAC ?
Posté par samerw . Évalué à 1.
SElinux et Apparmor sont complètement inefficaces pour faire face au risque d'escalation de privilège, car dans la majorité des cas ces modules limitent une partie d'application (e.g. target policy pour Selinux) et laisse les autres applications non confinées. N'importe quelle application non confinée est capable de désactiver Selinux et Apparmor lorsqu'on l'exécute avec la commande sudo. Si vous décidez d'appliquer la politique SELinux et Apprmor sur la totalité de des applications de votre système, votre système devient complémentent inutilisable. Notre objectif est de contrôler la distribution des privileges sur la totalité des applications présentes dans Linux. Cela est possible pour nous, car notre module n'implémente pas les règles MAC.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.