Sortie de RSBAC 1.2.5

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
29
sept.
2005
Sécurité
Rule Set Based Access Control (RSBAC) 1.2.5 vient de sortir !

Le noyau 2.6 propose un module de modèles de sécurité qui permet ainsi de s'affranchir du modèle de sécurité classique d'Unix basé sur le triplet (user, group, other). Par exemple, des modèles de sécurité basés sur les ACL (Access Control List), et MAC (Mandatory Access Control) sont déjà disponibles via le module SELinux développé par la NSA (National Security Agency aux Etats Unis).

RSBAC se positionne comme une alternative aux solutions telles que SELinux. De par sa structure, RSBAC permettra d'utiliser les règles et le modèle de sécurité SELinux et GrSecurity dans un futur proche.

Afin de tester la chose, un Live CD basé sur Debian à été concocté, il est disponible sur le site.

Tout test ou commentaire est le bien venu :-) Fonctions principales de RSBAC:

* Extension du noyau Linux Open Source (GPL)
* Indépendant des gouvernements et des grandes compagnies
* Plusieurs modèles de sécurité supportés, connus et approuvés (et certains nouveaux) ex: MAC, ACL et RC
* Contrôle individuel des utilisateurs, processus et accès aux ressources (réseau inclus)
* Gestion des utilisateurs complètement intégrée au noyau
* Combinaison de n'importe quel modèle de sécurité possible
* Écriture de nouveaux modèles aisée via REG
* Scan de virus par accès disque via l'interface Dazuko
* Supporte les derniers noyaux de la série 2.4 et 2.6
* Support PaX (Protection Against eXecution)
* Stable et utilisé en production depuis l'an 2000

Nouvelles fonction apportées par RSBAC 1.2.5:

* Revue complète de toutes les interceptions, avec de nombreux ajouts.
* Héritage des attributs sur les fichiers type "device"
* Journal des adresses IP distances du sujet dans le journal d'accès
* Re-écriture complète de la compilation du paquet "admin-tools"
* Corrige plusieurs bugs et accroît la flexibilité d'utilisation
* Liste complète des changements disponible dans le ChangeLog

Les versions 1.2.x seront dorénavant maintenues pour les noyaux Linux à venir, incluant uniquement les correctifs de bogues.

Les nouvelles fonctions sont déjà en cours d'implémentation dans la série 1.3, voir le TODO.

