Pourquoi une option ?

• [^]Re: Pourquoi une option ?

  Posté par patrick_g (page perso, ) le 15/11/2007 à 17:42. (lien). Évalué à 2.

  >>> pourquoi la branche grsec2 + PaX n' est pas intégrée par défaut
  
  Parce qu'elle refuse de s'intégrer !
  Le mécanisme de sécurité de Linux se base sur LSM et Grsecurity refuse d'utiliser LSM.

  • [^]Re: Pourquoi une option ?

    Posté par Éric JACQUOT (Jabber id, page perso, ) le 15/11/2007 à 17:49. (lien). Évalué à 5.

    Hum je vais reformuler ma question alors...
    
    Pourquoi le kernel par defaut et donc le modele LSM est il si permissif et n'intègre pas une protection suffisante?
    
    Peut etre as-tu quelques liens à me proposer afin quand meme que j'en sache plus à ce propos ?

    • [^]Re: Pourquoi une option ?

      Posté par Gabriel Linder () le 16/11/2007 à 11:37. (lien). Évalué à 2.

      Les auteurs de grsecurity ont déjà détaillé pourquoi ils ne veulent pas utiliser LSM ici : http://www.grsecurity.net/lsm.php
      
      Certains griefs semblent rejoindre l'affaire staircase/cfs, mais bon, ne suivant que de loin le développement du kernel, je m'abstiendrais de commenter :)

      • [^]Re: Pourquoi une option ?

        Posté par reno () le 16/11/2007 à 16:49. (lien). Évalué à 2.

        >Certains griefs semblent rejoindre l'affaire staircase/cfs
        
        Pas tout a fait d'accord dans le sens ou si LSM ne leur convient pas, c'est a eux de le patcher pour qu'il soit utilisable a la fois par SELinux et par eux..

      • [^]Re: Pourquoi une option ?

        Posté par Éric JACQUOT (Jabber id, page perso, ) le 17/11/2007 à 11:33. (lien). Évalué à 1.

        Merci beaucoup pour ce lien qui m'a permit d'éclaircir certaines zones d'ombre.

