SELinux en danger ?

Posté par . Modéré par Mouns.
Tags : aucun
0
8
oct.
2005
Linux
Derrière ce titre un peu racoleur se cache une vérité qui peut faire peur... En effet, "Type Enforcement", développé par Secure Computing pour SELinux, est protégé par un brevet. Type enforcement est la base permettant la séparation des objets, ressources, et privilèges utilisés par SELinux, c'est à dire la pierre angulaire du code.

Il n'y a aucune licence fournie pour l'utilisation de cette technique dans Linux : Secure Computing a simplement mis en ligne un document spécifiant que Secure Computing n'a pas pour l'instant l'intention d'exploiter les droits que lui accorde le brevet de l'utilisation de ce brevet dans SELinux, excepté si ce dernier est utilisé dans des domaines spécifiques (pare-feux et passerelles VPN) et beaucoup moins spécifiques (tout produit qui permet l'authentification et la gestion des autorisation à des applications). L'entreprise peut cependant se rétracter à tout moment, ce document ne constituant pas une licence : elle l'a d'ailleurs déjà fait dans le passé.

L'absence d'une licence officielle sur le brevet qui engagerait Secure Computing ainsi que les restrictions de domaine laissent peser une lourde épée de Damoclès au dessus de cette implémentation de SELinux.

À noter que SELinux est déjà présent et activé par défaut dans la distribution Fedora Core.
SELinux, pour Security-Enhanced Linux, est un LSM (Linux security module), qui permet de définir une politique d'accès MAC (mandatory access control) aux éléments d'un système basé sur Linux. Conçu à l'origine par la NSA, son architecture dissocie l'application de la politique d'accès et sa définition. Il permet notamment de classer les applications d'un système, en différents groupes, avec des niveaux d'accès plus fins. Il permet aussi d'attribuer un niveau de confidentialité pour l'accès à des objets systèmes, comme des descripteurs de fichier.
(source : Wikipédia)

