Aller au contenu | Aller au menu | Aller à la recherche

Another Home Page Blog

lundi, juin 20 2011

Installation d'un domU Xen Enterprise Linux sur un dom0 NetBSD

Ces derniers temps je m'amuse à faire des installations par le réseau d'un peu tout et n'importe quoi. J'utilise principalement l'outil de virtualisation Oracle VirtualBox, mais il m'arrive aussi de faire joujou avec Xen. Avec un hôte (dom0) CentOS 5 (et sans doute toutes les distribution de type "Enterprise Linux" telles que Red Hat Enterprise Linux ou Scientific Linux), il est très facile de créer d'autres machines virtuelles (domU) Xen de même type grâce à la commande "virt-install". Avec un dom0 NetBSD cependant, point de commande de ce type. Voyons donc comment faire.

Sur un système Enterprise Linux 5, il est possible de trouver une image de noyau d'installation (et l'initrd approprié) spécifique à Xen, comme par exemple sur ce miroir pour CentOS 5 64 bits.

Ce qui me paraît étrange, c'est avec Enterprise Linux 6, tout du moins avec Scientific Linux. Le noyau 2.6.32 dispose à priori des pv-ops, mais SL6 dispose d'un noyau et d'un initrd Xen. Peut-être est-ce par soucis de compatibilité de chemins, car les fichiers font la même taille que dans le répertoire pxeboot. D'ailleurs, lors de ma synchronisation rsync avec le miroir officiel Scientific Linux, le répertoire xen n'apparaît pas. Et je n'en ai pas eu besoin :)

Une fois nos images de noyau et d'initrd en main, il nous reste à créer notre fichier de configuration de domU, mon exemple prend comme exemple de disque dur un fichier et une connexion réseau par bridge :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
kernel  = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/vmlinuz"
ramdisk = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/initrd.img"
extra = "vnc"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

Il est possible de faire l'installation en mode texte en supprimant la ligne "extra", et d'ajouter l'url d'un fichier kickstart dans la directive extra, qui devient donc :

extra = "text ks=http://monserveur/pub/cfg/centos5_x86_64.cfg"

La commande "xm create -c centosexample" vous permet de lancer votre domU et de débuter l'installation. Une fois celle-ci faite et votre domU de nouveau éteint, il suffit de commenter les lignes "kernel" et "ramdisk" et de décommenter la ligne "bootloader". Vous pouvez alors démarrer votre domU sans que le noyau de celui-ci soit sur le disque dur du dom0 :)

Lors de mes tests, je me suis limité au partitionnement par défaut (qui utilise LVM), à un détail près : avec Scientific Linux 6, j'ai imposé ext3 à l'installeur. Une fois l'installation terminée, éteindre son domU (proprement de préférence) et modifier la configuration qui devient :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
bootloader = "/usr/pkg/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

J'ai donc remplacé le noyau et l'initrd d'installation par pygrub, qui me permet de démarrer mon domU sur le noyau et l'initrd installés. De plus, les mises à jour ne nécessitent pas de copier de nouveau le noyau et l'initrd sur le dom0.

Pour finir, si vous souhaitez installer un dom0 NetBSD, je ne peux que vous recommander l'excellent billet de Bsdsx !

lundi, janvier 17 2011

Vérifications de permissions - suite

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Après les droits des répertoires et le sticky bit, amusons-nous un peu avec SUID et SGID : un fichier possédant l'attribut SUID ou SGID permet d'être lancé avec les droits de l'utilisateur ou du groupe qui a été placé, généralement root. Ainsi, le programme at, permettant de lancer une tâche à un moment donné, est accessible aux utilisateurs classiques alors que son fonctionnement nécessite des droits plus élevés. Ceci peut s'avérer risqué car si un programme SUID root possède une faille, celle-ci peut être exploitée avec les droits de root, même si l'attaquant n'a pas les droits.

Comme pour le sticky bit, commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les fichiers possédant un SUID ou un SGID :

root@orgrimmar:~# find / \( -perm -4000 -o -perm -2000 \) -type f -print
/bin/ping6
/bin/umount
/bin/ping
/bin/mount
/bin/su
/lib64/dbus-1/dbus-daemon-launch-helper
/usr/bin/wall
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/sudoedit
/usr/bin/chsh
/usr/bin/write
/usr/bin/at
/usr/bin/chage
/usr/bin/crontab
/usr/bin/ssh-agent
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/gpasswd
/usr/bin/locate
/usr/bin/screen
/usr/libexec/openssh/ssh-keysign
/usr/libexec/libvirt_proxy
/usr/libexec/utempter/utempter
/usr/kerberos/bin/ksu
/usr/sbin/userhelper
/usr/sbin/postqueue
/usr/sbin/postdrop
/usr/sbin/usernetctl
/usr/sbin/ccreds_validate
/sbin/netreport
/sbin/mount.nfs4
/sbin/umount.nfs4
/sbin/umount.nfs
/sbin/mount.nfs
/sbin/unix_chkpwd
/sbin/pam_timestamp_check
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
root@orgrimmar:~# 

