Déploiement “en masse” de noyau Linux personnalisé et durci à l’aide de Puppet
 |
Comme tout barbu qui se respecte, j’aime avoir un noyau Linux, dont la configuration correspond parfaitement au matériel et à l’utilisation d’une machine. Pour cela j’ai développé un module Puppet qui permet de déployer des noyaux Linux personnalisés et durcis. |
Problématique
Compiler et personnaliser la configuration du noyau d’une seule machine est une tâche qui nécessite :
- une bonne connaissance des options du noyau ;
- connaissance du matériel et des drivers correspondants ;
- du temps ;
Il y a de cela une dizaines d’année il était fréquent de compiler une version personnalisée du noyau Linux, mais aujourd’hui le noyau fourni par une distribution GNU/Linux, contient une grande quantité de pilotes et couvre la plupart des besoins.
Il n’y a pas de différence de performance entre un pilote de périphériques compiler en “dur” dans le noyau et charger en modules.
Les seules raisons de compiler un noyau personnalisé sont :
- la vitesse de démarrage ;
- et la sécurité.
C’est ce dernier point qui m’a poussé à mettre en place un système de compilation de noyau Linux automatisé.
Module Puppet
Le module Puppet dispose des fonctionnalités suivantes :
- installation et décompression des sources du noyau dans /usr/src ;
- application du patch grsecurity ;
- écriture d’un fichier de configuration personnalisé ;
- re-compilation du noyau et création d’un paquet pour la distribution Debian GNU/Linux ;
- compilation en cas de changement de la configuration ;
- TODO : installation du paquet et reboot sur le nouveau noyau à l’aide de kexec ;
Gestion de la configuration du noyau
D’après le LKDDb (Linux Kernel Driver DataBase), il y a plus de 19 000 options différentes dans un noyau Linux.
L’approche classique pour la gestion d’un tel nombre d’options est l’utilisation d’un tableur Excel ;-)
Mais la plupart des utilisateurs conservent les fichiers de configuration directement sur le système de fichier ou dans un logiciel de gestion de version.
Mais cette approche ne me satisfait pas, j’ai donc opté pour l’utilisation d’une base de données hiérarchique : Hiera
Structure hiérarchique
La structure adoptée est la suivante :
# /etc/puppet/hiera.yaml
---
:backends:
- yaml
:yaml:
:datadir: /etc/puppet/hiera/
:logger: puppet
:hierarchy:
- "fqdn/%{::fqdn}"
- "boardproductname/%{::boardproductname}"
- "hardwaremodel/%{::hardwaremodel}"
- common
common.yaml
Contient la configuration commune à toutes les machines et la “négation” des options, ce qui évite à make-kdpkg de choisir une option par défaut :
# /etc/puppet/hiera/common.yaml
---
linux-grsec::kernel::config:
CONFIG_CGROUP_DEBUG: n
CONFIG_CGROUP_FREEZER: n
CONFIG_CGROUP_DEVICE: n
CONFIG_CPUSETS: n
CONFIG_PROC_PID_CPUSET: n
CONFIG_CGROUP_CPUACCT: n
CONFIG_RESOURCE_COUNTERS: n
CONFIG_MEMCG: n
CONFIG_CGROUP_HUGETLB: n
CONFIG_CGROUP_PERF: n
CONFIG_CGROUP_SCHED: n
CONFIG_FAIR_GROUP_SCHED: n
CONFIG_CFS_BANDWIDTH: n
CONFIG_RT_GROUP_SCHED: n
CONFIG_BLK_CGROUP: n
CONFIG_CHECKPOINT_RESTORE: n
CONFIG_GRKERNSEC: y
CONFIG_GRKERNSEC_CONFIG_AUTO: n
CONFIG_GRKERNSEC_CONFIG_CUSTOM: y
CONFIG_PAX: y
...
Répertoires hardwaremodel et boardproductname
Le répertoire hardwaremodel contiens la définition d’un architecture :
/etc/puppet/hiera/hardwaremodel/ ├── i586.yaml ├── i686.yaml └── x86_64.yaml
Comme par exemple l’architecture x86_64:
# /etc/puppet/hiera/hardwaremodel/x86_64.yaml
---
linux-grsec::kernel::config:
CONFIG_64BIT: y
CONFIG_X86_64: y
CONFIG_OUTPUT_FORMAT: '"elf64-x86-64"'
CONFIG_ARCH_DEFCONFIG: '"arch/x86/configs/x86_64_defconfig"'
Le répertoire boardproductname contient la définition des pilote de périphériques pour une machine :
/etc/puppet/hiera/boardproductname/ ├── beagleboneblack.yaml ├── C7Q67.yaml ├── D33217GKE.yaml ├── DN2800MT.yaml ├── net5501.yaml ├── net6501.yaml ├── raspberrypi.yaml ├── wandboard.yaml ├── X7SPA-HF.yaml ├── X9SCL.yaml └── Z68MA-D2H-B3.yaml
Par exemple, pour un net5501 de Soekris Inc. :
# /etc/puppet/hiera/boardproductname/net5501.yaml
---
linux-grsec::kernel::config:
CONFIG_SMP: n
CONFIG_X86_64_SMP: n
CONFIG_X86_32_SMP: n
CONFIG_RCU_FANOUT: 32
CONFIG_MGEODE_LX: y
CONFIG_X86_GENERIC: n
CONFIG_GENERIC_CPU: n
CONFIG_NET_VENDOR_VIA: y
CONFIG_VIA_RHINE: y
CONFIG_VIA_RHINE_MMIO: y
CONFIG_HW_RANDOM_GEODE: y
CONFIG_FB_GEODE: y
CONFIG_CRYPTO_DEV_GEODE: y
CONFIG_CRC_T10DIF: y
CONFIG_ATA_GENERIC: y
CONFIG_PATA_CS5536: y
CONFIG_CS5535_MFGPT: y
CONFIG_SENSORS_PC87360: y
CONFIG_I2C: y
CONFIG_SCx200_ACB: y
CONFIG_LEDS_NET5501: y
Répertoire fqdn
Le répertoire fqdn contient les options spécifique à une machine et à ses fonctionnalités (ici une gateway VPN avec StrongSwan et l’IPS Suricata ) :
# /etc/puppet/hiera/fqdn/foo.bar.yaml
---
linux-grsec::kernel::config:
# StrongSwan
CONFIG_XFRM_USER: y
CONFIG_NET_KEY: y
CONFIG_NET_KEY_MIGRATE: n
CONFIG_IP_ADVANCED_ROUTER: y
CONFIG_IP_MULTIPLE_TABLES: y
CONFIG_INET_AH: y
CONFIG_INET_ESP: y
CONFIG_INET_IPCOMP: y
CONFIG_INET_XFRM_MODE_TRANSPORT: y
CONFIG_INET_XFRM_MODE_TUNNEL: y
CONFIG_INET_XFRM_MODE_BEET: y
CONFIG_NET_IPVTI: n
CONFIG_IPV6: y
CONFIG_INET6_AH: y
CONFIG_INET6_ESP: y
CONFIG_INET6_IPCOMP: y
CONFIG_INET6_XFRM_MODE_TRANSPORT: y
CONFIG_INET6_XFRM_MODE_TUNNEL: y
CONFIG_INET6_XFRM_MODE_BEET: y
CONFIG_IPV6_MULTIPLE_TABLES: y
CONFIG_IPV6_SUBTREES: n
CONFIG_NETFILTER: y
CONFIG_NETFILTER_XTABLES: y
CONFIG_NETFILTER_XT_MATCH_POLICY: y
# Suricata
CONFIG_NETFILTER_ADVANCED: y
CONFIG_BRIDGE_NETFILTER: n
CONFIG_NETFILTER_NETLINK_QUEUE: y
CONFIG_NETFILTER_NETLINK_ACCT: y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE: y
...
Configuration finale
$ hiera -h linux-grsec::kernel::config ::hardwaremodel i586 ::boardproductname net5501 ::fqdn foo.bar
{"CONFIG_NETFILTER_XT_MATCH_STATISTIC"=>"n",
"CONFIG_BLK_DEV_RSXX"=>"n",
"CONFIG_USB_CATC"=>"n",
"CONFIG_MMU"=>"y",
"CONFIG_GPIO_BCM_KONA"=>"n",
"CONFIG_CHELSIO_T4VF"=>"n",
"CONFIG_SERIAL_CORE"=>"y",
"CONFIG_DM_MIRROR"=>"y",
"CONFIG_IO_DELAY_TYPE_NONE"=>3,
"CONFIG_MMC_TEST"=>"n",
...
Exemple d’utilisation
# puppet agent -t
...
info: Applying configuration version '1402952642'
notice: /Stage[main]/Linux-grsec::Kernel/File[/usr/src/foo.config]/ensure: created
info: /Stage[main]/Linux-grsec::Kernel/File[/usr/src/foo.config]: Scheduling refresh of Exec[make-kpkg]
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/linux-3.14.4.tar.xz]/ensure: defined content as '{md5}c7c565d14833550faa39ef8279272182'
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/grsecurity-3.0-3.14.4-201405141623.patch]/ensure: defined content as '{md5}e88a81b0c222d14e228dc29dd76a875a'
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/grsecurity-3.0-3.14.4-201405141623.patch.sig]/ensure: defined content as '{md5}737b22b6e8cae0d4398ba3f68acaf1e1'
notice: /Stage[main]/Linux-grsec::Install/Exec[/usr/src/linux-3.14.4/grsecurity]/returns: executed successfully
info: /Stage[main]/Linux-grsec::Install/Exec[/usr/src/linux-3.14.4/grsecurity]: Scheduling refresh of Exec[make-kpkg]
notice: /Stage[main]/Linux-grsec::Install/Exec[/usr/src/linux-3.14.4]/returns: executed successfully
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/linux-3.14.4/.config]/ensure: created
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: exec make kpkg_version=12.036+nmu3 -f /usr/share/kernel-package/ruleset/minimal.mk debian APPEND_TO_VERSION=-foo INITRD=YES
...
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: cp -pf debian/control.dist debian/control
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: make[2]: Leaving directory `/usr/src/linux-3.14.4'
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: make[1]: Leaving directory `/usr/src/linux-3.14.4'
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]: Triggered 'refresh' from 2 events
notice: Finished catalog run in 179.65 seconds
..
# dpkg -i linux-*.deb
Conclusion
Ce système me permet de déployer des noyaux GRSec sur la petite dizaine de machines de mon réseau local.
Cette méthode ne convient pas au domaine de l’embarqué, (rasberrypi, beaglebone black, wandboard, etc… ) car l’espace disque et la puissance de calcul nécessaire ne sont pas disponible sur ce type de machine.
