Ce dossier francophone, en libre l'accès pour tous, porte sur l'activation de ASLR (Address Space Layout Randomization), de GrSecurity et de PaX ainsi que sur celle de SELinux ; vous y retrouverez les procédures d'installation, de configuration et d'administration de ces mécanismes ainsi que des exemples d'attaques.
Vous pourrez également vous servir de la base d'exploits ExploitTree, basée sur CVS, et de sa plateforme de recherche en Perl afin de tester l'ensemble de ces fonctions de renforcement des noyaux Linux de cette branche. Parmi ces différents mécanismes de sécurisation, on retrouve donc plus en détails :
- ASLR ou Address Space Layout Randomization qui permet de rendre aléatoire les adresses mémoires pour le Tas (heap) et la pile système ;
- GrSecurity pour les définitions d'utilisation sécurisée des plages mémoires et des zones d'exécution. Il se base notamment sur PaX pour le traitement de la mémoire au niveau des zones kernel (noyau) et userland (espace utilisateur) grâce à l'ajout de protections spécifiques ;
- SELinux afin de restreindre le champ d'application de l'exploitation résultant de la compromission d'une machine par un utilisateur mal intentionné.
La version du noyau Linux étudiée dans ce dossier est une version 2.6.16.9, dernière version stable à rédaction de celui-ci ; la version la plus récente actuelle est la 2.6.23.1 disponible sur Kernel.org.
Aller plus loin
- Le dossier Kernel Hardening sur Secuobs.com (20 clics)
- Kernel.org le site officiel (1 clic)
- PaX le site officiel (2 clics)
- GrSecurity le site officiel (1 clic)
- SELinux le site officiel (4 clics)
- Le dossier ExploitTree sur Secuobs.com (5 clics)
# Pourquoi une option ?
Posté par Éric JACQUOT . Évalué à 9.
j'entends par là :
- Chroot renforcé car trop permissif par defaut (en gros qui laisse s'échapper les occupants)
- Cacher les process du noyau
- Logs beaucoup plus 'verbose' sur les actions des users
- Protection de la pile
- et bien d'autres...
Pourquoi ce qui s'applique aux BSD ne fait figure que d'option sous Linux ?
J'adore GNU/Linux (et notamment la branche Gentoo Hardened) mais je ne comprends toujours pas pourquoi la branche grsec2 + PaX n' est pas intégrée par défaut ...
Si d'ailleurs quelqu'un peut me l'expliquer je suis tout ouïe ( je ne suis pas sûr de l'orthographe ne m'en veuillez pas ;) )
[^] # Re: Pourquoi une option ?
Posté par patrick_g (site web personnel) . Évalué à 2.
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 . Évalué à 5.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 1.
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . Évalué à 2.
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 . Évalué à 1.
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. (site web personnel) . Évalué à 4.
à 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 . Évalué à 3.
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 . Évalué à 0.
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 . Évalué à 1.
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 2.
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 . Évalué à 4.
> 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 . Évalué à 1.
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) :
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 . Évalué à 9.
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 . Évalué à 0.
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 . Évalué à 2.
[^] # Re: Pourquoi une option ?
Posté par Éric JACQUOT . Évalué à 1.
>
>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 . Évalué à 4.
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 . Évalué à 1.
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 . Évalué à 2.
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 . Évalué à 1.
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
Posté par loufoque . Évalué à -2.
Ça ne fait que rendre certains bugs plus difficilement exploitables, bugs qui ne devraient pas exister si le programmeur savait utiliser des idiomes sûrs de programmation.
[^] # Re: L'ASLR ne sert à rien
Posté par Miod in the middle . Évalué à 4.
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 . Évalué à -4.
De toute façon, cela ne compromet en rien le système.
[^] # Re: L'ASLR ne sert à rien
Posté par neologix . Évalué à 1.
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:
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:
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 . Évalué à 1.
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 . Évalué à 1.
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 ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.