Sur le coup, voir autant de lignes peut paraître effrayant, mais si on y regarde de plus près, on peut comprendre que 99% des fichiers indiqués aient besoin du SUID. Le seul qui m'inquiète, c'est screen. Je vais donc regarder sur une autre machine, bien différente cette fois-ci :

nils@tomb:~$ uname -sr
NetBSD 5.0.2
nils@tomb:~$ ls -hl /usr/pkg/bin/scree*
lrwxr-xr-x  1 root  wheel   12B Jul 11 11:23 /usr/pkg/bin/screen@ -> screen-4.0.3
-r-s--x--x  1 root  wheel  279K Jul 11 11:23 /usr/pkg/bin/screen-4.0.3*

On voit que screen sur ma machine NetBSD a aussi un bit SUID. C'est bon, je peux aller me coucher l'esprit tranquille :) Mais avant, revenons à notre serveur CentOS, et comme pour l'affaire du sticky bit, simulons un programme dont le SUID a été ajouté inutilement :

root@orgrimmar:~# cat > testbin
#!/bin/bash
echo -n "Je suis un programme SUID de test"
exit 0
root@orgrimmar:~# chmod -v +x testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# ls -hl testbin 
-rwxr-xr-x 1 root root 63 déc 31 00:44 testbin*
root@orgrimmar:~# chmod -v +s testbin 
Le mode d'accès de `testbin' a été modifié à 6755 (rwsr-sr-x).
root@orgrimmar:~# ls -hl testbin 
-rwsr-sr-x 1 root root 63 déc 31 00:44 testbin*

Relançons notre recherche :

root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
/root/testbin

Supprimons maintenant le SUID et relançons la recherche :

root@orgrimmar:~# chmod -v -s testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
root@orgrimmar:~# 

Et voilà, nous sommes tranquille :)

