Le blog de Dju - Mot-clé - kernel - CommentairesUn peu de moto, un zeste de geek, et un brin d'autres trucs ;-)2024-03-22T17:50:26+01:00Djuurn:md5:5e61426dd704534f4aef077f5b82260bDotclearKernel debian et driver e1000e sur kimsufi 16G - Djuurn:md5:445285f3ef43afb096d8f2aab3fb2b582012-05-16T20:21:28+02:002012-05-16T19:21:28+02:00Dju<p>Bonjour,<br />
pour ce qui est du spécifique à centos, je ne pourrais vous répondre, ne l'ayant jamais utilisé.<br />
Néanmoins, la démarche serait effectivement la même <img src="/themes/BlueSky/smilies/smile.gif" alt=":)" class="smiley" /><br />
Accessoirement, il ne s'agit meme pas de recompiler le noyau, puisque c'est le "standard" de la distribution qui est utilisé. Il faut juste y intégrer le driver de la carte réseau.<br />
Pour debian, c'est très axé "libre" donc par défaut il n'y a pas de drivers propriétaires.<br />
Pour ce qui est de Centos, peut être le driver est il il deja inclus dans le kernel "standard" ?<br />
je crois que son kernel est un 2.6.32, donc relativement récent.<br />
Actuellement, sur un Kimsufi 16G, lspci indique ceci pour la carte réseau :<br />
"Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)"<br />
Eventuellement, la meilleure chose à faire serait, une fois le serveur livré, d'installer via le manager de packages (yum je crois) le kernel "standard" pour centos puis redémarrer dessus afin de voir si le serveur répond <img src="/themes/BlueSky/smilies/smile.gif" alt=":)" class="smiley" /></p>Kernel debian et driver e1000e sur kimsufi 16G - Yassurn:md5:6901095c756dee423cdd67fe6f909f062012-05-16T01:14:47+02:002012-05-16T00:14:47+02:00Yass<p>Bonjour,</p>
<p>Je suis tombé sur votre article en faisant une recherche sur les serveurs kimsufi. Je vous remercie pour ces explications détaillées.<br />
J'aimerai vous poser une question : j'envisage d'installer un kimsufi 16 avec une distrib CentOS, pour y installer un serveur openvpn. D'après ce que je peux voir, il y a aussi un kernel OVH. Pensez-vous qu'il soit possible de recompiler un kernel original, comme vous l'avez fait pour votre Debian ?<br />
Encore merci pour vos articles.</p>Faille de sécurité sur les kernels linux - kypdurronurn:md5:01b33567156ce4c82f33e2e353f7d3812010-10-29T18:07:03+02:002010-10-29T17:07:03+02:00kypdurron<p>Ce n'est pas tant l'aspect compilation qui est intéressant dans mon retour que l'aspect personnalisation...</p>
<p>J'utilise Gentoo surtout pour son approche minimaliste, pour la plupart de mes besoins des paquets binaires seraient bien plus pratiqued. Debian (et Ubuntu j'imagine) permet également de télécharger les sources à compiler soi même (pour les paquets avec apt-get source), le kernel nécessite quant à lui quelques outils dédiés sur cette distrib, mais en activant le support des modules il est assez aisé de compiler par la suite, sous forme de modules, des éléments manquants dans le kernel.</p>
<p>Enfin je prêche pas pour une distrib, l'essentiel est d'arriver à répondre aux besoins avec les outils avec lesquels on se sent à l'aise, mais je trouve tout de même les kernel pré-compilés un peu trop généralistes, de ce fait ils sont souvent sensibles à des failles sur des options obscures qui ne sont pas toujours nécessaires à la production d'un serveur dédié à un usage précis.</p>Faille de sécurité sur les kernels linux - Djuurn:md5:e4c8583ba8411599e9484750c6bc01e92010-10-28T00:34:24+02:002010-10-27T23:34:24+02:00Dju<p>Salut et merci pour le retour<br />
C'est vrai que compiler soi meme pour avoir juste ce dont on a besoin est une bonne solution, mais ça oblige à recompiler quand on veut mettre à jour...<br />
De ce point de vue, c'est bien pratique d'avoir des paquets pré-compilés via aptitude :p<br />
D'autre part, quand j'installe un OS sur une machine, je m'assure de faire toutes les mises à jours avant de commencer à installer les services (ce que fait debian à l'install, contrairement à ubuntu) <img src="/themes/BlueSky/smilies/smile.gif" alt=":)" class="smiley" /></p>Faille de sécurité sur les kernels linux - kypdurronurn:md5:4dee45f733177ea2ace45267d6d8f7d42010-10-26T20:54:47+02:002010-10-26T19:54:47+02:00kypdurron<p>Je viens d'acquérir une Dédi V3 avec une Ubuntu server 10.04 (j'avais besoin de quelque chose fonctionnel rapidement, et en l'absence de KVM-like déployer une de mes archives perso est un peu fastidieux...)</p>
<p>Cette faille ainsi que celle que tu as publié le 19 septembre passent un peu trop facilement.</p>
<p>Petit déception pour un serveur livré clé en main, un aptitude safe-upgrade à tout de même solutioner le problème en installant un kernel 2.6.32-25</p>
<p>$ uname -r<br />
2.6.32-25-server</p>
<p>Par acquis de conscience j'ai tenté de la reproduire sur deux autres de mes serveurs (sous Gentoo avec des kernel personnalisés) et elles ne fonctionnent pas...</p>
<p>Sur le premier une vieille gentoo de 3 ans</p>
<p>$ uname -r<br />
2.6.23-hardened-r7-valkyrie<br />
$ ./rds<br />
./rds: /lib/libc.so.6: version `GLIBC_2.7' not found (required by ./rds)<br />
//Toute façon le kernel est trop ancien pour celle là<br />
$ ./robert<br />
symbol table not available, aborting!<br />
Process finished</p>
<p>Sur le second une install fraiche de quelques semaines</p>
<p>$ uname -r<br />
2.6.34-gentoo-r11-tirnanog<br />
$ ./rds<br />
[*] Linux kernel >= 2.6.30 RDS socket exploit<br />
[*] by Dan Rosenberg<br />
[*] Could not open socket.<br />
$ ./robert<br />
resolved symbol commit_creds to 0xffffffff81058709<br />
resolved symbol prepare_kernel_cred to 0xffffffff81058604<br />
mapping at 3f80000000<br />
UID 1000, EUID:1000 GID:1000, EGID:1000<br />
sh-4.0$ id<br />
uid=1000(kypdurron) gid=1000(kypdurron) groups=1000(kypdurron),10(wheel),18(audio),19(cdrom),27(video),85(usb),250(portage)</p>
<p>J'ai même été testé une faille du même genre publié sur tux-planet <a href="http://www.tux-planet.fr/local-root-exploit-pipe-null-pointer-dereference/" title="http://www.tux-planet.fr/local-root-exploit-pipe-null-pointer-dereference/" rel="ugc nofollow">http://www.tux-planet.fr/local-root...</a> (ça faisait un moment que j'avais pas testé des local root exploit surtout sur mon vieux serveur en 2.6.23)</p>
<p>$ uname -r<br />
2.6.23-hardened-r7-valkyrie<br />
$ ./gayros<br />
We got NULL page babe!<br />
Using kernel version 2.6.23-hardened-r7-valkyrie.<br />
Found version 3 structure, doing our tricks in memory...<br />
Go go go boy!<br />
$ id<br />
uid=1000(kypdurron) gid=1000(kypdurron) groups=10(wheel),12(mail),16(cron),100(users),250(portage),1000(kypdurron)</p>
<p>cette faille qui a maintenant un an est toute façon patché sur les kernel récents</p>
<p>En clair sur les Gentoo soit RDS n'est pas activé dans le kernel (ou kernel trop ancien) soit la faille est patchée pour le recent, sinon pour la 2.6.23 sensé être vulnérable, on va dire que c'est le petit miracle de la gentoo "hardened" (un kernel patché avec quelques sécurités supplémentaires, je n'ai pas activé de SELinux ou autre...)</p>
<p>C'est peut être un mauvais conseil, mais compiler son kernel soit même avec le strict nécessaire et accessoirement quelques patchs, permet apparement de ne pas être à la merci des failles qui vont chercher dans des modules livrés avec les distributions généralistes...</p>
<p>Sur une Debian je n'avais pas eu de problème a recompiler un kernel, je vais peut être me lancer dans l'éxperience sur cette Ubuntu livré avec la V3.</p>