Version 2 du RootAsRole : se passer des commandes sudo et su sous GNU/Linux

Posté par . Édité par ZeroHeure, Davy Defaud, Xavier Teyssier, Ysabeau et gUI. Modéré par Pierre Jarillon. Licence CC by-sa.
39
25
oct.
2019
Administration système

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).

Copie d’écran de Root As Role

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

  • # RAR vs group/ACL ?

    Posté par (page perso) . Évalué à 5 (+3/-0).

    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 . Évalué à 2 (+3/-3).

      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 . Évalué à 3 (+3/-1).

      Ç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 (page perso) . Évalué à 3 (+1/-0). Dernière modification le 25/10/19 à 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 . Évalué à 6 (+4/-0).

          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 (page perso) . Évalué à 4 (+2/-0).

      Ça m'a l'air surtout plus proche de capsicum voire de cloudabi.

  • # Intéressant

    Posté par . Évalué à -1 (+1/-3).

    C'est drôlement intéressant tout ça ! Je n'ai jamais trop aimé la commande sudo.

  • # Mouais mais...

    Posté par . Évalué à -2 (+2/-4).

    A trop vouloir en faire, on s'embrouille..

  • # orthographe

    Posté par (page perso) . Évalué à 2 (+1/-0).

    ne founissait par à l’administrateur ⇒ ne fournissait pas à l’administrateur

    • [^] # Re: orthographe

      Posté par . Évalué à 2 (+0/-0).

      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 (page perso) . Évalué à 9 (+7/-0). Dernière modification le 25/10/19 à 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 . Évalué à 2 (+1/-0).

    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 . Évalué à 1 (+0/-0).

      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.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.