Que faire si j'ai un doute sur un programme ? Plusieurs possibilités : s'il s'agit d'un programme qui est fourni par les paquets de votre distribution, on peut toujours aller vérifier sur d'autres machines, dont l'OS ou la distribution peut différer (comme je l'ai fait avec screen); un même programme nécessitant le SUID sur 2 OS différents peut légèrement rassurer. Si le logiciel est libre (exemple : GNU screen :D), on peut aussi aller chercher dans les fichiers de création du paquet binaire, pour les RPM il suffit de chercher le SRPM du logiciel et de l'installer sur une machine de test. Ensuite, on regarde le contenu du fichier .spec qui sert à la création de ce paquet : en effet, ces fichiers contiennent la liste et les droits des fichiers et répertoires du paquet que l'on veut compiler :) Si un .spec n'indique pas que le programme est SUID, alors il est temps de s'inquiéter !

lundi, janvier 3 2011

Vérifications de permissions

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Je vous propose de vérifier les permissions de certains de vos fichiers sur votre serveur ou poste fonctionnant sur un système Linux. Le but est de limiter les possibilités de tentatives d'intrusion en recherchant les moyens d'entrée possibles. Commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les répertoires dont les droits permettent à n'importe quel utilisateur d'écrire dedans, et dont le sticky bit n'est pas positionné :

root@orgrimmar:~# find / -type d \( -perm -0002 -a ! -perm -1000 \) -print

Si jamais votre machine possède de nombreuses partitions, et qu'elles sont du genre bien remplies, il est possible de limiter la recherche de find à une partition à la fois :

root@orgrimmar:~# find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /home -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /var -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print

Idéalement (et c'est le cas sur ma machine, ouf !), cette commande ne devrait occasionner aucun affichage. Maintenant, amusons-nous un peu :

root@orgrimmar:/tmp# mkdir insecure
root@orgrimmar:/tmp# chmod -v 777 insecure
Le mode d'accès de `insecure' a été modifié à 0777 (rwxrwxrwx).
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
/tmp/insecure

Positionnons maintenant le sticky bit :

root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwx 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# chmod -v +t /tmp/insecure/
Le mode d'accès de `/tmp/insecure/' a été modifié à 1777 (rwxrwxrwt).
root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwt 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:/tmp# 

Qu'est-ce que le sticky bit ? Extrait de la page de manuel de chmod (man chmod) :

t (sticky-bit) conserver le code du programme sur le périphérique de swap après exécution. Il s’agit du comportement original, mais de nos jours il sert uniquement pour les répertoires. Il indique que seuls le propriétaire du répertoire, et le propriétaire d’un fichier qui s’y trouve ont le droit de supprimer ce fichier. C’est typiquement utilisé pour les répertoires comme /tmp ayant une autorisation d’écriture générale.

Vérifions cela :

root@orgrimmar:/tmp# cd /
root@orgrimmar:/# ls -hl | grep tmp
drwxrwxrwt   5 root root 4,0K déc 30 23:59 tmp/

Le sticky bit est positionné. Je suis rassuré. Néanmoins, il ne fait pas tout. Regardons donc quels répertoires sont accessibles à tous les utilisateurs, sans chercher à savoir si le sticky bit est positionné :

root@orgrimmar:/# find / -type d \( -perm -0002 \) -print
/var/tmp
/var/lib/xenstored
/dev/shm
/tmp
/tmp/insecure
/tmp/.ICE-unix

Cela fait déjà un peu plus de monde... pas très rassurant mais à part notre répertoire insecure, pas de quoi s'affoler : /var/tmp et /tmp sont des répertoires destinés aux fichiers temporaires des programmes en fonctionnement, /var/shm désigne la mémoire partagée et le xenstored sert au bon fonctionnement de l'hyperviseur Xen.

Pour finir, nous pouvons nettoyer notre petite expérience :

root@orgrimmar:/# rmdir -v /tmp/insecure/
rmdir: destruction du répertoire /tmp/insecure/
root@orgrimmar:/# ls -hal /tmp/ | grep secu

jeudi, juin 3 2010

Dédé le clown et son copain le live-cd

C'est l'histoire de Dédé le clown, ou plutôt de dd le clone, qui rend bien service lorsqu'on a des sueurs froides... Mais qu'est-ce que dd ? Depuis la page de manuel, on peut lire : "convert and copy a file". C'est tellement simple qu'on se dit que ce n'est pas très puissant, mais on se met à créer des fichiers d'image disque, ou cloner des disques durs entiers, on comprend que parfois les énoncés les plus court peuvent être très complet ! La page wikipédia de dd en Français contient quelques exemples utiles, mais la page anglophone en contient encore plus !

Imaginons maintenant la situation : vous possédez deux machines, identiques. Vous installez la première et désirez installer la seconde à l'identique, il suffit de cloner le disque dur à l'aide de dd et de copier votre clone, toujours à l'aide de dd, sur la seconde machine. Une autre situation, que je ne vous souhaite pas : vous disposez de deux machines identiques toujours, mais l'OS de l'une d'entre elles se trouve endommagés (imaginez par exemple, 3/4 des fichiers de /boot disparus, idem dans /lib et à quelques autres endroits). Ajoutons à cela là contrainte que vous ne pouvez pas éteindre la machine encore en marche, et que le temps presse. Pas besoin de chercher deux heures un outil de clonage, il est installé sur votre linux adoré : dd. Récupérons un disque dur USB dont la capacité excède celle du disque local. Voici comment on clone le disque dur :

[root@machinequimarche ~]# dd bs=1M if=/dev/sda of=/media/usb/machine1.img

Je pars du principe que le disque dur s'appelle /dev/sda et que le disque USB est monté sous /media/usb/, mais cela peut différer selon la situation de chacun. On notera que l'option "bs=1M" (copier par blocs de 1 Méga-octet) rend la copie plus rapide. J'aurais bien tenté des blocs encore plus grands mais la copie s'est avérée déjà bien rapide.

Une fois la copie terminée (environ une bonne heure pour 70Go de disque, sachant qu'il y avait du raid 1 matériel sur du SCSI 10000 tours...), reste à se rendre devant la deuxième machine, de démarrer celle-ci sur un live-cd contenant lui aussi dd (n'importe quel live-cd de distriubtion Linux devrait l'avoir), et copier dans l'autre sens :

[root@machinequimarchepas ~]# dd bs=1M if=/media/usb/machine1.img of=/dev/sda

Bien sûr, on a au préalable monté le disque USB ;) Une fois la copie terminée, le disque démonté, je recommande de monter les partitions du disque local (/dev/sda pour mon cas), et d'aller modifier les noms d'hôte, les adresses IP et autres configurations particulières qu'on pourrait trouver dans /etc, sinon la mise en réseau de la machine risquerait d'être problématique. Dans le cas d'une RHEL/CentOS/Fedora, on pensera à modifier :

  • /etc/hosts
  • /etc/sysconfig/network
  • /etc/sysconfig/network-scripts/ifcf-* (selon vos configurations, plusieurs cartes réseau, bonding...)
  • /etc/sysconfig/iptables-config si vous sauvegardez ici votre firewall, sinon regardez votre script de firewall

Autre chose, surtout pour les utilisateurs des distributions sus-cités : le mode rescue n'est disponible que sur le CD1 ou DVD1, mais pas dans le boot.iso ou tout autre média de net-install. Ce mode permet de démarrer sur un système live minimaliste permettant de monter les partitions du système, de monter un disque dur usb (si vous le branchez avant de booter pour du RHEL4), et bien sûr, d'accéder à dd :)

vendredi, juin 20 2008

Utilisateurs virtuels sous CentOS 5 avec base de données MySQL

convert_to_centos5_fr.sh --url howtoforge.com

Lire la suite...

- page 1 de 2