Linux capabilities : se passer des commandes su et sudo

Posté par . Édité par Benoît Sibaud, ZeroHeure, Pierre Jarillon, Trollnad Dump et Davy Defaud. Modéré par Benoît Sibaud. Licence CC by-sa.
58
6
sept.
2018
Administration système

Nous proposons un module qui permet de se passer des commandes su et sudo. L’avantage de notre module est qu’il permet de contrôler la liste des privilèges donnés aux programmes.

Traditionnellement, l’administration des systèmes GNU/Linux repose sur l’existence d’un seul utilisateur puissant (appelé super‐utilisateur) qui détient à lui seul la liste complète des privilèges du système. Cette vision a été critiquée car tous les programmes exécutés dans le contexte du super‐utilisateur obtiennent beaucoup plus de privilèges qu’ils n’en ont besoin. Par exemple, tcpdump demande uniquement le privilège cap_net_raw pour s’exécuter. Cependant, en l’exécutant dans le contexte de super‐utilisateur, tcpdump obtient la liste complète des privilèges du système. Ainsi, l’approche traditionnelle de l’administration GNU/Linux rompt le principe du moindre privilège, qui garantit qu’un processus doit juste avoir les privilèges nécessaires pour effectuer son travail. Un attaquant pourrait exploiter les vulnérabilités de tcpdump afin de compromettre la sécurité du système.

Il existe cependant une autre voie, non officielle, mais intégrée au noyau Linux depuis 1998…

Un brouillon POSIX (POSIX draft 1003.1e) avait été proposé afin de définir un modèle qui permet de donner aux processus uniquement les privilèges de super‐utilisateur dont ils ont besoin. La proposition définit pour chaque processus trois ensembles de bitmaps appelés Inheritable (i), Permitted (p) et Effective (e). Ce modèle n’a pas été adopté officiellement, mais il a été intégré au noyau Linux depuis 1998.

Cependant, pour différentes raisons, ce modèle n’a pas été largement utilisé :

  1. Premièrement, le modèle de capacité de Linux présente différents problèmes techniques en raison de l’utilisation d’attributs étendus pour stocker les privilèges dans les exécutables (problème 1).
  2. Deuxièmement, les administrateurs de systèmes GNU/Linux ne disposent pas d’un outil leur permettant de distribuer les privilèges aux utilisateurs de manière fine (problème 2). La distribution fine de privilèges devrait donner aux administrateurs la possibilité de décider quels privilèges accorder aux utilisateurs, quels programmes (par exemple, tcpdump) peuvent utiliser ces privilèges et sur quelles ressources ces privilèges peuvent être appliqués (par exemple, interface réseau eth0).
  3. Troisièmement, GNU/Linux ne fournit pas d’outil permettant aux utilisateurs de connaître le privilège demandé par une application (problème 3).
  4. Quatrièmement, GNU/Linux est livré avec des commandes de base qui ne sont pas compatibles avec des privilèges, tels que la commande passwd (problème 4).

En conséquence, la majorité des utilisateurs de GNU/Linux utilisent toujours les commandes su et sudo pour exécuter des applications privilégiées, car le modèle super‐utilisateur présente l’avantage d’être facile à utiliser.

Récemment, un nouvel ensemble de privilèges appelé Ambient a été intégré au noyau Linux afin de résoudre les problèmes techniques liés au stockage des privilèges dans les attributs étendus des exécutables. Cependant, le système GNU/Linux ne fournit pas de solutions pour gérer les problèmes deux et trois.

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 au problème deux : notre module est livré avec un outil appelé sr (switch role) qui permet aux utilisateurs de contrôler la liste des privilèges qu’ils accordent aux programmes.

Ainsi, avec notre module, les utilisateurs de GNU/Linux peuvent cesser d’utiliser les commandes sudo et su, qui ne permettent pas de contrôler la liste des privilèges à donner aux programmes.

Il existe déjà des outils permettant de contrôler la liste des privilèges à attribuer aux programmes tels que setcap et le module pam_cap. Cependant, ces outils nécessitent l’utilisation d’attributs étendus pour stocker les privilèges. Or stocker des privilèges dans des attributs étendus pose de nombreux problèmes. Notre module permet d’attribuer les privilèges Linux sans avoir besoin de les stocker dans les attributs étendus des fichiers exécutables.

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

Notre module est compatible avec pam_cap.so, les administrateurs peuvent donc continuer à utiliser pam_cap.so avec lui.

Concrètement, notre module permet de respecter le principe du moindre privilège en donnant aux utilisateurs la possibilité de contrôler la liste des privilèges qu’ils accordent à leurs programmes.

