patents

la base: droits supplémentaires sur les appels systemes

• [^]Re: la base: droits supplémentaires sur les appels systemes

  Posté par kang () le 08/10/2005 à 16:58. (lien). É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 free2.org (page perso, ) le 08/10/2005 à 21:22. (lien). É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 herodiade () le 08/10/2005 à 22:51. (lien). É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 Matthieu C () le 08/10/2005 à 17:51. (lien). É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

• [^]Re: Alternatives

  Posté par izildur () le 08/10/2005 à 19:25. (lien). Évalué à 4.

  j'ai trouvé ca:
  http://gentoo-wiki.com/Access_Control_Comparison_Table(...)

  • [^]Re: Alternatives

    Posté par Sytoka Modon (page perso, ) le 09/10/2005 à 07:33. (lien). É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 izildur () le 09/10/2005 à 12:24. (lien). É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 Ramoz () le 09/10/2005 à 17:02. (lien). É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 Jean-Luc Henry (page perso, ) le 09/10/2005 à 18:50. (lien). Évalué à 4.

          Ou Postfix vs Qmail

    • [^]Re: Alternatives

      Posté par herodiade () le 09/10/2005 à 13:48. (lien). É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 djano () le 10/10/2005 à 08:18. (lien). É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...

• [^]Re: Je vais peut-être dire une connerie...

  Posté par free2.org (page perso, ) le 08/10/2005 à 21:27. (lien). É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 Matthieu Moy (page perso, ) le 09/10/2005 à 11:00. (lien). É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 izildur () le 09/10/2005 à 12:15. (lien). É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 équi () le 09/10/2005 à 16:51. (lien). É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 Matthieu Moy (page perso, ) le 09/10/2005 à 19:45. (lien). É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 free2.org (page perso, ) le 09/10/2005 à 19:55. (lien). É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

• [^]Re: paranoïa

  Posté par tipic () le 09/10/2005 à 20:04. (lien). É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 voodoo () le 10/10/2005 à 15:54. (lien). É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 ? :)