Planète des utilisateurs Debian  -  Christophe Nowicki: Déploiement “en masse” de noyau Linux personnalisé et durci à l’aide de Puppet

 -  Juin 2014 - 

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.

Références

• puppet-linux-grsec ;
• Debian Linux Kernel Handbook ;
• grsecurity ;
• Hiera: Overview ;

par