Le code (GPL v3) et des exemples plus complets sont disponibles sur la page GitHub du projet.

  • # Demande de compléments

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

    Merci pour ces explications claires mais qui appelleraient quelques compléments et un peu de mise en page, et surtout merci de ce travail.

    Il y a des exemples et des explications vraiment apétissantes (que je n'ai pas encore eu le temps de lire) qui permettent de mieux comprendre l'usage de l'outil sur la page github que vous mettez en lien.

    Pouvez-vous expliciter qui est le «nous» de la première phrase (personnes, organisation…) et si vous faites ça sur votre temps libre, ou si vous vendez du conseil etc ?

    Merci encore !

    • [^] # Re: Demande de compléments

      Posté par . Évalué à 9 (+8/-0). Dernière modification le 06/09/18 à 11:31.

      J'ai lu le Github, c'est bien plus explicite que ce post (mais bon merci pour le post hein, ça m'a permis de découvrir cette fonctionnalité perdue et ce projet très intéressant !).

      L'équipe y est détaillée :

      Authors
      Rémi Venant: remi.venant@gmail.com
      Ahmad Samer Wazan : ahmad-samer.wazan@irit.fr
      Guillaume Daumas : guillaume.daumas@univ-tlse3.fr

      Et les exemples sont bien détaillés et donnent plein d'infos sur le sujet.
      Je pense que tu y trouveras tes réponses.

    • [^] # Re: Demande de compléments

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

      Bonjour,

      Je vous remercie pour votre commentaire.

      "nous" c'est mes collègues et moi-meme qui ont participé à ce travail. Ce travail est le fruit d'un travail de recherche à l'université de Toulouse.

    • [^] # Re: Demande de compléments

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

      Votre modérateur bienveillant du jour a refait la mise en page.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Demande de compléments

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

        Votre modérateur bienveillant du jour a refait la mise en page.

        mici _o/

        tu remplaces Oumph< ponctuellement ?! (oui ça s'est vu \o/ et pas qu'une fois)

  • # Petite question ...

    Posté par . Évalué à 3 (+1/-0). Dernière modification le 06/09/18 à 11:36.

    Bonjour,

    Donner des privilèges à un executable pourquoi pas …

    Récemment j'ai testé l'attribution de privilèges à cause du fameux Selinux pour un cas tout simple concernant apache

    C'est une commande a noter quelque part ok … mais le problème c'est que cela semble lié à l'éxécutable
    et que si pour une raison cet éxécutable change, pour une mise a jour par exemple les privilèges deviennent caduques

    Et cela ne marche plus … tant que l'on a pas remis les privilèges (la fameuse commande)

    Même si c'est logique, cela peut devenir vite contraignant et alourdir la procédure de mise à jour qui dans certain cas peut être assez fréquente.

    Voila je voulais juste vous sensibiliser sur ce point et savoir ce qu'il en est …

    La sécurité à un prix … c'est sur

    • [^] # Re: Petite question ...

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

      Bonjour,

      la mise à jour des executables n'est pas le seul problème concernant le stockage des privilèges dans les attributs étendus. Comme précisé dans la page Github, il existe d'autres problèmes comme : executer des scripts privilégiés, LD_PRELOAD et d'autres.

    • [^] # Re: Petite question ...

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

      Donner des privilèges à un executable pourquoi pas […] mais le problème c'est que cela semble lié à l'éxécutable

      Ce n’est pas la solution présentée dans cette dépêche. Ici, ce qui est présenté; c’est une alternative à su/sudo qui repose sur les « capabilities » et rend ce mécanisme de sécurité utilisable relativement facilement. C’est justement une réponse aux limitations que tu soulèves (et c’est expliqué dans la dépêche).

      • [^] # Re: Petite question ...

        Posté par . Évalué à 3 (+3/-0). Dernière modification le 06/09/18 à 13:25.

        En utilisant notre outil, les utilisateurs n'auront pas besoin des sudo et su qui ne permettent pas de controller les privilèges passés aux programmes.

        D'autres part, je ne comprends pas quand vous dites "la sécurité a un prix" car notre solution ne diminue pas la sécurité, bien au contraire elle permet de limiter l'usage des privilèges à certaines commandes et encore à certain arguments de ces commandes.

        Finalement, je suis d'accord avec vous que la dépêche n'explique pas tout, mais vous pouvez trouver toutes les infos sur la page Github.

        Merci

        • [^] # Re: Petite question ...

          Posté par . Évalué à 7 (+5/-0). Dernière modification le 07/09/18 à 12:03.

          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.

          • [^] # Re: Petite question ...

            Posté par . Évalué à 10 (+9/-0). Dernière modification le 07/09/18 à 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.

            • [^] # Re: Petite question ...

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

              La gestion de sécurité est complexe, car on la fait reposer soit sur les exécutables, soit sur des droits de chaque utilisateurs. Cela marche depuis SELinux, mais c'est hyper complexe. Le système de base root/user a le mérite d'être simple à mettre en œuvre.

              Je pensais que la modèle de sécurité a été "plié" en utilisant la méthode du moindre privilège : en gros, un exécutable root bien élevé est cessé faire tomber tous les privilèges dont il n'a pas besoin (et ni lui, ni ses enfants ne peuvent les récupérer). Si on reprend l'exemple de tcpdump, avec une telle approche le script obtenu ne serait pas vraiment root.

              On peut utiliser aussi ce principe pour lancer des utilitaires "wrappés".

              Il y a un gros reproche à faire à tous ses modes de sécurités : souvent il est question de l'intégrité de la machine, mais souvent l'utilisateur s'en fout, il a surtout peur de perdre les 10 ans de photos à cause d'un crypto-locker. Et même un programme ayant simplement l'id de l'utilisateur peut faire très mal.

              Je pense qu'il faudrait repenser les "capabilities" en fonction des données utilisateurs qui est finalement ce qu'il le plus de valeurs dans le système (perte de données ou fuite de données).

              Si vous arrivez à faire en sorte qu'une faille mozilla soit impossible à utiliser pour sortir des données, le tout sans 3 tonnes de configuration, vous êtes très fort.

              "La première sécurité est la liberté"

    • [^] # Re: Petite question ...

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

      Et cela ne marche plus … tant que l'on a pas remis les privilèges (la fameuse commande)

      Je ne connais que le cas de debian, mais c'est quelque chose qui se laisse très bien gérer par le gestionnaire de paquet (au même titre que s'assurer que les fichiers ont le bon utilisateur, groupe et droits).

      • [^] # Re: Petite question ...

        Posté par . Évalué à 3 (+1/-0). Dernière modification le 06/09/18 à 23:50.

        Oui, et si c'est un contexte changé par rapport à ce que le gestionnaire de paquets attends (qu'il lit du spec du paquet), par exemple parcequ'on utilise un endroit non-standard (cas courant avec apache) alors la création d'un module spécifique de règles selinux correspond au besoin : ne plus avoir en s'en occuper. semanage et zou, simple efficace.

        On peut scripter aussi, pour mettre des attributs plus cools automatiquement sur l'espace data de nextcloud, par exemple, pour profiter de la mise à jour en "full web", puis remettre tout ça plus correctement après, en automatique.

        Et pour démarrer, rien de vaut le retour de logs de setroubles en preprod, il dit quoi faire et comment faire dans 95% des cas, y a plus qu'à pousser en prod. Bref, SElinux c'est pas si compliqué que ça (tant qu'on ne touche pas au :sX ..)

        C'est un peu hors-sujet avec la dépêche, cette tirade. Par contre je me demande comment selinux et rar cohabitent. Hop, direction les tests.

  • # faille tcpdump?

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

    "Un attaquant pourrait exploiter les vulnérabilités de tcpdump afin de compromettre la sécurité du système."

    Même pas besoin de faille dans tcpdump pour accéder à tout le système. On imagine que tcpdump est suid, alors:
    $ tcpdump -n -i lo -G1 -w /dev/null -z ./runme.sh

    va exécuter le script runme.sh avec les droits root.

    Pourquoi? Car tcpdump peut stocker les paquets capturés dans des fichiers (le -w) et éventuellement zipper les fichiers capturé (gain de place) et propose d'utiliser un autre programme de compression que gzip (option -z). tcpdump ne valide absolument pas le programme qui gère la compression, donc là, à chaque rotation de fichier de capture (option -G1 => rotation à chaque paquet capturé), le programme runme.sh est appelé…

    Et root access pour tout le monde …

    • [^] # Re: faille tcpdump?

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

      On imagine que tcpdump est suid

      Pourquoi ? Parce que dans ce cas, on peut imaginer que vim ou less sont setuid aussi.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: faille tcpdump?

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

        Je vais tenter de clarifier mon propos.
        L'article parle des capabilities. Et il référence tcpdump comme exemple, en indiquant que tcpdump pourrait avoir une faille.

        Je suppose que le raisonnement est le suivant: si un utilisateur du système a le droit de lancer tcpdump et que l'utilisateur lance tcpdump et que tcpdump a une faille alors l'utilisateur peut exploiter la faille pour passer root.

        Je dis juste que si un utilisateur a le droit de lancer tcpdump (via sudo, ou le suid), alors l'utilisateur peut passer root, indépendamment d'une faille dans tcpdump.

        Le raisonnement est le même avec vim ou less.

        • [^] # Re: faille tcpdump?

          Posté par (page perso) . Évalué à 6 (+4/-0).

          Je dis juste que si un utilisateur a le droit de lancer tcpdump (via sudo, ou le suid), alors l'utilisateur peut passer root, indépendamment d'une faille dans tcpdump.

          Non. L'utilisation sudo de tcpdump peut être restreint dans le fichier sudoers afin que l'utilisateur X puisse en effet lancer sudo tcpdump (qui sera donc exécuté en tant que root), mais pas d'autre commande. L'exemple de faille donnée est basé sur le fait que tcpdump peut lancer un autre binaire (de compression) qui héritera des droits de root et pourra alors faire tout ce qu'il veut.

          Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

          • [^] # Re: faille tcpdump?

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

            Yes ça me rappelle une (grosse) boite où j'ai bossé et qui pour permettre d'accéder à un fichier de log sur AIX avait utilisé "sudo vim /le/fichier.log" (bon c'était pas en root, mais un membre du groupe admin). Ils avaient bien fixé ça comme seule commande, en passant complètement à coté du fait que l'utilisateur pouvait lancer des commandes depuis vim ! (bon je leur ai quand même dit :-D)

            • [^] # Re: faille tcpdump?

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

              On a peut-être bossé pour la même grosse boîte. J'ai eu un même cas similaire, quelques commandes autorisées dans /etc/sudoers dont vim. Du coup, vim, :!/bin/sh et hop un shell en root :-)

            • [^] # Re: faille tcpdump?

              Posté par (page perso) . Évalué à 7 (+4/-0).

              Je la connais avec un équipement propriétaire qui te demande d'accepter la licence avec un less lancé en root.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: faille tcpdump?

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

          Je pense que ce n'est pas le bon raisonnement dans ce cas. Et je pense qu'il s'agit du suivant:

          Tu lance tcpdump en root (par simplicité) et s'il a une faille, un pirate qui t'enverrait du trafic à ce moment là peut avoir accès à toute la machine alors que s'il n'avait que net_cap, il serait beaucoup plus restreint.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: faille tcpdump?

      Posté par . Évalué à 5 (+5/-0). Dernière modification le 06/09/18 à 14:10.

      Si vous utilisez notre module, vous pouvez empêcher l'utilisateur d'utiliser les options de tcpdump qui lui permet de devenir root. En effet, il suffit de définir un role en lui donnant le privilège cap_net_raw et le limitant à l'argument -i par exemple.
      N'hésitez pas à le tester.

    • [^] # Re: faille tcpdump?

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

      Et root access pour tout le monde …

      Mettre en chmod +s une commande qui peut exécuter un script passé en paramètre, c'est plus du PEBKAC non ?

  • # Appel aux testeurs et aux contributeurs

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

    Comme vous pouvez le constater, dans la page Github nous avons une section "to do list", n'hésitez pas à lire cette section et à nous proposer des idées ou bien contribuer directement au projet.

    N'hésitez pas aussi à nous envoyer vos résultats des tests.

    Merci d'avance

    • [^] # Re: Appel aux testeurs et aux contributeurs

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

      Je mettrais en tout premier de la liste : soit virer le xml, soit développer un outil permettant de ne pas avoir à manipuler cette horreur.

      • [^] # Re: Appel aux testeurs et aux contributeurs

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

        Virer xml non mais developper des outils pour l'éditer oui (c'est déjà prévu).

        • [^] # Re: Appel aux testeurs et aux contributeurs

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

          Pourriez faire du YAML. Quasiment la même chose mais en plus léger !

          C'est ce qui se passe avec cette usine à gaz de polkit (un remplaçant lui aussi de sudo chiant à configurer). Les fichiers systèmes sont en XML mais on peut les surcharger en YAML parce que le XML, c'est vraiment très chiant pour l'admin système.

          À noter que polkit n'a pas réduit l'usage de sudo… Parfois, c'est tellement peu claire que je préférais avoir une ligne claire dans sudoers que ce genre de droit compliqué à tester et qu'on ne sais pas trop si cela marche ou pas alors on élargit d'office !

          • [^] # Re: Appel aux testeurs et aux contributeurs

            Posté par . Évalué à 4 (+4/-0). Dernière modification le 06/09/18 à 17:26.

            Je vous remercie pour cette proposition.
            Je vais l'étudier et voir si on peut faire du YAML à la place de XML.

            Notre objectif est d'étudier l'utilisabilité de notre solution par rapport aux solutions existantes. Je pense qu'il nous manque un peu du support de la part du kernel pour améliorer l'utilisabilité de notre solution. En effet, aujourd'hui le kernel utilise cap_capable() dans le kernel pour vérifier si un processus possède un privilège ou pas. Le problème c'est que cette fonction retourne toujours le meme code erreur quel que soit le privilège vérifié. Si cette fonction est modifiée pour retourner avec le code d'erreur le privilège vérifié, nous pourrons exploiter cette information pour indiquer à l'utilisateur le role qu'il doit assumer.

            bref, une modification du kernel est nécessaire pour améliorer notre solution. Nous allons travailler sur cet aspect prochainement.

          • [^] # Re: Appel aux testeurs et aux contributeurs

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

            «  le XML, c'est vraiment très chiant pour l'admin système »

            T’es sérieux quand tu dis ça ?

            • [^] # Re: Appel aux testeurs et aux contributeurs

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

              D'accord pour dire que "très chiant" c'est exagéré.

              Cela dit, XML reste pénible à utiliser/taper/lire, et perso, partout où j'ai le choix pour de la configuration, c'est JSON ou YAML/INI, en fonction de "contexte web ou pas web, complexe/simple".

              YAML a l'avantage d'être également utilisé par d'autres outils type Ansible qui ont potentiellement la même base utilisateur. XML reste rare pour tout ce qui est setup du système de base.

              Je garde XML pour de l'échange de données inter-systèmes et quand une validation formelle en entrée ou en sortie est nécessaire.

              • [^] # Re: Appel aux testeurs et aux contributeurs

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

                Je garde XML pour de l'échange de données inter-systèmes et quand une validation formelle en entrée ou en sortie est nécessaire.

                Sais tu que YAML (enfin json) a un system de validation? Cela s'appelle json schema et c'est directement utilisable avec yaml.

                • [^] # Re: Appel aux testeurs et aux contributeurs

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

                  Je l'ignorais, mais je ne sais pas encore si ça change grand chose. Entre "ça existe" et "c'est utilisé et suffisamment répandu pour que je puisse m'en servir", il y a un pas.

                  Je vais creuser, merci pour la piste. Ca pourrait permettre de sortir des erreurs plus propres.

            • [^] # Re: Appel aux testeurs et aux contributeurs

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

              Oui, c'est pénible à éditer, à écrire, à faire des "grep"…

              Je trouve que la solution choisie par polkit, les fichiers de la distributions polkit en XML et la surcharge de l'admin systeme dans /etc en YAML très bien.

              Le XML, c'est bien pour les interfaces graphiques, pas trop pour la CLI. Ne rendons pas trop le système trop dépendant des interfaces graphiques comme l'OS de Microsoft !

              • [^] # Re: Appel aux testeurs et aux contributeurs

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

                J’essaie de comprendre. Tu édites le XML avec ed ? Quand tu fais un grep, ça te renvoie tout le fichier sur une ligne ? Pourquoi tu parles d’interface graphique ?

                • [^] # Re: Appel aux testeurs et aux contributeurs

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

                  J'édite avec vim en général… Quand je fais un grep sur un fichier YAML, cela renvoi juste la(les) bonne ligne dont il facile d'extraire la valeur avec cut ou awk. Bref, c'est plus facile de faire de la GLU en ligne de commande avec le YAML qu'avec le XML. Sinon, on voit souvent le XML dans les applications graphiques car -1- avec les schémas, c'est facile à valider coté dév et -2- malgré le coté verbeux, ça marche bien. Java et Tomcat en ont d'ailleurs un peu abusé ;-)

                  • [^] # Re: Appel aux testeurs et aux contributeurs

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

                    Vraiment ? Faut arrêter que l'ont utilise grep/less pour vite fais se retrouver dans un document pourquoi pas, mais c'est des langages qui ne sont pas parsables avec grep, sed ou awk. Que ce soit ini, json, xml ou yaml. Le fait que tu en ai l'impression ne fait que te faire écrire des bugs que tu n'a pas encore découvert. Si json était parsable avec ses outils jq n'aurais pas de raison d'être. Seul awk est capable d'avoir un contexte, mais si tu veux te servir d'awk pour ça tu va rencontrer pas mal de difficulté.

                    La phrase de Douglas Mcliroy c'est « Make each program do one thing well » (qu'on traduit généralement par « Écrivez des programmes qui effectuent une seule chose et qui le font bien ») et pas « binutils can make all things ». Quand tu parse un format qui n'est pas conext-free, utiliser des outils qui sont context-free c'est aller au devant de jolis problèmes. Je suis persuadé que pour le moment vu que c'est toi qui écris les parseurs et que les formats d'entrée n'ont pas trop évolués « ça passe ». Mais « ça passe » ça veut juste dire que le cas nominal fonctionne. Je présume que je peux casser ton parseur juste en construisant le fichier qui va bien sans changer son format et je sui parfaitement certain de pouvoir casser silencieusement ton parseur si je modifie le format.

                    Donc personnellement, je dirais que si xml permet de démotiver les gens à tenter de faire du parsing en grep/sed, il vaut mieux faire du xml.

                    • [^] # Re: Appel aux testeurs et aux contributeurs

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

                      "c'est des langages qui ne sont pas parsables avec grep, sed ou awk"
                      On doit pouvoir les parser avec xml-grep, xml-sed ou xml-awk ?

                      ben si ça existe

                      "personnellement, je dirais que si xml permet de démotiver les gens
                      à tenter de faire du parsing en grep/sed, il vaut mieux faire du xml."

                      Je comprends ce point de vue mais ça ne me semble pas très constructif.

                      Je me suis rendu compte au boulot que très peu de gens connaissent les bases
                      en XML, y compris dans les domaines ou c'est incontournable, et donc on a souvent
                      droit à une réaction de rejet et des décisions idiotes (remplacement par "du CSV pour
                      des dinos ou du JSON pour des hipsters").

                      • [^] # Re: Appel aux testeurs et aux contributeurs

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

                        c'est des langages qui ne sont pas parsables avec grep, sed ou awk

                        On doit pouvoir les parser avec xml-grep, xml-sed ou xml-awk ?

                        Ça n'a rien avoir. On peut très bien écrire des parseurs oui. Mais xml-grep, n'est pas grep.

                        personnellement, je dirais que si xml permet de démotiver les gens
                        à tenter de faire du parsing en grep/sed, il vaut mieux faire du xml.

                        Je comprends ce point de vue mais ça ne me semble pas très constructif.

                        Si le besoin de tes utilisateurs, c'est de faire du grep alors, tu utilise un format qui se manipule bien avec grep. Laisser des légendes urbaines comme csv ou yaml ça marche avec mon sed, ça va poser des problèmes soit à toi soit à très utilisateurs. Le seul format véritablement parsable avec ces outils c'est properties. Le truc c'est qu'en vrai ils s'en foutent ce qu'ils veulent c'est que ce soit joli ou conci. Parce que c'est forcément plus lisible (les liens de documents en yaml ? Les chaînes de caractères qu'on peut écrire de 3 ou 4 façons ? L'indentation relou avec les chaînes de caractères multilingnes?…). Tu ne trouvera personne pour dire que ngnix a un format de configuration pas bien parce qu'il ne peut pas être parsé via grep et pour le coup tu ne trouvera rien qui te permet de le parser. Non c'est xml qui a mauvaise presse pour des raisons qui n'ont rien de rationnelles. Tu peux trouver des gens qui sont fort de manipuler du html à tour de bras,mais qui vomissent xml.

                        Xml est un format qui a pleins de problèmes et qui est souvent mal implémenté, mais ceux qui sortent des arguments comme réécrit ton outil avec yaml parce que moi j'aime bien yaml, me donnent plus envie de tout remplacer par asn1 que par le truc à la mode qu'ils auront trouvé.

                    • [^] # Re: Appel aux testeurs et aux contributeurs

                      Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 11/09/18 à 11:05.

                      Ton programme (ou mon programme) se configure avec du YAML et le lit avec un vrai parser YAML (donc conforme). Donc tout va très bien. En quoi est-ce un problème de pouvoir faire un grep, un ack ou un awk dessus pour certaines taches de recherche / contrôle ? Par exemple un test Nagios ou autre…

                      Bref, un "egrep 'ChapeauCrochetCrochet:space:CrochetCrochet*clef:' | awk '{print $2}'" renvoie la valeur d'une clef et cela peut être très pratique dans certains cas. C'est lisible et pour moi, c'est pas un bogue d'écrire cela ! J'ai jamais dis qu'il fallait parser 100% du fichier YAML en Bash !

                      Après, il y a effectivement des personnes pour qui il faut un programme Java ou un pip install d'une détrachiée de module pour juste lire une clef d'un fichier.

                      • [^] # Re: Appel aux testeurs et aux contributeurs

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

                        En quoi est-ce un problème de pouvoir faire un grep, un ack ou un awk dessus pour certaines taches de recherche / contrôle ? Par exemple un test Nagios ou autre…

                        Parce que c'est du bricolage qui ne marche pas. Le fait que ça marche pour l'exemple sur le quel tu l'a fait à l'instant où tu l'a mis en place ne dis pas que ça fonctionne. C'est vraiment très fragile comme fonctionnement et baser ton monitoring sur quelque chose d'aussi fragile c'est vraiment pas une bonne idée. Tu veux pas que ton monitoring casse plus souvent que ton environnement en principe. Passer son ton à faire de la maintenance de scripts c'est une perte de temps. Surtout qu'il est vraiment facile d'utiliser un outil adapté.

                        Mais surtout je dis que c'est pas un argument pertinent plus qu'un problème. Que tu fasse n'importe quoi dans ton coin, tant pis pour toi, que tu demande de changer le logiciel pour pouvoir faire n'importe quoi c'est une demande qui n'est pas particulièrement argumentée.

                        Bref, un "egrep 'ChapeauCrochetCrochet:space:CrochetCrochet*clef:' | awk '{print $2}'" renvoie la valeur d'une clef et cela peut être très pratique dans certains cas. C'est lisible et pour moi, c'est pas un bogue d'écrire cela !

                        Et ta super ligne donne quoi sur :

                        foo:
                          bar:
                            clef: |
                        v
                        a
                        l
                        e
                        u
                        r
                        5
                          bar2:
                            clef: 'val
                        ''eur'' 6'

                        Comment font les gens pour utiliser nginx si c'est nécessaire d'avoir un parsing grep/sed/awk ?

                        • [^] # Re: Appel aux testeurs et aux contributeurs

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

                          Mon dernier post car tu est de mauvaise fois. Je te dis que c'est intéressant pour tester une clef particulière dans certain cas et tu me sors un fichier YAML complexe avec deux fois 'clef' et des machins multi-lignes. J'ai bien dis que je ne parse pas du YAML depuis Bash ! Uniquement quelques cas simples… En règle générale, j'utilise un vrai parseur avec un langage qui gère cela très bien comme Python ou Perl par exemple.

                          Tu dis que c'est fragile… Il y a tout plein de cas ou la clef est unique et le fichier YAML très très simple. Tu fait un test super simple et la maintenance ne change pas tant que le service tourne. Le jour d'une grosse mise à jour du service, tu mets à jour le test mais cela, c'est le cas quelque soit le test !

                          Si ton système de configuration des serveurs est versionné (git…) et avec déploiement automatique sur les postes (puppet…), la mise à jour une fois tous les 3 ans d'un test de deux lignes qui génère un faux positif n'est pas forcément une perte de temps. Je ne fais pas partie des fanatiques qui veulent sortir Bash des systèmes UNIX ;-)

                          • [^] # Re: Appel aux testeurs et aux contributeurs

                            Posté par . Évalué à 1 (+2/-2). Dernière modification le 11/09/18 à 15:25.

                            Le coût d'utiliser un outil adapté (yq, (jq)[https://stedolan.github.io/jq/] ou xml-coreutils) est beaucoup trop faible pour qu'utiliser autre chose soit acceptable. Faire les choses bien n'est pas plus compliqué ça demande seulement de vouloir le faire.

                            • [^] # Re: Appel aux testeurs et aux contributeurs

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

                              yep ça c'est typique le gars qui lorsqu'il doit faire un script qui tourne une fois sur un cas simple et dont les valeurs sont prévisibles, va installer 50 bibliothèque / exécutable pour faire en 2J ce qu'une ligne de commande écrite en 2 minutes fait.

                              Mais au moins c'est propre !

                              Et encore j'ai pris le cas où le service info fait son taf, et qu'en plus l'utilitaire est dans les repos.

                              Et puis c'est aussi à supposer que l'outil n'a pas de bug. J'ai parlé du module xpath de python qu'est pas capable de gérer les namespace XML ?

                              Et parfois le coût il est pas 'trop faible'; lorsque tu te contente d'un grep ça va; quand tu dois faire un enchainement de grep -B, puis grep -A…

                              Note bien j'ai rien contre faire les choses propres, pour la configuration des bases décrites dans un xml, je les chopes via du xpath.

                              Mais parfois c'est plus simple/rapide/efficace de se passer des outils dédier.

                              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                              • [^] # Re: Appel aux testeurs et aux contributeurs

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

                                yep ça c'est typique le gars qui lorsqu'il doit faire un script qui tourne une fois sur un cas simple et dont les valeurs sont prévisibles, va installer 50 bibliothèque / exécutable pour faire en 2J ce qu'une ligne de commande écrite en 2 minutes fait.

                                Tu veux faire modifier l'outil pour une action que tu fais une fois à l'arrache ? Faut se plier aux demandes pour chaque lubies du cas particulier du gars qui utilise un truc une fois et qui veut pas s'embêter et donc préfère faire porter le travaille sur les dev ?

                                2 commentaires plus haut il est question de faire faire ça à l'outil de monitoring, hein ?

                                Mais au moins c'est propre !

                                Il était question de faire faire ça à nagios, hein ?

                                Et puis c'est aussi à supposer que l'outil n'a pas de bug. J'ai parlé du module xpath de python qu'est pas capable de gérer les namespace XML ?

                                J'ai vu bien plus de bug dans scripts de scripts kiddies que dans les bibliothèques. Sûrement parce que l'un des 2 écrit des tests et pas l'autre ?

                                Mais parfois c'est plus simple/rapide/efficace de se passer des outils dédier.

                                C'est comme si tu disais qu'utiliser la commande docker, il y a pleins de fois où c'est compliqué alors que tu peut tout faire avec ton netcat/socat tu peux directement tout faire sur la socket unix du deamon. Avoir l'outillage qui permet de manipuler les logiciels que tu gère c'est ton job, le mode « j'y vais avec ma bite et mon couteau » c'est pas un gage de qualité. Sélectionner et savoir utiliser ses outils et en comprendre les limites, c'est le boulot d'un opérationnel.

                      • [^] # Re: Appel aux testeurs et aux contributeurs

                        Posté par (page perso) . Évalué à 7 (+4/-0).

                        une détrachiée …

                        Non, c'est une tétrachiée ! Et ça vaut 44.
                        Un chiée, ça fait onze et onze fait chiée. Par conséquent une tétrachie vaut 4 fois plus donc 44.
                        Par extension, l'expression courante "une tétrachiée plus une vaut 45.
                        Qu'on se le dise !

            • [^] # Re: Appel aux testeurs et aux contributeurs

              Posté par . Évalué à 3 (+1/-0). Dernière modification le 08/09/18 à 18:37.

              Ben moi je le pense sérieusement.

              J'utilise les 3 formats (json, yaml et xml) quasiment tous les jours, et c'est xml qui pose le plus de problème.

              Le XML n'a jamais été fait pour être éditable par un humain.

              • [^] # Re: Appel aux testeurs et aux contributeurs

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

                Le XML n'a jamais été fait pour être éditable par un humain.

                Là on bascule dans l’extrémisme :-D

                XML dérive se SGML qui a quand même été pensé pour l'utilisation par les humains (c'est quand même pas du binaire ou du BSON ou du gzip !).

                Mais ce qui est sur, YAML est né comme une alternative plus facile à manipuler par les humains.

                Perso je trouve qu'effectivement YAML a un bon équilibre flexibilité / facilité d'édition, et reste très facile à utiliser coté programme. Donc je trouve que c'est pas mal pour la configuration.

                Il reste une fonctionnalité de XML qui manque, à mon goût, à YAML, c'est les namespaces.

                (PS: je suis contre JSON pour la configuration pour la simple raison que en JSON, pas de commentaires, ce qui est une plaie dans ce cas).

                • [^] # Re: Appel aux testeurs et aux contributeurs

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

                  Le YAML est très bien et je l'utilise et le promeut depuis des années mais il a aussi des inconvénients. Il est vrai que les outils de validation sont moins nombreux et que si on fait un fichier hyper long très complexe, il peut lui aussi devenir compliqué à gérer.

                  Bref, YAML est super pour les choses simples ce qui me semble le cas présent sur l'outil "CAP" proposé.

                • [^] # Re: Appel aux testeurs et aux contributeurs

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

                  XML dérive se SGML qui a quand même été pensé pour l'utilisation par les humains (c'est quand même pas du binaire ou du BSON ou du gzip !).

                  D'après wikipédia, L'objectif initial de XML est de faciliter l'échange automatisé de contenus complexes (arbres, texte riche…) entre systèmes d'informations hétérogènes (interopérabilité) .

                  J'essaierai de retrouver d'autres sources (celles que j'avais utilisées à l'époque ou je me suis intéressé à xml - ce doit être un bouquin de chez o'reilly) qui détaillent un peu plus tout ça. mais si ma mémoire ne me fait pas défaut, et ma compréhension de l'époque était la bonne (et je peux avoir mal compris), le fait qu'xml soit manipulable par des humains n'est qu'une conséquence, pas le but.

                  Sinon, le xml ne me dérange pas lorsqu'il est utilisé à bon escient (je pense par exemple au format OpenDocument, ou au format svg), mais lorsqu'il s'agit de choses éditables par des humains, tel que des fichiers de conf, j'ai tendance à ne pas aimer (je n'aime d'ailleurs pas le format de fichier de conf d'Apache qui est une espèce de pseudo xml/html qui est parfois lourd à manier et difficile à comprendre).

                  Il reste une fonctionnalité de XML qui manque, à mon goût, à YAML, c'est les namespaces.

                  Là je suis tout à fait d'accord avec toi : je ne trouve pas le yaml parfait, mais beaucoup plus facile à utiliser pour de la conf (ou des trucs qui doivent être édités/manipulés par des humains).

  • # Problèmes

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

    Donc si je résume bien vous listez 3 problèmes des capabilities :

    1. Utilisation des attributs étendus (xattr des fs)
    2. Manque de finesse dans à qui ont donne les droits
    3. Impossibilité de définir les droits par introspection des binaires

    Perso de ce que j'avais compris le principal problème des capabilities, c'est que ce sont de gros trous de sécurité :
    False Boundaries and Arbitrary Code Execution
    .

    • [^] # Re: Problèmes

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

      Le système de capacité de Linux souffre de nombreux problèmes. En tous cas, si vous utilisez le mode no-root (-n option) vous répondez à certain problèmes cités dans le lien que vous avez fourni (False Boundaries and Arbitrary Code Execution). Le mode no-root permet de désactiver le traitement particulier de uid 0 et vous permet d'avoir un système qui considère root comme utilisateur standard.

  • # C'est quand même un changement profond de paradigme ...

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

    Un brouillon POSIX (POSIX draft 1003.1e) avait été proposé afin de définir un modèle qui permet de donner aux processus uniquement les privilèges de super‐utilisateur dont ils ont besoin.

    L'approche unix se base sur les droits attribués à un utilisateur sur les objets manipulés (fichiers, etc …) et non sur des droits attribués à un processus. Et je crains qu'ajouter une couche de contrôle au niveau processus ne vienne à rendre difficile la gestion des accès au ressources, surtout soi à ça on interagit avec d'autres couches telles que selinux par exemple. Après, si on intègre les diverses couches à un seul outil, pourquoi pas, mais vu qu'on se dirige de plus en plus vers des applications orientées microservices sur des containers/VM n'ayant que peu de choses qui tournent dessus, je me demande si les admins prendront le temps de gérer ce genre de choses.

  • # Très intéressant, mais moins pratique que pledge

    Posté par . Évalué à 6 (+7/-2). Dernière modification le 06/09/18 à 14:23.

    Sur le système OpenBSD il y a le principe de pledge qui est très intéressant à noter et qui, comme ici, permet de limiter le pouvoir qu'a un programme sur la machine. L'idée de pledge est d'ailleurs largement plus simple que les capacités du noyau Linux.

    On part du principe qu'un programme se compose généralement de 2 parties : la partie initialisation (on ouvre des sockets, des fichiers, on lit une configuration, etc.) et une boucle de travail (répondre à des requêtes HTTP par exemple). De ce fait, on sait ce qui doit et ne doit pas pouvoir se passer dans la boucle. On va donc dire qu'on assure n'utiliser par exemple que le réseau et le DNS avant d'entrer dans la boucle infinie, en indiquant dans le programme une simple ligne pledge ("inet dns"); et voilà.

    J'ai regardé légèrement SELinux, les capacités Linux, et encore deux ou trois autres systèmes comme ceux-là… on est à des années-lumière de la simplicité de pledge, et du coup pas grand monde utilise ces mécanismes. Et au contraire, tous les programmes OpenBSD sont passés à pledge en l'espace de deux releases (une année), permettant de trouver des erreurs de programmation dans le code de certaines applications comme openbgpd.

    (ma vie) C'est assez drôle d'ailleurs, la première fois que je me souviens avoir entendu parlé de SELinux était quand il fût responsable d'un problème de démarrage de programme sur ma machine.

    • [^] # Re: Très intéressant, mais moins pratique que pledge

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

      Bonjour,

      Je crois que vous mélangez les 'capability based access control model' avec linux capability. Vous avez raison de confondre les deux car Linux utilise le mot capability. Mais en fait ce sont deux choses différentes. Pledge, seccomp et encore capsicum permettent de contrôler les appels systèmes des processus. Linux capabilities (nous devons utiliser le mot privilege) c'est l'ensemble des permissions dans le kernel qui sont traditionnellement réservés au root.

      • [^] # Re: Très intéressant, mais moins pratique que pledge

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

        L'objectif final est le même : rendre le système plus sûr en limitant le pouvoir de nuisance d'une faille. Et pour cela, dans tous les cas, on limite les droits d'une application. L'approche est certes différente, comme vous dites Linux capabilities est différent de seccomp, capsicum et pledge, mais on cherche à faire la même chose. Ce que je dis dans mon commentaire est justement ça : l'approche est différente, et en pratique moins intéressante à cause de sa complexité de mise en œuvre et du coup du peu d'intérêt pour les développeurs. Oui ça existe dans le noyau depuis longtemps, et le fait que pas grand monde l'utilise me semble révélateur de l'échec que représente cette approche.

        • [^] # Re: Très intéressant, mais moins pratique que pledge

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

          J'insiste sur le fait qu'il ne faut pas mélanger le capability based access control modele avec Linux capability. Je m'explique: admettant qu'un programme souhaite ouvrir un raw socket. Le programme doit absolument posséder cap_net_raw privilège sinon le call socket ne va pas fonctionner. Nous appelons le retour du call socket (file descriptor) comme capability dans le domaine "capability based access control". Ce descripteur normalement doit être initialisé et passé à un autre processus qui n'a pas le droit de faire des appels aux syscalls…

          Par ailleurs, notre module est plutôt un outil pour les administrateurs et les utilisateurs, mais pas pour les développeurs. Comme vous le savez, tous les programmes ne sont pas forcément bien développés (imagine un programme qui demande à utilisateur de faire un sudo car il a besoin uniquement d'un seul privilège). Le fait que les administrateurs et les utilisateurs possèdent des outils qui leur permettent de contrôler les privileges passés au programmes c'est forcément avantage.

          • [^] # Re: Très intéressant, mais moins pratique que pledge

            Posté par . Évalué à 6 (+6/-1). Dernière modification le 06/09/18 à 16:05.

            Je comprends bien ce que vous dites, et contrairement à un système comme pledge, vous partez du principe qu'on ne touche pas à l'application mais on la contraint par une autre manière que la perte de privilèges volontaire indiquée dans le code. L'hypothèse de départ est différente, dans un cas on a le code de programmes dont on veut assurer encore plus la sécurité, de l'autre on part uniquement des binaires pour gérer la sécurité.

            Et c'est exactement ce que je disais : deux approches. Et là où on peut accepter qu'un programme "s'initialise" puis lâche ses privilèges avec pledge, le même fonctionnement est impossible avec les privilèges Linux et on doit séparer le programme en deux pour le même résultat : le binaire conserve ses privilèges même lorsqu'il entre dans sa boucle de fonctionnement donc l'initialisation doit se faire ailleurs.

            Donc on a des hypothèses de départ différentes :

            • avoir accès au code, pouvoir y ajouter une ligne pour limiter ses droits
            • ne pas avoir accès au code, ou ne pas vouloir y toucher (ni s'en préoccuper)

            Un fonctionnement différent :

            • une ligne de code indiquant qu'on ne conserve qu'une partie de nos privilèges
            • des outils externes au programme qui vont donner des privilèges

            Des fonctionnalités et contraintes différentes :

            • on peut avoir des droits au début pour l'initialisation puis y renoncer (fonctionnement normal de toutes les applications serveur), mais on doit toucher au code
            • on donne des privilèges à une application sans pouvoir lui en retirer une fois la phase d'initialisation terminée, mais on n'a pas besoin de connaître l'application, et on veut juste s'assurer qu'elle n'aille pas fouiller le système et lui interdire des appels systèmes

            Mais un même but final : contraindre une application aux seuls privilèges dont elle a besoin. On pourrait donc discuter des usages possibles de chacune des approches, certes, mais l'objectif est quand même identique.

            Par ailleurs, dans les deux cas il faut bien qu'on sache ce que l'application est sensée faire pour y attribuer les bons droits… donc le fait d'avoir ou pas à modifier le code (quand on parle seulement d'ajouter une ligne de code), n'est pas un argument qui pèse lourd. Cet argument vaut surtout pour les applications non libres, où on n'a pas du tout accès au code source, sinon ajouter une ligne de code me semble préférable à la complexité des capacités Linux. L'approche (caricaturée) ici est donc "on ne gère pas la sécurité en amont, les admin feront le job plus tard".

            • [^] # Re: Très intéressant, mais moins pratique que pledge

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

              Merci pour ce commentaire assez intéressant.

              Moi je pars du principe suivant: aujourd'hui nous utilisons tous les commandes sudo et su par défaut, ce qui est très dangereux. Tous les programmes peuvent avoir des vulnérabilités et certains programmes ne sont pas forcément bien écrits et ne gèrent pas les privilèges correctement dans leur code. Par ailleurs, quand on donne un ou deux privilèges à un programme, on n'est pas sûr que le programme va l'utiliser sur la ressource qu'il est censé utiliser. Par exemple, quand je donne le privilège cap_net_bind_service à un programme qui est censé l'utiliser pour écouter sur le port 80. Qu'es qui me garantit que le programme ne va pas utiliser ce privilège pour écouter le port 81?

              Notre module est donc une amélioration de la situation actuelle. Mais un bon programme doit utiliser des approches comme pledge et capsicum. Il doit aussi savoir gérer les privilèges qui consiste à désactiver les privilèges quand il n'en a plus besoin. Vous pouvez regarder notre code source pour avoir un exemple mais aussi le code source de ping qui est aussi un bon exemple sur l'utilisation des privilèges.

              • [^] # Re: Très intéressant, mais moins pratique que pledge

                Posté par (page perso) . Évalué à 1 (+0/-1). Dernière modification le 06/09/18 à 17:05.

                Il me semble que l'approche pas capability marchait mal parce qu'il y avait au final quelques capability clefs qui font tout le job et que ce n'était pas bien réparti…

                Je suis perso assez dubitatif. Par le passé, on a vu que cette approche par les CAP marchait pas trop, l’approche SELinux non plus (trop complexe)… Je crois qu'il faut essayé de plus faire confiance dans les DEV et faire une API propre (et standard entre OS) pour comme avec secomp et pledge, que l'appli réduire elle même son angle d'attaque. Ce sont les développeurs qui connaissent souvent le mieux celle-ci (et c'est plus facile à maintenir dans une même branche git).

                Bref, les restrictions via l'OS comme vous le faites sont bien mais peu utilisée… car je pense trop éloigné de l'arbre de développement des codes.

                • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                  et si vous voulez controller les listes de privilèges que vous donnez à vos développeurs? Par exemple, un développeur construit une solution sur un serveur, l'administrateur du serveur souhaite lui donner une partie des privilèges pour tester sa solution sur le serveur, mais pas tous les privilèges. Notre solution peut bien servir dans ce cas.

                  • [^] # Re: Très intéressant, mais moins pratique que pledge

                    Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 06/09/18 à 18:07.

                    Je suis d'accord. Dans le cas que vous dites, cela peut marcher.

                    En pratique, des dev web vont vouloir être "root" via par exemple l'utilisation de conteneur genre docker. De plus en plus, cela va s’appuyer sur de l'intégration continue lié à par exemple gitlab…

                    Bref, c'est intéressant comme approche mais je crains que cela ne soit pas super utilisé.

                    Un truc que j'aimerais faire (simplement) est un rsync distant en mode readonly. Genre

                    rsync -av toto@server1:/etc /tmp/etc
                    Il y a moyen d'assurer que le rsync server qui tourne sur server1 soit en mode readonly sur le système de fichier avec votre système avec évidement la possibilité de voir tous les fichiers (comme root) ?

                    • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                      Il existe le privilege cap_dac_override que vous pouvez donner à votre utilisateur « toto » en précisant la commande rysync avec les options associées. Maintenant cap_dac_override permet de tout faire (read,write, execute) mais uniquement dans le dossier /etc. Nous ne pouvons pas limiter à readonly car les privileges Linux ne sont pas assez fines, contrairement à d’autres systèmes comme Solaris qui possède des privileges fines et permettent de réaliser ce que vous demandez.

                      Une amélioration du kernel à ce niveau est nécessaire.

                    • [^] # Re: Très intéressant, mais moins pratique que pledge

                      Posté par . Évalué à 3 (+2/-0). Dernière modification le 07/09/18 à 11:40.

                      Je reformule ma réponse. En effet, Linux possède le capability CAP_DAC_READ_SEARCH. Ce privilège permet uniquement de lire les fichiers. Donc vous pouvez éditer le fichier de configuration capabilityRole.xml de la manière suivante:

                          <role name="role1">
                                  <capabilities>
                                      <capability>CAP_DAC_READ_SEARCH </capability>
                                  </capabilities>
                                  <users>
                                      <user name="toto">
                                          <commands>
                                              <command>rsync -av toto@server1:/etc  /tmp/etc</command>
                                          </commands>
                                      </user>
                                  </users>
                              </role>    
                      

                      Apres l'utilisateur toto doit utiliser la commande suivante: sr -r role1 -c "rsync -av toto@server1:/etc /tmp/etc"

                  • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                    Aujourd'hui si on a besoin de droit spéciaux, on utilise docker.

                    "La première sécurité est la liberté"

                • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                  On peut ajouter que dans le monde linux il n'y a pas que les administrateurs et les utilisateurs. Il y a ceux qui font la distribution, et c'est eux qui ont toutes les billes pour mettre ses restrictions en place. L'approche de pledge semble bien plus facile à mettre en œuvre industriellement que l'approche par utilisateur.

                  Je rajouterais qu'il manque des privilèges user qui serait sympa : impossible de faire .. pour sortir d'un répertoire de lancement, n'ouvrir que les fichiers créés par l'application en question et rien d'autre, ne pas pouvoir lire des fichiers locales, mais parcourir les répertoires, et écrire dedans si on veut. On pourrait même imaginer que le shell détecte les fichiers données en ligne de commande et donne l'accès uniquement à eux.

                  "La première sécurité est la liberté"

              • [^] # Re: Très intéressant, mais moins pratique que pledge

                Posté par . Évalué à 6 (+6/-1). Dernière modification le 07/09/18 à 01:58.

                Je viens de voir votre readme. La seule chose que je peux vous dire, c'est que vous vous embêtez vraiment beaucoup à définir des rôles, utiliser les capacités Linux, et tout un tas de choses compliquées pour au final remplacer pledge et doas. Tout votre exemple sur le script python autorisé à démarrer à partir de l'utilisateur awazan de lancer son serveur sur le port 80 revient à autoriser une personne à lancer une application avec certains paramètres, et c'est pratiquement tout. Donc vous demandez aux administrateurs de créer des fichiers XML pour décrire des rôles qui auront des droits, des utilisateurs qui pourront avoir ces rôles et les applications qu'ils pourront lancer avec en plus les paramètres autorisés.

                Voici le même exemple avec pldege (voir pledge(2)) et doas (voir doas.conf(5)) :

                pledge("inet", NULL);

                Dans le fichier /etc/doas.conf :

                permit nopass awazan as root cmd python /usr/local/Users/awazan/server.py -p 80

                Et voilà… alors certes, vous pouvez toujours trouver des arguments un peu pointus pour montrer que cela n'est pas 100% équivalent, mais on en est vraiment pas loin, tout en ayant une bien moins grande complexité et donc en ayant bien plus de chances d'être effectivement intégré sur de vrais systèmes en production (ce qui est le cas pour tous les systèmes OpenBSD depuis plusieurs années maintenant).

                Le second exemple que vous donnez implique de ne pas pouvoir faire du LD_PRELOAD, ce qui est déjà pris en compte par mon exemple de fichier doas, tout simplement parce qu'on doit préciser explicitement via keepenv si nous souhaitons garder les variables d'environnement de l'utilisateur au lancement de la commande. C'est un fonctionnement par défaut qui me paraît complètement raisonnable, et sûr par défaut.

                Votre troisième exemple indique qu'il faut actuellement utiliser des commandes compliquées pour injecter des capacités dans le binaire des applications, puis ces privilèges sont supprimés dès que le binaire change, et donc votre solution apporte une certaine stabilité. Oui, comme doas.

                Du coup, même en ayant creusé votre proposition, je ne peux que vous encourager à regarder ce qui est fait côté OpenBSD. C'est de loin pour moi un exemple du meilleur de ce qui se fait dans le domaine.

                PS: j'ai l'impression que votre travail est lié à une publication scientifique. Je suis sincèrement désolé de voir à quel point vous avez travaillé pour arriver au final à moins bien que ce qui est déjà fait. Certes, c'est externe à l'environnement Linux, mais vous auriez sans doute pu vous en inspirer… bref. Je compatis. Moi aussi je suis dans le domaine et je ne fais pas toujours des articles intéressants. Courage pour la suite.

                • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                  Je crains que votre solution ne suffit pas de protéger complètement votre OS. En effet, la configuration de la commande doas vérifie uniquement que l'utilisateur ne va pas passer au script une valeur différente à 80. Rien n'interdit par contre l'utilisateur awazan d'ouvrir un port qui est différent de 80. Par ailleurs, la configuration doas permet au utilisateur awazan de récupérer les privilèges root pour exécuter ce script. Je me demande donc si l'utilisateur awazan n'aura pas la possibilité de créer un autre processus et changeant les arguments de pledge pour pouvoir appeler d'autres syscall..(à tester).

                  Je pense que vous avez toujours du mal à comprendre que pledge et les separation des privilèges sont des solutions complémentaires. Je vous propose de regarder cette video qui est justement faite par OpenBSD sur la complémentarité de ces deux solutions.

                  https://www.youtube.com/watch?v=a_EYdzGyNWs

                  PS: Ma solution ne permet toujours pas de vérifier si l'utilisateur a vraiment ouvert le port 80 ou un autre port. Simplement, si vous avez lu la section to "do list" vous verrez que nous comptons modifier le kernel de Linux pour couvrir cet aspect.

                  • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                    Soyons d'accord sur ça : non, aucun programme actuel ne vérifie ce que vous souhaitez vérifier avec votre projet. Si je grossis un peu le trait (dites-moi si je me trompe, qu'on soit définitivement d'accord sur la question), votre projet est d'intercepter tous les appels systèmes pour vérifier à la fois si ce sont des appels autorisés, et les paramètres qui y sont passés. Au final oui, vous allez bien plus loin que ce qui existe. Mais je vois 2 problèmes majeurs : les outils (et méthodes) actuels se rapprochent d'une vérification à gros grain mais qui couvre une (très) bonne partie des problèmes, et la complexité pour décrire des autorisations.

                    Revenons sur vos exemples.
                    Concernant les ports ouverts, effectivement, pledge et doas ne peuvent pas vérifier cela. En revanche c'est le travail de pf (le pare-feux packet filter), et il le fait très bien, il va même au delà de ce que vous souhaitez faire : vous pouvez préciser les messages qui sont ou pas accepter (est-ce qu'il doit accepter d'ouvrir des connexions TCP à partir de ce port, ou seulement en recevoir ? Est-ce de l'UDP ? SCTP ? Quelle taille de buffer ? …).

                    Pour l'exemple que vous donnez d'un subprocess qui serait appelé par un programme d'awazan, et que ce programme aurait été modifié par awazan pour y ajouter des éléments dans pledge, c'est au final très peu réaliste. En réalité, il est hors de question de donner des droits root à un simple utilisateur sur un programme de l'utilisateur. C'est un non sens, littéralement une faille de sécurité.

                    Comme nous l'avons vu pour l'instant, les exemples couvrent l'usage du réseau, ce qui est important également c'est l'usage du système de fichiers, et pour ça la séparation de privilèges (que j'ajouterai volontiers : amorcée par le projet OpenBSD…) et le chroot. Rien qu'avec les outils que je viens de citer, on sait gérer en grande partie le réseau (quels sont les ports qui peuvent être ouverts), on ne laisse pas une application ouvrir des fichiers au hasard sur le système (elle est contrainte dans une racine séparée), et on ne laisse pas un simple utilisateur s'octroyer des droits (hors de question qu'on laisse des droits root sur un programme utilisateur, on donne le droit à un utilisateur de lancer un programme root avec des paramètres prédéfinis).

                    On peut dire également que votre projet permet à un simple utilisateur de lancer son propre programme de manière sûre… si on a fait un gros travail en amont pour contraindre le programme qu'il veut lancer à ne faire que ce dont on a décidé. Effectivement, vous pouvez aller jusqu'à préciser à la fois qu'un programme en particulier sera utilisé par un utilisateur en particulier et qu'il n'aura pas le droit d'ouvrir autre chose qu'un port en particulier. Mais tout ceci reste laborieux, et en pratique les paramètres vont changer très souvent. Là où les outils actuels font bien leur travail est qu'ils maintiennent une balance intéressante entre le temps pris pour l'administration/développement, et les vérifications qui sont faites. C'est simple, rapide à implémenter, et du coup c'est utilisé.

                    Ensuite, concernant la complexité de description des autorisations. Vous avez fait un travail pour alléger l'écriture des différentes règles en définissant des rôles à des utilisateurs et des groupes, ce qui est un moyen assez simple de regrouper des instructions qui ont un même sens sémantique. Ça ne va pas assez loin, c'est même bien trop simpliste. Les exemples qu'on peut voir sont également simplistes, et je ne vois pas votre projet fonctionner pour de grosses applications, il y a un manque d'expressivité. Je ne peux que vous conseiller de regarder la syntaxe de pf dans la FAQ OpenBSD pour vous en inspirer.

                    Pour que votre solution soit utilisable, il faudrait selon moi regrouper les appels système, pouvoir donner des indications "laxistes" où on dirait "vérifie que le programme X n'ouvre que le port Y, mais je m'en fous de tout autre paramètre lié au réseau". Sinon on sera obligé d'écrire des tonnes d'instructions pour couvrir tous les appels qui sont fait. Par exemple, si un programme a besoin de lire et écrire des fichiers, il va être un peu pénible de devoir faire une instruction pour préciser tous les appels de open avec tous les fichiers (ou alors il faut s'inspirer des tables dans pf). Bref, regardez la syntaxe pf, il y a déjà tout ce que vous voulez : des tables pour regrouper des capacités, utilisateurs, groupes, des instructions de blocage ou acceptation (block, pass) et la possibilité de dire "tout sauf" (via '!') ce qui est pratique, des macros pour simplifier la lecture, des listes, des ancres pour donner la possibilité à une application externe d'ajouter des instructions à la volée…

                    Allez, je ne résiste pas à donner un exemple :

                    table <webusers> { awazan, toto } # table = liste qui peut être màj à la volée via une commande
                    cap_net_web = "cap_net_bind_service port { 80, 443 }"
                    progweb = "/usr/local/sbin/webfail.py"

                    cap_fs = { toutes les capacités liées au système de fichiers }

                    pass cap_net_web to <webusers> prog progweb
                    pass log cap_fs to <webusers> prog progweb label "fs web" # autorise et log tous les accès aux fichiers
                    block # bloque tout ce qui n'est pas explicitement autorisé au dessus

                    Bon, si le projet se dessine au final comme ça, il m'intéresse. ;) Là il commencerait à devenir intéressant dans la pratique (pour le debug principalement).

                    PS: Vous ne pouvez pas le savoir… mais il y a un commentaire que j'ai posté il y a plus d'un an sous cette vidéo… :-D

                    • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                      Je pense que on va arriver à se mettre d'accord. Si openbsd n'a pas implémenté le brouillon POSIX, mon travail n'a aucun intérêt dans OpenBSD. Par ailleurs, mon objectif ne consiste pas à filter les syscalls, il existe bien d'autres solutions qui font ce travail parfaitement comme par exemple Linux Extended BPF.

                      Mon objectif est de définir une approche de distribution des privilèges root dans les OSs qui ont implémenté le brouillon POSIX. Je vous donne un exemple en reprennat le syntaxe de votre propre exemple sur pf. Nous avons dans Linux le privilège cap_dac_override qui permet à celui qui le possède de contourner toutes les permissions. Maintenant, quand je donne ce privilège à quelqu'un j'aimerais lui donner ce privilège uniquement pour contourner les permissions sur certains dossiers mais pas tout le système. Ainsi, mon système doit permettre à l'administrateur de préciser les privilèges, les utilisateurs et les ressources sur les quelles ces privilèges seront appliqués. le syntaxe pf ce que je veux faire est le suivant:

                      table { awazan, toto } #
                      cap_dac_override_personal_documents = "cap_dac_override { /home/user/awazan}"
                      progbackup = "/usr/bin/backup_program"

                      pass cap_dac_override_personal_documents to prog progbackup

                      block # bloque tout ce qui n'est pas explicitement autorisé au dessus

                      • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                        Je pense que pour mieux comprendre et répondre à ce que vous voulez faire, il me faudrait l'accès au draft. Malheureusement je n'ai pas de compte sur opengroup.org.

                        J'ai zieuté un peu "Operating System Structures to Support Security and Reliable Software" (1976), j'ai pas eu le courage de lire les 37 pages mais je n'ai pas l'impression que cela reflète parfaitement ce que vous souhaitez faire de nos jours. J'en ai retenu un système un peu compliqué, dont les auteurs sont d'accord pour dire que des options de sécurité dans les compilateurs pourraient faire une partie du job.

                        Du coup, je ne peux me baser que sur les exemples que vous donnez, et qui me semblent trop éloignés de la réalité pour être utiles en pratique. Mais soit, je me demande ce à quoi cela ressemblera à l'avenir, et je vois l'utilité qu'on pourrait en avoir (même si c'est éloigné de l'objectif qui est annoncé).

                        • [^] # Re: Très intéressant, mais moins pratique que pledge

                          Posté par . Évalué à 1 (+0/-0). Dernière modification le 08/09/18 à 14:57.

                          Je pense qu'il faut lire la documentation de Linux sur les capabilities. Sinon vous avez aussi des articles sur Internet qui parlent de ce sujet. Nous donnons plusieurs références dans notre page Github.

                    • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                      Bonjour,

                      pass cap_net_web to prog progweb
                      pass log cap_fs to prog progweb label "fs web" # autorise et log tous les accès aux fichiers
                      block # bloque tout ce qui n'est pas explicitement autorisé au dessus

                      PF utilise une politique (assez nulle ama) de last matching rule, sauf si quick est spécifié. Ces règles là, en bref, ça bloque tout.

                      (je dis ça…)

                      les pixels au peuple !

                • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                  Il semble que OpenBSD n'a pas implémenté POSIX draft 1003.1e dans son kernel. Si cela est vrai, alors OpenBSD adopte le modèle traditionnel d'administration où tous les pouvoirs sont aux mains de l'utilisateur root. Pledge permet d'améliorer la situation mais je me demande du coups comment être sûr que l'utilisateur n'a pas ouvert par exemple le port 81 au lieu de 80 dans OpenBSD?

                  • [^] # Re: Très intéressant, mais moins pratique que pledge

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

                    Seul root a le droit d'ouvrir un port < 1024. Dans la pratique je n'ai jamais, en 15 ans d'administration système, eu besoin d'ouvrir un port < 1024 pour utilisateur. Ce qui est fait en revanche, c'est que root lance un programme qui se sépare en deux pour gérer correctement la séparation de privilèges, avec d'un côté un programme qui gère le réseau et les appels systèmes en tout genre, et un programme qui n'a droit qu'à très peu de choses, avec un pledge qui lui coupe presque tout et est dans une racine séparée.

                    OpenBSD ne part pas du principe qu'on a le droit d'ignorer le code, le projet part au contraire du principe qu'il faut être très vigilent sur le programme qu'on écrit, qu'il faut faire activement des relectures même si on implémente des tas de parades dans le noyau pour contrer des attaques potentielles. Les deux sont complémentaires, et on ne peut pas prétendre gérer la sécurité si on ne fait pas les deux. S'il y a eu si peu de failles sur ce système en plus de 20 ans d'existence, ce n'est pas le fruit du hasard. Les mots clés sont : relecture et sécurité pro-active (séparation de privilèges, pledge, W^X, pageguard, diverses options de compilation…).

                    Si on a un programme dangereux à faire tourner, on peut toujours le mettre dans un chroot et le lancer via un autre utilisateur. On peut aussi s'amuser à lui créer une interface réseau pour qu'il fasse sa tambouille dessus, sous linux il faut voir les netns avec ip. Mais à aucun moment le réflexe est de lui donner tous les droits sur le système, il est contraint, au pire dans un sous-système minimaliste (vraiment minimaliste, un chroot n'a besoin de rien du tout, limite une copie de /etc/resolv.conf et peut-être un ou deux autres fichiers vite-fait).

                    Implémenter de la sécurité pro-active ne doit pas dispenser d'écrire du code en respectant les standards de sécurité. Et si on les respecte, il ne reste finalement que peu d'erreurs à intercepter, et elles resteront difficiles à analyser même avec votre solution. Donc oui c'est un complément, et le commentaire que je vous ai donné plus haut montre en quoi votre projet peut être intéressant (voir l'exemple de syntaxe pf adaptée à votre outil) avant tout pour voir ce qui se passe en historisant les appels système.

                    PS: Bon, mine de rien j'ai passé pas mal de temps à argumenter… donc soit on discute authorship soit je pars finir ma thèse ! :-D

                  • [^] # Re: Très intéressant, mais moins pratique que pledge

                    Posté par . Évalué à 1 (+0/-0). Dernière modification le 07/09/18 à 17:42.

                    Réponse un peu plus directe à votre question : on ne le fait pas. On vérifie que le programme en amont pour vérifier qu'il ouvre bien le port qu'on lui demande, et c'est tout. Un programme va, dans les cas observés et selon mes connaissances, se lancer en ouvrant les ports dont il a besoin puis pledge. S'il n'a pas ouvert les bons ports avant pledge, c'est une erreur de programmation mineure et évidente, et après il ne peut de toutes façons plus ouvrir de port. Si on parle réseau, de toutes manières il y a de fortes chances pour qu'on puisse gérer ça avec pf, même s'il ne fait pas le lien avec le programme ni l'utilisateur qui a lancé le programme.

                    S'il y a une place pour votre projet sur de vrais système, je ne considère pas nécessairement que ce soit lié à 100% à la sécurité, mais surtout pour la surveillance des programmes et leur debug. J'ai peur qu'il soit trop complexe de définir correctement les droits sans être soit trop laxiste, soit trop stricte, la balance est compliquée à obtenir (mais c'est mon avis, je serai ravis d'avoir tort).

                    En revanche, si je me souviens bien, les capacités sont gérées non pas au niveau du programme seul, mais aussi de ses fils. Ça c'est intéressant, toujours pour le debug en analysant ce qui se passe dans un environnement de test par exemple.

  • # Permissions Android

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

    Lorsqu'une application Android souhaite, par exemple, accéder à l'appareil photo du mobile il faut qu'elle demande la permission.
    Pour demander la permission il faut que son développeur ait inclus dans le manifeste de l'application la demande de ladite permission.

    Quelqu'un saurait-il comment est géré dans le noyau ce mécanisme de permission ? Est-ce propre à Android (donc des modifications que Google a apporté à Linux) ou bien ce mécanisme existe-t-il déjà dans Linux ?
    Quelles sont les différences entre la proposition de l'article et les permissions Android ?

    • [^] # Re: Permissions Android

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

      Malheureusement je ne connais pas assez Android pour répondre à votre question.

    • [^] # Re: Permissions Android

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

      De ce que j'en ai compris, sur Android, les permissions ne sont pas géré par le noyau mais par Android. Les applications n'ont pas accès au système (rappel: elles sont en Java), mais à un ensemble d'API (qui elles, appellent les api systèmes). Et une application est dans une sandbox. De ce fait, quand une application fait appelle à une API, Android vérifie que l'application a le droit d'appeler cette API, en se référant aux permissions données par l'utilisateur (que ce dernier a indiqué à l'installation ou au moment de l'appel à la fonctionnalité). Si c'est pas bon, ça échoue.

      Bref, c'est la couche Android qui fait "firewall", pas le noyau.

      • [^] # Re: Permissions Android

        Posté par . Évalué à 2 (+0/-0). Dernière modification le 07/09/18 à 16:05.

        De ce que moi j'ai compris de Android…

        Il y a deux niveaux de permissions à considérer sous Android :
        - les permissions de la couche Android (accès aux API, messages etc.). C'est un système de permission dédié
        - les permissions POSIX, et là c'est bien du classique : chaque appli a son user:group dédié

        Oui, c'est du Java (mais pas que d'ailleurs), mais ça reste un process unique vu du noyau : le JVM est bien instanciée pour chaque appli, et a donc des droits POSIX dédiés.

        Pour illustrer :
        Une appli n'aura jamais le droit de parler directement au périphérique GPS (elle devrait être root, ce n'est évidemment pas le cas), elle doit donc passer par l'API Android (et donc avoir des permissions Android).

        Mais une appli qui écrit dans le répertoire utilisateur (photos, sauvegarde des préférences utilisateurs ou je ne sais quoi) aura le droit d'écriture, sans avoir le droit d'écrire ni de lire dans le répertoire d'une autre appli (permissions Linux).

        • [^] # Re: Permissions Android

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

          (permissions Linux).

          Est-ce que ce sont des permissions unix habituelles ou des ACL ?
          Je vois mal comment on peut gérer finement des permissions type telle appli à un accès RW à tes données, mais telle appli non c'est juste du R, avec le modèle UGO classique.
          Ou alors j'imagine un modèle batard ou l'accès niveau FS est "tout ou rien" niveau R/W et la VM filtre les appels Read et Write ?

          • [^] # Re: Permissions Android

            Posté par . Évalué à 8 (+6/-0). Dernière modification le 08/09/18 à 00:37.

            c'est ce qui m'intéresse le plus en tant qu'utilisateur : une gestion plus fine des "droits" (entre guillemets et en italique pour insister sur le côté "vue utilisateur" et non pas sur les droits unix). Par exemples :

            • que mon navigateur internet n'ai pas accès à mon dossier Documents, mais juste Public et Téléchargements ;
            • que que mon logiciel de visionnage de photos puisse écrire de nouveaux fichiers dans .thumbnails mais pas lire les fichiers qui y sont déjà ;
            • que chacun de mes logiciels puisse écrire dans .config .local .autre mais juste dans leurs dossiers respectifs, sans pouvoir ni lire ni écrire dans ceux des autres

            C'est une partie du point de vue d'Android il me semble …
            Et une partie de la réponse ne se situe pas dans les droits UGO mais dans ceux-ci + une grosse gestion d'uid et de guid côté système + le concept de déclaration de racine et d'isolation (dont l'implémentation pour arriver au résultat peut être diverse : chroot, sandbox selinux, usage des namespaces, utilisation de points de montage bind à la demande, ..)

            Il y a pas mal d'arguments contre ça, d'un point de vue système et kiss, mais il y a aussi pas mal d'arguments pour, et à l'heure où le soucis central c'est l'accès à nos données par des tiers sur le réseau via des apps que j'installe, il est peut être tant de se dire qu'en 2018 il est complètement con que les navigateurs aient accès par défaut aux clefs privées dans .ssh.

    • [^] # Re: Permissions Android

      Posté par . Évalué à 4 (+2/-0). Dernière modification le 09/09/18 à 20:55.

      Android, je sais pas, mais de ce que j’en comprends, iOS fait de l’IPC (xpc en parlance Apple) pour tout/la plupart de ce qui requiert des permissions.
      L’implémentation repose sur des mach messages, et passe donc par le kernel. Ça paraît assez simple pour des trucs genre location etc, pas sûr de comment ça marche pour des services lourds en données, genre photos.

      Bref, l’idée de base c’est que le process demeure 100% sandboxé. L’appli demande les permissions au daemon, qui va rendre, via le window manager, la pop up de confirmation (out of process donc). Une fois confirmé, la communication xpc peut continuer entre les 2.

      L’appli reste donc 100% sandboxée et non privilégiée, ce qui est plutôt cool. Ya toujours le système de root, donc c’est techniquement possible de passer root et faire des choses affreuses au système (mais ça reste difficile à cause de la sandbox).
      Le truc c’est que ça marche uniquement parce que c’est un système mono utilisateur, et donc l’humain est de confiance, c’est les applis qui ne le sont pas, le contexte est donc très différent de ce qui est discuté ici (les applis sont de confiance, mais pas les humains).

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # Super Quoi ? :>

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

    l’administration des systèmes GNU/Linux repose sur l’existence d’un seul utilisateur puissant (appelé super‐utilisateur)

    rumeur persistante issue de l'égo d'un internaute probablement oublié

    "su" pour "substitute user", "sudo" pour "substitute user and do". Pour référence, par exemple, le Jargon Français de Roland TRIQUE : http://jargonf.org/wiki/su - http://jargonf.org/wiki/sudo

    CQFD !

Envoyer un commentaire

Suivre le flux des commentaires

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