Aller plus loin

  • # Comparatif

    Posté par  (site web personnel) . Évalué à 8.

    C'est surtout interessant de dire que les developpeurs des projets RSBAC et GRsecurity sont tres critiques face a la solution retenu officiellement dans le noyau Linux.

    Notamment (en anglais):
    http://grsecurity.net/lsm.php(...)
    http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm(...)

    Ils y expliquent pourquoi ils n'utilisent pas les modules de securite de Linux et critiquent la maniere dont ils ont ete implementes : en ignorant les interlocuteurs prealables et en cedant a la facilite de pouvoir implementer SELinux directement.

    D'ailleurs, GRsecurity n'est rien d'autre qu'un fork du noyau.

    • [^] # s/fork/patch, interactif à la systrace.org

      Posté par  . Évalué à 3.

      s/fork/patch
      Je ne vois pas pourquoi GRsec maintiendrait une version séparée des milliers de drivers et autres fonctions du noyau qui n'ont rien à voir avec le LSM.

      Sinon j'aimerais bien savoir si il existe une interface RSBAC interactive pour définir les droits d'accès, à la systrace: http://systrace.org(...)

      • [^] # Re: s/fork/patch, interactif à la systrace.org

        Posté par  (site web personnel) . Évalué à -1.

        S'il-te-plait, renseigne toi avant de me corriger. GRsecurity est bien un fork du noyau, il ne s'en cache pas.

        Tu as acces au noyau grsecurity2 v 2.6 ici:
        http://cvsweb.grsecurity.net/index.cgi/grsecurity226/(...)

        Ca ne veut pas dire qu'ils maintiennent tous les drivers mais qu'ils ont leur branche a eux de developpement et que rien n'est reverse en mainline. C'est bien un fork.
        D'ailleurs, regarde les entetes de fichiers. On peut forker sans avoir a tout modifier.

        • [^] # Re: s/fork/patch, interactif à la systrace.org

          Posté par  . Évalué à 3.

          Un fork du noyau ?
          On sort du sujet initial ; mais à mon avis, lancer un "fork du noyau" est crétin.
          Ca va devenir ingérable d'ici 2 ou 3 ans ; ça va troubler les utilisateurs de "Linux" qui ne sauront plus sur quoi se fonder (si c'est "mieux" mais pas "officiel", que faire ?)

          Un patch aurait été mieux. En plus, un patch peut s'officialiser et s'intégrer au noyau de façon pleine (comme divers File Systems qui étaient, je crois, des patches au début)

          C'est à coup de fork de noyaux que Linux va mourir.

          En tous cas, en lisant que c'est un fork du noyau, je passe de la réaction "ça doit être utile, on va regarder" à la réaction "ça n'a pas d'avenir ; attendons que le noyau s'adapte".

          • [^] # Re: s/fork/patch, interactif à la systrace.org

            Posté par  . Évalué à 6.

            C'est à coup de fork de noyaux que Linux va mourir.
            Si à chaque fois que quelqu'un modifiait un logiciel libre pour en faire sa propre version, on avait peur que ce logiciel meurt... on aurait pas fini d'avoir peur.

            Au final il y a concurence entre les forks et le meilleur gagne, et donc on est tous gagnant.

            PS: dans le cas de GRSec il s'agit bien d'un patch, cf leur site officiel et ma réponse ci-dessous

        • [^] # Re: s/fork/patch, interactif à la systrace.org

          Posté par  . Évalué à 1.

          On peut forker sans avoir a tout modifier.
          Le problème , si on en fait pas ce "fork" en utilisant un système de patch, c'est que les drivers et autres fonctions vont vite devenir de vieilles versions obsolètes.

          Je préfère employer le mot patch dans le cas de GRsec car on peut tout-à-fait patcher un logiciel sans avoir à reverser ce patch dans la version officielle de ce logiciel. Contrairement à ce que tu laisses entendre avec tes définitions de patch et fork.

          Et tu nies l'évidence car la page officielle de dowload du site officiel de GRsec est bien une page pour télécharger les patchs officiels GRsec:
          http://grsecurity.org/download.php(...)

          • [^] # Re: s/fork/patch, interactif à la systrace.org

            Posté par  (site web personnel) . Évalué à -1.

            Cette discussion devient de plus en plus sterile et je ne comprends vraiment pas ton debat semantique sur les mots patch et fork et la maniere dont tu les opposes. Ca a tendance a embrouiller les gens.

            Un patch est simplement un resume des differences entre deux codes sources. Que ces codes sources soient du meme projet ou de projets differents ne change pas le sens de ce mot. Parler du patch -ac d'Alan Cox ou du patch GRsecurity est techniquement la meme chose. Ca ne sert donc a rien, et surtout pas comprendre la philosophie du projet, que de dire que c'est un patch.

            Tu aurais pu ecrire s/fork/code en C/ c'eut ete aussi pertinent.

            Le fork, en revanche, existe bel et bien. Depuis belle lurette, les developpeurs de GRsecurity savent que leur code ne sera pas implemente dans le noyau officiel. Ils ne le proposent d'ailleurs pas sur la lkml. En passant, ca reviendrait a mettre SELinux a la poubelle. Ils developpent, maintiennent et distribuent leur propre noyau, sous le nom "grsecurity". Ils developpent en parallele des mainteneurs de LSM. C'est la definition d'un fork. Ca ne les empeche pas de synchroniser les parties non critiques (comme la plupart des drivers) avec la mainline.

            Et tu nies l'évidence car la page officielle de dowload du site officiel de GRsec est bien une page pour télécharger les patchs officiels GRsec:

            Et ? Je peux tout aussi bien te faire un patch entre Emacs et son fork XEmacs. On ne va pas obliger les gens a telecharger 40Mo de source quand on peut faire un patch de 150Ko, la plupart des distributeurs Linux fournissant deja le code source de Linux. Neanmoins, comme signale plus haut, tu peux tout a fait telecharger l'integrale du projet GRsecurity par CVS.

  • # Différences

    Posté par  . Évalué à 6.

    Sans vouloir faire de troll sur cette question, j'essaye de connaitre les différences notables et les "saymieu" sous-jacent entre GrSec, RSBAC et SELinux.

    Connaissant que GrSec (en terme d'utilisation), j'ai demandé à des utilisateurs RSBAC ou SELinux de me donner leurs points de vues sur la questions ... mais à part une conclusion directe ( aka "[RSBAC|SELinux] saymieu point final" ) je n'ai pas plus d'écho.

    Y'a t'il des utilisateurs RSBAC/SELinux dans la salle ? :-)

    • [^] # Re: Différences

      Posté par  (site web personnel) . Évalué à 3.

      Je ne connais pas toutes les differences fondamentales mais la chose qui me dérange c'est que GRSec a du mal a se maintenir a jour vu le manque de moyens et de temps des developpeurs.

      RSBAC m'a été mentionné plusieurs fois comme une très bonne alternative, je suis en train de la considérer sur des serveurs de tests.

      SELinux ne m'a jamais vraiment enchanté bien que cela soit la solution que tout le monde préconise (tm). Fedora a été la première à l'intégrer et Debian a en projet de faire de même dans Etch.

      Steph

    • [^] # Re: Différences

      Posté par  . Évalué à 5.

      Pour faire très concis,
      RSBAC est capable de controler les appels systèmes.

      C'est à dire que tu peux définir des ROLES pour une application,
      un processus, un binaire (pour séparer les différents états).

      Avec RSBAC tu peux faire un sorte qu'une appli écrite avec les pieds
      qui ne comprends rien à la sécurité tourne sans problème sans jamais
      pouvoir intéragir avec le reste dont il n'a normalement rien à faire.

      Pour donner un peu une image facile à comprendre, c'est comme si il validait chaque ligne d'un strace.

      Definir un role d'application de log qui aurait comme seul droit de pouvoir lire /proc/kmsg et d'ecrire dans /var/log sans pouvoir lire ce
      répertoire ni d'effacer les fichiers que lui même aurait créé, tournant dans un chroot au sens rsbac (rsbac_chroot) qui pourrait être lancer
      par un user sans privilège.

      RSBAC te permet de TOUT controler, par controle il faut comprendre validation; il donnera l'accès seulement parce que tu l'as décidé.

      PS le roles ne sont qu'une partie de ce que tu peux faire mais c'est déjà un concept très intéressant.

      Il me vient une idée pour illustrer un peu mes dires c'est qu'avec RSBAC tu peux créer un automate de ton application.
      Un schéma dans lequel tu controles toutes les possibilités de cette application.

      Accessoirement ca te permet de voir des messages d'erreurs que tu n'aurait jamais vu par ailleurs :p


      Oua(h)la
      :p

  • # SElinux

    Posté par  . Évalué à 3.

    Ce que j'ai bien aimé avec grsec c'est qu'on trouve pas mal de docs pour savoir comment le mettre en oeuvre, par contre c'est vrai que les patchs sont longs à venir (on en est encore au 2.6.11.12).

    J'ai vite abandonné SElinux de part le manque de docs, à part quelques trucs sur leur site, c'était décevant. (En gros, il faut utiliser une distrib adaptée)

  • # ACL sous FreeBSD

    Posté par  (site web personnel) . Évalué à 1.

    Comme il est dit "tout commentaire est bienvenu", en voici un :

    Dans ma boite (~500 personnes), on utilise un serveur samba paramétré relativement simplement, mais avec un filesystem qui utilise des ACL très complexes, ce qui permet de gérer des droits beaucoup plus complexes que ce que sait (peu) faire samba.

    Mais on fait ça depuis plus de deux ans sous FreeBSD...

    http://ezine.daemonnews.org/200310/acl.html(...)

Suivre le flux des commentaires

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