• [^]Re: Pourquoi une option ?

  Posté par IsNotGood () le 15/11/2007 à 17:58. (lien). Évalué à 2.

  > Mais trouvez vous normal d'être obligé de patcher votre noyau pour renforcer la securité...
  
  SeLinux est en standard.
  
  > Pourquoi ce qui s'applique aux BSD ne fait figure que d'option sous Linux ?
  
  Linux n'est qu'un noyau.
  Certaine distribution renforce la sécurité.
  Pour exemple pour Fedora/RH. il y a tout un tas de truc auquel je ne comprend pas grand chose et qui est parfois upstream :
  * Default requires signed updates
  * NX emulation using segment limits by default
  * Support for Position Independent Executables (PIE)
  * ASLR for Stack/mmap by default
  * ASLR for vDSO (if vDSO enabled)
  * Restricted access to kernel memory by default
  * NX by default for supported processors/kernels
  * Support for SELinux
  * SELinux default enabled with targetted policies
  * glibc heap/memory checks by default
  * Support for FORTIFY_SOURCE, used on selected packages
  * All packages compiled using FORTIFY_SOURCE
  * Support for ELF Data Hardening
  * All packages compiled with stack smashing protection
  * Pointer encryption
  Vous trouverez des pointeurs vers plus d'info ici :
  http://www.awe.com/mark/blog/200701041544.html
  
  En passant, car ce n'est pas indiqué dans cette liste, les noyaux Fedora/RH on un contrôle de signature (gpg) lors du chargement des modules. Présent dans Fedora mais peu (voire pas) utilisé pour Fedora.

  • [^]Re: Pourquoi une option ?

    Posté par Éric JACQUOT (Jabber id, page perso, ) le 15/11/2007 à 18:23. (lien). Évalué à 1.

    Merci pour le lien... Il y a bien longtemps que je ne suivais plus l'actualité de Redhat (bien qu'appreciant énormément leurs contributions) et j'ai été agréablement surpris même si je ne suis pas trop partisan du contexte selinux (à tord peut être). L'intégration par défaut (si c'est bien le cas) de PIE/SSP est une réelle avancée je pense au niveau des executions.
    
    Mais je parlais dans le sens général d'une installation par défaut d'un utilisateur standard. Les noyaux ici et là que j'ai trouvé sur bon nombre de distributions n'intègre pas ces contextes, et, lorsqu'il l'intègre pour certaines, la chaine de compilation est imparfaite (d'après ce que j'ai pu en voir mais j avoue que ca commence à dater et que si alors je n'avais pas rencontré alors la branche gentoo Hardened, je serais depuis longtemps sous BSD). Je crois que je vais creuser un peu le sujet et faire à nouveau le tour des distributions... Je te remercie de ta réponse :)

    • [^]Re: Pourquoi une option ?

      Posté par Alexis P. (page perso, ) le 15/11/2007 à 18:58. (lien). Évalué à 4.

      Bonsoir,
      
      à mon avis (de non expert, je note bien), je trouve normal la non-adoption de ces mécanismes de sécurité par défaut dans la plupart des distributions. Si on regarde bien, les configurations par défaut (je parle du noyau là) sont assez génériques et cherchent à répondre à un grand panel de besoins différents. Mon impression jusqu'à présent est que la politique est la suivante : "on donne un noyau qui marche correctement, avec une majorité de configurations (matérielles), sans trop de compromis d'un point de vue performances".
      
      Si on était amené à faire un sondage auprès des utilisateurs linux, je pense que l'on serait surpris de voir un grand pourcentage de personnes travaillant avec le noyau "basique" proposé par leur distribution favorite, et ce malgré le fait que bon nombre des utilisateurs linux ont souvent un certain bagage informatique qui leur permettrait de se lancer dans une recompilation du noyau.
      
      Il faut rajouter à ça qu'une simple activation de SELinux ne suffit pas. Il faut chercher à comprendre ce que propose ce mécanisme et comment le configurer correctement, ce qui n'est ni à la portée de tous, ni jugé nécessaire par la majorité des utilisateurs Linux. Ainsi, on risquerait fort de donner une fausse impression de sécurité en posant une configuration "générique" de SELinux par défaut, ce qui est encore plus dangereux que ne rien mettre du tout à mon avis.
      
      Donc pour répondre à ta question, je pense que c'est un choix réfléchi que de ne pas activer ces options de sécurité par défaut. Comme pour toute chose dans les distributions Linux (celles que je connais du moins), on laisse le choix à l'administrateur de faire ce qu'il veut avec sa machine. S'il est suffisament compétent pour activer et paramétrer SELinux, il le fera de lui-même, et bien mieux que toute configuration préfabriquée.

      • [^]Re: Pourquoi une option ?

        Posté par fmaz fmaz () le 15/11/2007 à 19:21. (lien). Évalué à 3.

        Il y a deux types de sécurité mentionné ici:
        1. les aspects « visible » côté utilisateurs (SE-linux) ;
        2. les aspects « invisibles ».
        
        Il est clair que l'aspect SE-linux demande à l'utilisateur de s'y plonger et je comprend que les distributions ne l'activement pas par défaut.
        
        En revanche, pour ce qui est des aspects invisibles, (chroot renforcé, protection de la pile, cacher les process...) je ne vois pas en quoi cela peut géner les utilisateurs ou même les distributions. Il est cependant évident que cette sécurité à un coût en terme de performance et les développeurs noyaux semblent considérer que perdre 5% en vitesse est inacceptable même si la sécurité du noyau s'en trouve nettement renforcée. C'est question de politique.

        • [^]Re: Pourquoi une option ?

          Posté par IsNotGood () le 15/11/2007 à 19:43. (lien). Évalué à 0.

          > les développeurs noyaux semblent considérer que perdre 5% en vitesse est inacceptable même si la sécurité du noyau s'en trouve nettement renforcée.
          
          Oui. Mais Selinux ce n'est pas 5 % de perte en performance (ni 7 % comme le dit (ou l'a dit) Novell).
          Dans quelques scénarios très spécifiques on peut monter à 3 % (cas où on accède à 10 000 fichiers différents par seconde et où SeLinux doit contrôler chaque accès). Généralement on ne remarque rien de rien. Il y a eu un bench entre Ubuntu et Fedora pour les jeux. La différence : 0,00000.

        • [^]Re: Pourquoi une option ?

          Posté par Éric JACQUOT (Jabber id, page perso, ) le 17/11/2007 à 11:39. (lien). Évalué à 1.

          C'est en effet surtout des aspects invisibles dont je parlais. Je prefèrerais un noyau renforcé par défaut au détriment de la performance globale qui reste sommes toutes acceptable. Mais ce n'est que mon humble avis et n'ai aucun pouvoir de décision à ce sujet. J'en resterai donc à coller des rustines...

      • [^]Re: Pourquoi une option ?

        Posté par IsNotGood () le 15/11/2007 à 19:38. (lien). Évalué à 1.

        > Si on était amené à faire un sondage auprès des utilisateurs linux, je pense que l'on serait surpris de voir un grand pourcentage de personnes travaillant avec le noyau "basique" proposé par leur distribution favorite,
        
        Inversement, beaucoup utilise le noyau/glibc "full feature" au niveau sécurité livré par la distribution sans s'en préoccuper. C'est le cas de Fedora par exemple.
        
        > Il faut rajouter à ça qu'une simple activation de SELinux ne suffit pas.
        
        Ça dépend comme est intégré SeLinux. Un noyau SeLinux sans règle de sécurité SeLinux est sans intérêt.
        
        > Il faut chercher à comprendre ce que propose ce mécanisme et comment le configurer correctement
        
        Ça dépend. Pour Fedora, dans la majorité des cas tu ne te soucis pas de ça et c'est déjà configuré. D'autres (des spécialistes) configurent Selinux pour toi comme les permissions de fichier sont déjà configurées dans toutes les distributions par exemple.
        
        > ce qui n'est ni à la portée de tous
        
        Effectivement.
        
        > Ainsi, on risquerait fort de donner une fausse impression de sécurité en posant une configuration "générique" de SELinux par défaut, ce qui est encore plus dangereux que ne rien mettre du tout à mon avis.
        
        Remarque très pertinente.
        La sécurité ne se résume à un bouton sur on ou off.
        Mais je te conseille, si tu as le temps, de regarder Fedora. SeLinux y est intégré et le travail ne c'est pas limité à configurer une option du noyau.
        
        > S'il est suffisament compétent pour activer et paramétrer SELinux, il le fera de lui-même, et bien mieux que toute configuration préfabriquée.
        
        J'en doute.
        SeLinux (ses règles de sécurité) est un travail énorme (des années). Je ne crois pas d'un administrateur s'improvise expert Selinux du jours au lendemain.
        
        Quelques liens pour voir en surface le travail réalisé par Fedora/RH :
        http://www.redhatmagazine.com/2007/05/04/whats-new-in-selinu(...)
        http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guid(...)

    • [^]Re: Pourquoi une option ?

      Posté par IsNotGood () le 15/11/2007 à 19:24. (lien). Évalué à 1.

      > L'intégration par défaut (si c'est bien le cas)
      
      C'est le cas.
      
      > Mais je parlais dans le sens général d'une installation par défaut d'un utilisateur standard.
      
      Peut-être que je t'ai mal compris. Mais tous les trucs précédents sont activés par défaut (même SeLinux (dans un mode qui est presque strict)). Donc tu installes une Fedora ou une RHEL (ou CentOS, etc), et voilà.
      C'est un démaine où Fedora est en pointe :
      http://fedoraproject.org/wiki/Security/Features
      Et tu as raison de le dire, il ne sagit uniquement d'appliquer quelques patch pour dire "on a ça", mais il faut que ça soit activé et utilisable dans la majorité des configurations. C'est le cas.
      C'est un énorme travail. En passant, F8 a la fonctionnalité "compte visiteur" par défaut (grace à SeLinux) :
      http://danwalsh.livejournal.com/13376.html
      C'est un bon début.

      • [^]Re: Pourquoi une option ?

        Posté par herodiade () le 15/11/2007 à 21:52. (lien). Évalué à 2.

        > Donc tu installes une Fedora ou une RHEL (ou CentOS, etc), et voilà.
        
        Heu, ça dépend de quoi on parle.
        S'il s'agit du desktop, où l'ensemble des logiciels fournis par le distributeur suffisent généralement à l'utilisateur, tout à fait (et pour les logiciels non fournis par la distribution, donc sans règles SELinux, on sera tolérant en considérant que les desktop est généralement moins critique que les serveur).
        
        Si on parle d'environnement serveur, où la sécurité est plus critique, c'est différent. Mis à part les serveurs d'infrastructure (mail, dns), je n'ai jamais administré des serveurs qui fassent tourner exclusivement des logiciels fournis par ma distribution. Sur mes serveurs web par exemple : certes j'utilise les apaches qu'on m'a fournis, et leurs modules. Mais il font tourner une foultitude d'application php, python, perl (cgis, applications métiers, devs maison, ...), des bloatwares en java, ... qui sont les "vrais" fonctionnalités offertes par le serveur. Vos sites web et vos applis j2ee sont fournis par Red Hat ?
        
        Ainsi les applications critiques exposés au réseau ne seront finement protégés qu'à condition que l'admin écrive ou affine lui-même ses règles SELinux. Et là, la complexité est un handicap (pour revenir sur le troll de l'autre journal).

        • [^]Re: Pourquoi une option ?

          Posté par IsNotGood () le 16/11/2007 à 01:46. (lien). Évalué à 4.

          Si tu veux dire qu'en général il vaut mieux un truc personnalisé aux petits oignons (s'il est effectivement bien fait) qu'un truc généraliste, ben oui.
          
          > S'il s'agit du desktop, où l'ensemble des logiciels fournis par le distributeur suffisent généralement à l'utilisateur, tout à fait (et pour les logiciels non fournis par la distribution, donc sans règles SELinux, on sera tolérant en considérant que les desktop est généralement moins critique que les serveur).
          
          SeLinux débute pour le desktop. Mais les possibilités sont énormes. Par exemple si un utilisateur lance un programme dans son $HOME, on peut faire que ce programme (qui a été downloadé sur un signe warez) ne puisse lire .thunderbird, etc...
          
          A l'avenir (car SeLinux débute dans le domaine du desktop), les paquets rpm/deb qui sont installés et ne sont pas signés par une source de confiance pourront avoir des privilèges limités (interditions de lire/écrire/supprimer des fichiers que le programme n'a pas créé, etc). Notons qu'un "bête" rpm est un problème puisqu'il s'installe avec les droits root.
          [admin@one rsync]$ rpm -q --scripts firefox
          postinstall scriptlet (using /bin/sh):
          update-desktop-database /usr/share/applications
          preuninstall scriptlet (using /bin/sh):
          # is it a final removal?
          if [ $1 -eq 0 ]; then
          /bin/rm -rf /usr/lib/firefox-2.0.0.9/components
          /bin/rm -rf /usr/lib/firefox-2.0.0.9/extensions
          fi
          postuninstall scriptlet (using /bin/sh):
          update-desktop-database /usr/share/applications
          Le "rm -rf" pourrait être un "rm -rf /", il marcherait très bien.
          
          Donc dans les scripts d'installation tu peux faire tout et n'importe quoi et sous le compte root. Avec SeLinux tu peux gérer ce type de problème. Problème qui se posera à l'avenir.
          
          > Ainsi les applications critiques exposés au réseau ne seront finement protégés qu'à condition que l'admin écrive ou affine lui-même ses règles SELinux.
          
          Le httpd de Fedora avec SeLinux n'a pas le droit de lire /etc (sauf /etc/httpd et quelques bricoles) ni les fichiers dans /tmp (sauf ceux créés par apache).
          
          Il y a plein de "petites choses" dans ce gout. Et tu as ça par défaut !
          Tu as ça aussi si l'administrateur à fait des conneries (par exemple un malheureux chmod -R 777 /etc). Si un utilisateur à fait chmod -R 777 ~, ben apache (ou un script d'apache) ne pourra pas y lire.
          Si tu utilises mod_user (avec ou sans suexec) d'apache ça veut alors dire que $HOME/public_html est accessible. Et donc $HOME. Et donc tous les fichiers à l'intérieur dès que l'utilisateur fait un oubli. SeLinux gère ça. apache ne peut lire et écrire que dans $HOME/public_html quelque soit les conneries de l'utilisateur.
          
          Il y a des tonnes de serveur prétendument "finenement protégé" qui ne sont pas au niveau de ce qui est fait par SeLinux sous Fedora par défaut. Par défaut sans que tu te prennes la tête. Et l'expertise que tu as n'est pas d'un administrateur qui a fait ça à l'arrache car il est sous pression, mais par des experts.
          
          > Et là, la complexité est un handicap
          
          La complexité est toujours un handicap/problème. Mais es-ce Selinux qui est complexe ou la sécurité qui est complexe ?
          Avec chroot, les droits DAC, aussi ACL, des programmes bien sélectionnés et audités, etc et un admistrateur compétent tu peux avoir un système très sûr. Aucun doute sur ça. Pour ces cas on n'a pratiquement pas besoin de SeLinux. Ces cas sont finalement très limité.
          
          Par contre dans pleins pleins d'autre cas, SeLinux est un atout. Ce n'est pas un atout qui ajoute forcément de la compléxité. J'ai installé bugzilla et awstats, il y a déjà des règles SeLinux, j'ai rien à faire. Plus simple que ça tu meurs.
          
          Pour les cas spécifiques ?
          Ben il y aura du boulot. Oui. Mais au lieux de te prendre la tête pour mod_user, pour bugzilla, pour awstats, etc, ben tu ne te prends la tête que pour les choses très spécifiques.
          Il y a une communauté SeLinux très dynamique, tu trouveras de l'aide sans problème. SeLinux est aussi l'outil qui répond à une très vaste palette de problème (bien au-delà de ce que proposer le modèle DAC, ACL, chroot, etc). Donc au-lieu de te demander qu'elle solution il te faut dans les 10 000 addons sécurité, il te suffit de connaitre SeLinux. Ça simplifie grandement. Donc la complexité de SeLinux est très relative. D'autant plus qu'on a de plus en plus d'outil de haut niveau pour faire ses propres règles ou pour faire un audit rigoureux des règles (atout énorme de SeLinux).
          
          SeLinux te permet aussi d'exprimer ton besoin (domaine, object, attribut, etc) et celà aussi ça simplifie la vie lorsque la situation est complexe.

        • [^]Re: Pourquoi une option ?

          Posté par IsNotGood () le 16/11/2007 à 02:37. (lien). Évalué à 1.

          > (pour revenir sur le troll de l'autre journal).
          
          En passant, le bug dans selinux-policy-targeted pour bugzilla a été corrigé. C'est l'affaire de deux ou trois jours pour que ça arrive en mise à jours officiel.
          
          Plus généralement.
          
          On est ici, pour beaucoup, amoureux d'Unix/Linux. C'est astucieux et clean. On s'est bien pris la tête pour comprendre comme ça marche sous le capot et ça nous a été très profitable.
          Notre "amour" fait qu'on pense Unix et qu'on est rétissant à d'autres solutions. Souvent à juste titre. Mais parfois on est rétissant à d'autres solutions car elles demandent de se remettrent en cause.
          On ne le devrait pas toujours. Par exemple OLPC est un Linux, son modèle de sécurité est complètement différent d'un Unix (OLPC utilise aussi SeLinux :-)).
          
          Il n'est pas question de dire que SeLinux est indispensable. Telque le conçois Fedora par exemple, un système doit rester sûr sans SeLinux (au moins autant que n'importe quel système sans SeLinux).
          
          M'enfin, il est peut-être temps d'aller plus loins que le modèle Unix classique. Si on a un linux pour les masses, on ne va pas demander à tous les utilisateurs d'être un expert Unix ou d'avoir de bons fondamentaux en Unix. Si Linux devient le système le plus utilisé, il y aura plein programmes tous plus flashy les uns que les autres à downloader. Sous Windows ce sont souvent des spyware/etc et il faut un anti-virus. Si on veut répondre à ce problème qui se posera, il faut aller plus loins que le modèle Unix classique.
          Bien des évolutions se sont faites avec des résistances. Bien des distributions on mis des mois (pour ne pas dire années) pour passer à UTF ou pam. De nombreux utilisateurs préféraient s'ajouter au groupe "sound" que de laisser pam_console s'occuper de ça (maintenant c'est ConsoleKit l'avenir (c'est dans déjà utilisé par F8)).
          
          Rester cramponné à nos habitudes/traditions n'est pas toujours bon. D'autant plus que SeLinux ne diminue jamais la sécurité ! Il n'autorise jamais ce que Linux sans SeLInux refuserait.
          
          Es-ce que l'avenir sera SeLinux ?
          J'en sais rien. Mais j'ai du mal à croire que le modèle actuel Unix sera satisfaisant à l'avenir.
          
          
          
          Pour le fun. J'ai Firefox qui a planté il y a 2 minutes. Il a déclenché SeLinux. Comme il y a audit et setroubleshooting, j'ai une applet qui clignote. Je clique, et j'ai un diagnostique (tout n'est pas traduit encore) :
          

          Résumé
          SELinux empêche /usr/lib/firefox-2.0.0.9/firefox-bin de changer un segment de mémoire inscriptible en segment exécutable.
          
          Description détaillée
          The /usr/lib/firefox-2.0.0.9/firefox-bin application attempted to change the access protection of memory (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests web page [ http://people.redhat.com/drepper/selinux-mem.html ] explains how to remove this requirement. If /usr/lib/firefox-2.0.0.9/firefox-bin does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a bug report [ https://bugzilla.redhat.com/enter_bug.cgi ] against this package.
          
          Autoriser l'accès
          If you trust /usr/lib/firefox-2.0.0.9/firefox-bin to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t /usr/lib/firefox-2.0.0.9/firefox-bin". You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t unconfined_execmem_exec_t /usr/lib/firefox-2.0.0.9/firefox-bin"
          
          La commande suivante autorisera cet accès :chcon -t unconfined_execmem_exec_t /usr/lib/firefox-2.0.0.9/firefox-bin

          
          
          Il faudrait que l'utilisateur puisse modifier des règles pour les programme qu'il lance lui-même sans passer par root (l'utilisateur à toujours le droit de faire des connerie si il insiste). C'est prévu à moyen terme par SeLinux.

• [^]Re: Pourquoi une option ?

  Posté par herodiade () le 15/11/2007 à 21:29. (lien). Évalué à 9.

  > Chroot renforcé car trop permissif par defaut (en gros qui laisse s'échapper les occupants)
  
  Vraisemblablement pour ne pas casser le comportement standard de chroot(2), lequel est défini précisément par POSIX.1-2001.
  
  En l'occurrence, les "problèmes" de chroot visés par grsecurity, ce n'est pas qu'il "laisse s'échapper les occupants", mais qu'il n'isole un processus du reste qu'au niveau du système de fichier, et c'est tout (les IPC fonctionnement normalement, les fd hérités restent ouverts, ...). Mais c'est ce pour quoi il a été conçu, on n'a pas menti sur la marchandise.
  
  Chroot n'était pas prévu pour être utilisé comme un mécanisme de sécurité (cf. [http://lwn.net/Articles/252794/]), encore moins comme mécanisme d'isolation totale (à part pour le système de fichier). Des solutions parallèles sont cependant en cours de développement et intégration dans Linux (autour de la virtualisation et des espaces de nommages multiples et séparés pour les processus, par ex.) ; elles ont le mérite de présenter une architecture d'ensemble et cohérente, et de ne pas casser un appel système standard, existant et déjà largement utilisé par des milliers de logiciels.
  
  > Cacher les process du noyau
  
  C'est plutôt "cacher certains processus à d'autres processus". Tel que proposé par grsecurity, ce n'est pas une chose très simple (ou très saine) à intégrer dans le desktop de monsieur tout le monde. Là encore, il faut veiller à ne pas casser les standards ou l'existant. Et là encore, la virtualisation et la ségrégation de plusieurs espaces de nommages pour les processus (enfin pour le moment, seulement les pids) est une solution plus générale et en cours d'adoption.
  
  > Logs beaucoup plus 'verbose' sur les actions des users
  
  Là je ne sait pas trop de quoi tu parle. L'accounting BSD ne remplis pas cette fonction ?
  
  > Protection de la pile
  
  Si mes souvenirs sont bons, le patchset grsecurity+pax s'était vu rejeté, lorsqu'ils ont demandé l'intégration dans le noyau, notamment parce que les mécanismes de protection de pax divisaient par deux l'espace mémoire adressable par un processus donné, merci la belle régression (je dit ça de mémoire hein, c'est peut être "divisaient en quatre" ou quelque chose similaire, mais c'était bien un problème de ce type). Ce qui casse le fonctionnement d'un paquet d'applis en situation "enterprise", notamment celles qui font vendre du redhat/oracle.
  
  Ce n'est pas la seule raison du refus, je me souvient que d'autres problèmes sans rapport direct avec la protection de la pile ont été soulevés sur lkml à l'époque (non utilisation de LSM, développeur principal qui refuse l'intégration d'une partie de son patchset parce que "la sécu c'est tout ou rien", et qui se montre odieux et borné comme seuls les dévs sécu noyau savent l'être (à la hauteur des devs SELinux ou de Theo de Raadt), ...).

  • [^]Re: Pourquoi une option ?

    Posté par IsNotGood () le 15/11/2007 à 21:42. (lien). Évalué à 0.

    > se montre odieux et borné comme seuls les dévs sécu noyau savent l'être (à la hauteur des devs SELinux ou de Theo de Raadt), ...).
    
    Les devs SeLinux sont "odieux" envers les fausses solutions (type AppArmor). Ils ne sont pas odieux vis-à-vis de ce qui est techniquement bien conçu (par exemple smack).
    Et s'ils étaient aussi odieux que tu le dis, aussi odieux que Theo par exemple, SeLinux ne serait pas upstream.

  • [^]Re: Pourquoi une option ?

    Posté par Gabriel Linder () le 16/11/2007 à 11:33. (lien). Évalué à 2.

    PaX divise bien la mémoire en deux oui (1.5G processus au lieu de 3G), mais d'après les développeurs même çà peut se changer facilement. Maintenant je ne sais pas si çà a été modifié récemment ou pas.

  • [^]Re: Pourquoi une option ?

    Posté par Éric JACQUOT (Jabber id, page perso, ) le 17/11/2007 à 11:56. (lien). Évalué à 1.

    >> Logs beaucoup plus 'verbose' sur les actions des users
    >
    >Là je ne sait pas trop de quoi tu parle. L'accounting BSD ne remplis pas cette fonction ?
    
    Je parlais surtout de la fonction d'audit de grsec qui est plus que 'verbose'. Logs des actions (chdir, reseau...)

• [^]Re: Pourquoi une option ?

  Posté par reno () le 16/11/2007 à 05:37. (lien). Évalué à 4.

  >>- Chroot renforcé car trop permissif par defaut (en gros qui laisse s'échapper les occupants)<<
  
  Pour moi, chroot devrait être encore plus permissif et fournir un moyen 'normal' d'échapper au chroot: c'est un outil de gestion de configuration pas de sécurité et dans la gestion de configuration il est parfois utile de sortir du chroot.
  
  Pour un outil de sécurité il faudrait soit une option supplémentaire, soit un appel système différent.

  • [^]Re: Pourquoi une option ?

    Posté par Éric JACQUOT (Jabber id, page perso, ) le 17/11/2007 à 11:51. (lien). Évalué à 1.

    Option supplémentaire, pourquoi pas...
    
    J'avoue que j'ai cette vieille habitude de chrooter mes services. Dans ce cadre, je ne peut me permettre de laisser un individu qui exploitera une faille naviguer sur l'arborescence complète et compromettre les autres services en s'échappant avec une facilité déconcertante...
    
    Je n'utilise pas chroot comme seule et unique solution de sécurité, mais cela me permet d'apporter une protection supplémentaire à mon système. Peut-être est-ce une erreur, je ne suis pas non plus un expert en sécurité, et d'autres solutions sont peut être plus viables et performantes. C'est pourquoi je m' intéresse au sujet et que j'étudierai avec soin les solutions et suggestions qui me seront transmises...

    • [^]Re: Pourquoi une option ?

      Posté par Gabriel Linder () le 18/11/2007 à 12:16. (lien). Évalué à 2.

      J'ai déjà examiné ce problème, et j'ai trouvé ceci : http://linux-vserver.org/ C'est une sorte de chroot amélioré et ne portant pas que sur le système de fichiers (il isole également les processus et interfaces réseaux, en gros çà équivaut aux jails des *BSD). Ils proposent également grsecurity en option, pour bénéficier des protections supplémentaires de ce dernier.
      
      Ah et mon conseil du jour : surtout n'installe pas dietlibc dans /usr/local, sinon tu risques d'avoir des erreurs de compilation inexplicables :)

      • [^]Re: Pourquoi une option ?

        Posté par Éric JACQUOT (Jabber id, page perso, ) le 18/11/2007 à 14:33. (lien). Évalué à 1.

        Je connaissais déjà un peu vserver de nom qui est une solution que je prefèrerais dans tous les cas à Xen que je trouve très lourd (mais ce n'est que mon humble avis).
        
        Je t'avoue ne pas utiliser le package jail qui intègre beaucoup trop de commandes par défaut à mon gout et j'ai toujours fabriqué mes jails à la main sur une base Linux/Grsec (j avoue ne pas trop adhérer à du SELinux dans l'optique générale).
        
        Quelle est alors la différence notable par rapport à l'utilisation de vserver ?
        
        
        Bien à toi,
        Éric

[+] L'ASLR ne sert à rien

• [^]Re: L'ASLR ne sert à rien

  Posté par miod () le 16/11/2007 à 08:11. (lien). Évalué à 4.

  Le problème, c'est que le programmeur est humain et donc qu'il commet des erreurs, même s'il est doué.
  
  Ce genre de protection sert essentiellement à sauver la couenne des gens.
  
  Dans un monde meilleur, elles seraient totalement inutiles. Mais malheureusement, le monde étant ce qu'il est, elles sont nécessaires.

  • [+] [^]Re: L'ASLR ne sert à rien

    Posté par loufoque () le 16/11/2007 à 15:31. (lien). Évalué à -4.

    Le programmeur commet des erreurs parce qu'il n'utilise pas des langages ou des idiomes de programmation sûrs.
    
    De toute façon, cela ne compromet en rien le système.

• [^]Re: L'ASLR ne sert à rien

  Posté par neologix (page perso, ) le 17/11/2007 à 17:23. (lien). Évalué à 1.

  ASLR n'est pas très utile.
  Déjà, contrairement à ce qui est écrit, il ne rend aléatoire que les adresses dans la pile, et pas le tas (ils ont dû confondre avec les adresses renovoyées pa mmap() quisont, elles, aléatoires). On le voit dans l'article:
  
  
  

  
  $ cat /proc/3027/maps
  (...)
  0804a000-0806b000 rw-p 0804a000 00:00 0 [heap]
  b7da3000-b7da4000 rw-p b7da3000 00:00 0
  b7da4000-b7ed2000 r-xp 00000000 03:04 345236 /lib/tls/libc-2.3.6.so
  b7ed2000-b7ed7000 r--p 0012e000 03:04 345236 /lib/tls/libc-2.3.6.so
  b7ed7000-b7eda000 rw-p 00133000 03:04 345236 /lib/tls/libc-2.3.6.so
  b7eda000-b7edc000 rw-p b7eda000 00:00 0
  b7ef5000-b7ef8000 rw-p b7ef5000 00:00 0
  b7ef8000-b7f0d000 r-xp 00000000 03:04 2032253 /lib/ld-2.3.6.so
  b7f0d000-b7f0f000 rw-p 00015000 03:04 2032253 /lib/ld-2.3.6.so
  bf7f7000-bf80d000 rw-p bf7f7000 00:00 0 [stack]
  ffffe000-fffff000 ---p 00000000 00:00 0 [vdso]Texte
  
  
  Lors d'un second lancement du même processus, nous constatons que l'adresse de la pile a effectivement changé et se trouve désormais entre 0xBF865000 et BxBF87B000 :
  
  $srv&
  [3593]
  
  $ cat /proc/3593/maps
  (...)
  0804a000-0806b000 rw-p 0804a000 00:00 0 [heap]
  b7e11000-b7e12000 rw-p b7e11000 00:00 0
  b7e12000-b7f40000 r-xp 00000000 03:04 345236 /lib/tls/libc-2.3.6.so
  b7f40000-b7f45000 r--p 0012e000 03:04 345236 /lib/tls/libc-2.3.6.so
  b7f45000-b7f48000 rw-p 00133000 03:04 345236 /lib/tls/libc-2.3.6.so
  b7f48000-b7f4a000 rw-p b7f48000 00:00 0
  b7f63000-b7f66000 rw-p b7f63000 00:00 0
  b7f66000-b7f7b000 r-xp 00000000 03:04 2032253 /lib/ld-2.3.6.so
  b7f7b000-b7f7d000 rw-p 00015000 03:04 2032253 /lib/ld-2.3.6.so
  bf865000-bf87b000 rw-p bf865000 00:00 0 [stack]
  ffffe000-fffff000 ---p 00000000 00:00 0 [vdso]Texte
  

  
  
  L'adresse de la pile a changé, pas celle du tas. On peut aussi le vérifier avec un programme du style:
  
  
  /* test.c */
  
  #include <stdlib.h>
  #include <stdio.h>
  
  
  int main(void)
  {
  int i;
  int *p;
  
  p = malloc(10 * sizeof(int));
  
  /* pile */
  printf("Dans la pile: %p\n", (void *)&i);
  /* tas */
  printf("Dans le tas: %p\n", (void *)p);
  
  free(p);
  
  return 0;
  }
  
  
  
  renvoie:
  
  $ for i in `seq 1 10`; do ./test; done
  
  Dans la pile: 0xbfe185cc
  Dans le tas: 0x804a008
  Dans la pile: 0xbf99c95c
  Dans le tas: 0x804a008
  Dans la pile: 0xbfd0d4cc
  Dans le tas: 0x804a008
  Dans la pile: 0xbf80afcc
  Dans le tas: 0x804a008
  Dans la pile: 0xbfe485fc
  Dans le tas: 0x804a008
  Dans la pile: 0xbfbf83ac
  Dans le tas: 0x804a008
  Dans la pile: 0xbff256dc
  Dans le tas: 0x804a008
  Dans la pile: 0xbff4df0c
  Dans le tas: 0x804a008
  Dans la pile: 0xbfa9824c
  Dans le tas: 0x804a008
  Dans la pile: 0xbfd4dd0c
  Dans le tas: 0x804a008
  
  
  Ensuite, "aléatoire" est un grand mot.
  L'une des critiques quand il a été introduit est la suivante:
  
  

  
  One of the biggest complaints that has been raised is that the amount of randomization is insufficient. The patches, as posted, vary the stack base within a 64KB area and the mmap() base within a 1MB range. Alignment requirements prevent just any address from being used with the result that only a relatively small number of possible base addresses exists. So a determined attacker could repeatedly run a hardcoded exploit with some assurance that, within a reasonable amount of time, the stack would land at the right place and the exploit would work. Placing a long series of no-op instructions at the beginning of the payload can also make an exploit more robust when faced with randomization.
  

  
  
  En gros, la plage de valeur possible n'est pas très étendue, et quand on enlève les adressesquivontpas (alignement toussa...), et bien on se dit qu'il suffit de lancer l'exploit en boucle et au bout de peu de temps on va tomber sur une adresse qui correspond à celle codée dans l'exploit.
  
  Voilà. Après, je ne pense pas qu'il y ait un inpact visible sur les performances. De toute façon, avec la rapidité des machines actuelles, j'en ai rien à foutre de perdre 10% de performances si j'ai un OS fiable et sûr. Une machine à laver marche 24/7, il devrait en être de même d'un ordinateur...

  • [^]Re: L'ASLR ne sert à rien

    Posté par IsNotGood () le 18/11/2007 à 01:05. (lien). Évalué à 1.

    Tu utilises quoi ?
    
    J'ai utilisé ton source et j'ai (sous F8) :
    $ for i in `seq 1 10`; do ./test; done
    Dans la pile: 0xbf81475c
    Dans le tas: 0x8dcb008
    Dans la pile: 0xbfef463c
    Dans le tas: 0x8f4a008
    Dans la pile: 0xbfa931dc
    Dans le tas: 0x85b8008
    Dans la pile: 0xbfeb59cc
    Dans le tas: 0x83f6008
    Dans la pile: 0xbf91785c
    Dans le tas: 0x8141008
    Dans la pile: 0xbfb6ea5c
    Dans le tas: 0x8441008
    Dans la pile: 0xbffa76ec
    Dans le tas: 0x87b8008
    Dans la pile: 0xbfc67bac
    Dans le tas: 0x864c008
    Dans la pile: 0xbfcd5c1c
    Dans le tas: 0x9448008
    Dans la pile: 0xbfa5b99c
    Dans le tas: 0x898c008
    
    > En gros, la plage de valeur possible n'est pas très étendue
    
    Oui. Mais il faut une bonne centaine de tentative au moins. C'est toujours ça de pris. Et 99 fois sur 100 que le craker va faire une tentative, ça va être un segfault. Ça va donc probablement se remarquer.
    
    > ASLR n'est pas très utile.
    
    C'est un petit plus. Combiné avec NX (ou ExecShield), c'est un gros plus.

  • [^]Re: L'ASLR ne sert à rien

    Posté par oumpa () le 19/11/2007 à 12:52. (lien). Évalué à 1.

    ASLR permet de rendre aléatoire un espace d'adressages mémoire dans des zones spécifiques, il est donc apte à le faire avec le tas (heap) à condition que l'implémentation en fasse l'objet ...
    
    Sinon pour les curieux, contournement de PaX ASLR :
    
    http://www.phrack.org/archives/59/p59-0x09.txt
    
    Doc de PaX ASLR :
    
    http://pax.grsecurity.net/docs/aslr.txt
    
    Bonne lecture ...