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
- SELinux and patents (1 clic)
- A 'Statement of Assurance' on SELinux patents (1 clic)
- SSC Statement of assurance (1 clic)
- Type Enforcement (R) (5 clics)
- SELinux (5 clics)
- Critique et alternatives (3 clics)
# patents
Posté par kang . Évalué à 9.
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 free2.org . Évalué à 10.
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 kang . Évalué à 2.
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 . Évalué à 5.
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 . Évalué à 9.
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 M . Évalué à 5.
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 Jean-Luc Henry . Évalué à 2.
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 izildur . Évalué à 4.
http://gentoo-wiki.com/Access_Control_Comparison_Table(...)
[^] # Re: Alternatives
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
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 . Évalué à 7.
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 . Évalué à 4.
Je pense qu'il s'agit plutôt de Postgres vs MySQL...
[^] # Re: Alternatives
Posté par Jean-Luc Henry . Évalué à 4.
[^] # Re: Alternatives
Posté par herodiade . Évalué à 10.
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 . Évalué à 5.
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 Laurent GUEDON . Évalué à 6.
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 free2.org . Évalué à 3.
[^] # Re: Je vais peut-être dire une connerie...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
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 . Évalué à 1.
[^] # Re: Je vais peut-être dire une connerie...
Posté par Thomas Maurin (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 3.
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 mickabouille . Évalué à 3.
[^] # Re: paranoïa
Posté par tipic . Évalué à 1.
La NSA ???
De confiance ? Vous vous sentez bien ?
Evidemment que la NSA n'est pas confiance.
tststs....
Pierrot
[^] # Re: paranoïa
Posté par voodoo . Évalué à 4.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.