Aller plus loin

  • # patents

    Posté par . Évalué à 9.

    Il faut voir que SELinux est aussi proposé par défaut dans le noyau 2.6.
    Enfin bon, heuresement qu'il y a des alternatives .. :)
    Avis non objectif: http://www.rsbac.org(...)
  • # la base: droits supplémentaires sur les appels systemes

    Posté par . Évalué à 10.

    Le titre est en effet un peu raccoleur. Déjà il y a le fait que les brevets logiciels ne sont pas valables en Europe.
    La base d'outils comme SELinux (ou systrace.org) est de controler des droits d'accès supplémentaires pour les appels systèmes. Ce qui ne semble pas couvert par ce brevet.
    Le Type/Domain enforcement est juste une manière d'agencer ces droits en regroupant les programmes par Domaine et les droits par Type (les programmes appartenant au Domaine1 accèdent aux appels systèmes avec des droits de type Type1 et Type2, par exemple).
    • [^] # Re: la base: droits supplémentaires sur les appels systemes

      Posté par . Évalué à 2.

      Attention quand meme, pour citer, par exemple:

      http://www.gentoo.org/proj/en/hardened/selinux/selinux-sparc64-hand(...)

      "The SELinux policy is primarily composed of type enforcement rules"

      et encore:

      http://www.usenix.org/events/sec03/tech/full_papers/jaeger/jaeger_h(...)

      "the main focus of SELinux policy development has been an extended Type Enforcement (TE) model"

      En fait type enforcement effectivement la methode utilisée pour écrire la plupart des configurations (policy) SELinux.

      Bref, SELinux est SELinux de par TE.

      Quand a systrace, cela ne permet, a ma connaissance (et d'après les messages de l'auteur), uniquement de contrôller les appels systeme (syscalls), sans aucun modèle de sécurité sous-jacent (MAC, RC/RBAC, TE, ..), ce qui est donc légérement different (il ne faut pas tout simplifier)

      http://en.wikipedia.org/wiki/Mandatory_access_control(...)
      http://en.wikipedia.org/wiki/RBAC(...)
      http://rsbac.org/documentation/different_models(...)
      • [^] # Re: la base: droits supplémentaires sur les appels systemes

        Posté par . Évalué à 5.

        Quand a systrace, cela ne permet, a ma connaissance (et d'après les messages de l'auteur), uniquement de contrôller les appels systeme (syscalls), sans aucun modèle de sécurité sous-jacent
        En fait les policies de systrace permettent de spécifier ce que tel programme de tel utilisateur a le droit de faire en matière de syscall. C'est deja pas mal, car cela peut concerner par exemple le login-shell et donc toute une session de cet utilisateur, ou bien encore spécifiquement ses programmes ayant accès à internet et donc exploitables à distance.
        De plus la génération interactive des policies de systrace est plutot sympa.

        Mais RSBAC déja cité donne accès à un grand nombre de modèles peu éloignés de type/domain:
        Several well-known and new security models, e.g. MAC, ACL and RC
        http://rsbac.org/why(...)

        Le controversé LinuxSecurityModule permet à chacun d'implémenter facilement un nouveau modèle sans avoir à faire de patch du noyau. Il permet d'installer ses propres callbacks dans chaque syscall.
      • [^] # Re: la base: droits supplémentaires sur les appels systemes

        Posté par . Évalué à 9.

        Oui systrace est très différent en pratique.

        D'une part sont objectif initial n'est en aucun cas de faire des politiques d' Access Control, à la différence de SELinux (qui est plus pensé sur le modèle des controles d'accès aux systèmes de fichiers/ gestion par uid/gid au sens étendu... - il fait bien plus de choses évidement, je parle de modèle conceptuel).

        Theo de Raadt s'est toujours oposé à l'ajout de solution MAC dans Open, car il considère que ce ne sont pas vraiment des outils de sécurité mais plutot de politique / gestion des users / ... qui complexifient le code et la tache des admins de façon malsaine.

        Systrace est une sorte de "firewall" pour les appels systèmes : on peut autoriser, pour telle appli, tel syscall à être éxecuté, avec tels arguments seulement (on peut utiliser des wilcards) et par tel utilisateur seulement...
        Il y a aussi des "meta" syscalls, qui regroupent des ensembles d'appels systèmes similiaires, comme "native-fsread" pour fopen/fdreopen/lstat/... ex de rules :

        native-bind: sockaddr match "inet-*:6667" then permit, if user != root
        native-fsread: filenamenative-fsread: filename eq "/var/run/*" then permit
        native-setegid: gid eq "70" then permit

        Mais systrace n'ajoute rien à posix en termes de controle d'accès au fs par exemple.

        Son avantage (à mon avis) c'est qu'il est très clair et simple à utiliser (du coup on arrive à faire des polices super précises). Jettez un oeil à un exemple de police systrace, vous verrez comme c'est évident au premier coup d'oeil.

        Son gros désavantage c'est qu'il est moins puissant, moins fin, et encore plus lent que SElinux. Et je ne suis pas sur que la version Linux soit maintenue (la version BSD l'est).

        Pour revenir à SELinux, récement Red Hat a annoncé qu'ils préparent une certification pour être autorisés à fournir du soft à l'armée/au NSA, et qu'à cette fin ils integreront SELinux dans la prochaine RHEL (comme actuellement dans Fedora). Je ne sait pas si c'est lié, mais maintenant SC a un beau moyen de pression.

        Btw je me demande à chaque fois si le fait que RH ai embauché la majorité des developpeurs noyau qui décident n'est pas ce qui a permis à la très tarabiscoté solution LSM/SELinux de s'imposer dans le noyau officiel (devant les solutions alternatives, type grsecurity ou rbac, plus simples et parfois plus complétes, mais moins "corporates" ; plus orientées sécurité et moins orientées "certifications")...
    • [^] # Re: la base: droits supplémentaires sur les appels systemes

      Posté par . Évalué à 5.

      Le titre est en effet un peu raccoleur. Déjà il y a le fait que les brevets logiciels ne sont pas valables en Europe.
      C'est marrant on en parlait dans un journal : https://linuxfr.org/comments/633726.html#633726(...) .

      Et puis il me semble que kernel.org se trouve au US où les brevets sont vraiement valable...
  • # Alternatives

    Posté par . Évalué à 2.

    Je ne suis pas expert sur le sujet (en fait je connais mal GRSec vs SELinux), alors ne lancez pas des pierre!

    Mais GRSecurity (+ peut-être PAX) ne serait il pas une belle alternative?

    http://grsecurity.org(...)
    http://fr.wikipedia.org/wiki/Grsecurity(...)

    Si qqn peut faire une brève description grsec vs selinux, ce serait top!
    • [^] # Re: Alternatives

      Posté par . Évalué à 4.

      • [^] # Re: Alternatives

        Posté par (page perso) . Évalué à 6.

        En ni connaissant rien au sujet mais en lisant ici ou là quelques documentations, on ne comprend pas pourquoi RSBAC n'est pas l'implémentation de référence.

        On a vraiment l'impression que RSBAC n'a que des avantages devant SELinux.

        Si la logique "open source" est suivi, ne devrait'il pas logiquement remplacer SELinux dans le noyau ?
        • [^] # Re: Alternatives

          Posté par . Évalué à 7.

          Parce que mine de rien, la politique reigne partout, je suppose.
          SELinux a été concu par la NSA afin de pouvoir créer un OS certifié sous Linux, ce qu'est entrain de faire Redhat.

          Maintenant si c'est aussi si pour garder le contrôle via differents brevets a resortir le jour ou un autre pays que les USA s'en sert un peu trop, j'en sais rien.

          Le fait que RSBAC soit mieux que SELinux, ben, c'est peut etre comme Postfix vs MySQL, ou des choses comme ca.. moi je suis plutot pour les projets libres fait par des gens comme nous et pas pour des raisons politiques (quoi qu'on en dise le fait est que la NSA a crée tout ca pour faire des OS certifiés et gratos pour les USA, à la base)

          A noter qu'il semblerait (rien d'officiel que je connaisse) que Mandriva utilise uniquement RSBAC et tente de créer une solution similaire pour la France, basée sur RBSAC.. je suppose qu'ils ont de vrai bonnes raisons pour ca..
          • [^] # Re: Alternatives

            Posté par . Évalué à 4.

            Le fait que RSBAC soit mieux que SELinux, ben, c'est peut etre comme Postfix vs MySQL

            Je pense qu'il s'agit plutôt de Postgres vs MySQL...
        • [^] # Re: Alternatives

          Posté par . Évalué à 10.

          Je soulevais cette question plus haut:

          Sachant que SELinux permet de décrocher de beaux contrats auprès du gouvernement americain, que Red Hat est intéréssé par ces contrats, et qu'ils ont vraiment les moyens de faire du lobbying sur le noyau linux et de se payer (si besoin est) une license d'exploitation du brevet ... on peut s'interroger sur la sérénité des choix.

          Je suis assez inquiet de la représentation pas très équilibrée des developpeurs Red Hat (par rapport aux devs d'autres distros) dans le kernel.
          J'ai peur que ça puisse, un jour, déterminer des choix selon des critères commerciaux plutôt que techniques ou éthiques.

          Par exemple: RHEL (avec Suse) est la seule distro à être supportée par Oracle. RH vend beaucoup de support grâce à ça. Si une fonctionalité de sécurité (au hasard, grsecurity) était susceptible de casser le support Oracle (au hasard, si Oracle contenait de sales hacks), il ne serait pas suprenant que RH lance ses devs aux lobbying contre cette fonctionalité. Et je parle d'Oracle, mais c'est aussi bien SAP, DB2, Tivoli etc., bref, tout ce qui fait le fond de commerce de RHEL (et pas seulement sur des questions de sécurité: l'actuel lobbying anti-reiserfs4 doit bien arranger RH contre Suse et Mandriva, non ?).

          Si RH achète une licence d'utilisation du brevet qui touche SELinux -et je ne doute pas qu'ils soient en train de négocier- ils mettront les distributions libres (Debian et dérivés, Slack, Gentoo, Centos ... et même Fedora !) en difficulté, et récuperont sans doute une partie de leurs utilisateurs (ceux qui ont besoin d'être légalement protégés) et de leurs marchés: j'imagine que cette perspective ne doit pas trop les chagriner.

          Ces actions de lobbying (avec vendor lock in en arrière plan) ont été très visibles récement autour du projet Gnome, mais dans ce cas heureusement les concurents (Novell/Suse, Ubuntu) sont assez bien représentés.

          Que Torvalds et Morton soient chez OSDL me semble insuffisant, devant la quantité de core developpers chez RH: cette société à maintenant un pouvoir de veto sur le kernel, la glibc, gcc ...
          • [^] # Re: Alternatives

            Posté par . Évalué à 5.

            C'est vrai que Red Hat a pris une sacree importance dans de nombreux projets cles.
            En meme temps, le support de java n'est arrive que au travers de gcj + classpath. S'il avaient voulu faire du java non libres, ils auraient pu le faire depuis longtemps en demandant a Sun. Bon, il se trouve qu'ils ne sont pas du tout copain.
            Alors c'etait politique ou philosophique? Agir contre Sun, ou ne pas integrer de logiciel non libre? Si c'etait politique, c'est clair qu'un SElinux (intentionnellement) touche par un brevet ne les generait pas trop. Si c'etait philosophique, brevet entraine non libre (pas assez), entraine pas de SElinux.
            Tout de meme, d'apres Daniel Veillard, la tres grande majorite de leur code est libre. J'aidonc une preference pour l'option ethique.

            En tout cas:
            clap clap clap les brevets! clap clap Secure Computing! Et vivement la GPLv3 qui va bien niquer ce comportement totalement immoral et non ethique.

            Je suis pas toujours d'accord avec RMS (quoique, ethiquement parlant, c'est du tout bon), mais la, il devient criant que les brevets sont une vraie epine dans le pied des logiciels libres.

            RMSement votre,

            djano
  • # Je vais peut-être dire une connerie...

    Posté par . Évalué à 6.

    Mais, combien d'autre brevet il y a t-il dans le kernel ? Combien de brevet dans l'interface graphique ?

    Bref, le risque n'existe-t-il pas depuis longtemps de voir une boite se boiter et dire : "Hola, hola, j'ai un brevet sur l'utilisation des grouplou© dans un systeme de fichier spartX (oui oui, j'ai pas d'autre exemple en tête !)" ?
    • [^] # Re: Je vais peut-être dire une connerie...

      Posté par . Évalué à 3.

      Au pire le code litigieux est finalement retiré du noyau Linux. En effet la société possédant grouplou© ne peut pas sanctionner les auteurs des autres parties du noyau. Donc leur code peut continuer à être distribué, mais sans grouplou©.
      • [^] # Re: Je vais peut-être dire une connerie...

        Posté par (page perso) . Évalué à 3.

        > Au pire le code litigieux est finalement retiré du noyau Linux.

        Au vraiment pire, c'est ça plus les dommages et intérêts. Cf. Eolas qui demande quelque chose comme 500 Millions de dollard à MS en plus d'une modification de MSIE pour une histoire de brevets.
        • [^] # Re: Je vais peut-être dire une connerie...

          Posté par . Évalué à 1.

          sans compter les parties a recoder, le travail externe des outils a refaire, les logiques a re-apprendre aux administrateurs.. :(
        • [^] # Re: Je vais peut-être dire une connerie...

          Posté par (page perso) . Évalué à 3.

          Au vraiment pire, c'est ça plus les dommages et intérêts.

          Et à qui ils les demandent les D-I ? Ils lancent une collecte de dons sur la LKML ?

          Ah mais oui suis-je bête, ils ont qu'à les demander à la NSA vu qu'à la base c'était leur idée...
          • [^] # Re: Je vais peut-être dire une connerie...

            Posté par (page perso) . Évalué à 3.

            > Et à qui ils les demandent les D-I ?

            Je suis pas juriste, mais je dirais « au propriétaire du code concerné ». En tous cas, ils demandent ça à la même personne (physique ou morale) que celle à qui ils demandent de supprimer le code en question. Je suppose que les distributeurs de ce code peuvent aussi prendre, vu que RedHat a choisi de ne pas distribuer de lecteur de MP3 pour des histoires de brevets.
            • [^] # Re: Je vais peut-être dire une connerie...

              Posté par . Évalué à 3.

              Je suppose que les distributeurs de ce code peuvent aussi prendre, vu que RedHat a choisi de ne pas distribuer de lecteur de MP3 pour des histoires de brevets.
              Les distributeurs peuvent aussi se décharger sur l'auteur si celui-ci les a sciemment trompé sur la "propriété intellectuelle" du code qu'il a publié.

              En l'occurence l'auteur original de SELinux est bien une agence du gouvernement américain.
  • # paranoïa

    Posté par . Évalué à 3.

    De toute façon, SELinux est pour moi un truc développé par des gens qui ne sont pas vraiment de toute confiance. C'est un morceau de code suspect en plein au milieu du noyau. Et bien malin celui qui ira faire une revue de ce genre de choses...
    • [^] # Re: paranoïa

      Posté par . Évalué à 1.

      De toute façon, SELinux est pour moi un truc développé par des gens qui ne sont pas vraiment de toute confiance.


      La NSA ???
      De confiance ? Vous vous sentez bien ?
      Evidemment que la NSA n'est pas confiance.
      tststs....


      Pierrot
    • [^] # Re: paranoïa

      Posté par . Évalué à 4.

      mouahaha la NSA les grands méchants qui surveillent tout et mettent des backdoors dans tous les softs !

      Ce qui me fait rire dans ce genre de propos c'est pourquoi la NSA mettrait un backdoor/vulnérabilité dans un code qu'elle maintient elle-même (donc si à la suite d'un audit quelque chose de suspect est détecté tout retombe sur elle) alors qu'elle peut très bien avoir des agents infiltrés comme dev dans des projets libres et en mettre partout (kernels, implémentations d'algos de chiffrement, ...) ? Pourquoi mettre en danger son propre pays (pourquoi personne n'auditerait ce code ?) en laissant des faiblesses volontaires (à moins qu'un certificat ou une clé ne soit caché dans le code aussi ;p) ?

      Brad Spengler (dev de grsecurity) a déjà trouvé des vulnérabilités dans systrace, lids et execshield, pourquoi n'en trouverait-il pas dans SELinux s'il y en a ?

      Je prend ton message comme ironique, mais le pire c'est que des gens y croient vraiment ...

      question : tu fais confiance aux routeurs de ton FAI ? :)

Suivre le flux des commentaires

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