Les spécificités de Linux en sécurité
Denis Ducamp / Hervé Schauer Consultants
18 juin 1999
Reproduction strictement interdite
Cette présentation va aborder deux aspects distincts :
- les principales fonctions de sécurité de Linux 2.2
- l'authentification avec PAM (Pluggable Authentication Modules)
1.1 Qu'est ce qu'un noyau ?
Le noyau est le coeur du système.
Il peut être comparé à un "gros programme" qui serait chargé en mémoire à
l'initialisation de la machine. Ses principales tâches sont de :
- gérer les systèmes d'entrées / sorties et les processus.
- distribuer aux processus les ressources en temps processeur et en
mémoire.
Les programmes accèdent aux fonctionnalités du noyau via les appels
systèmes.
1.2 Les principales fonctions de sécurité de Linux 2.2
- Les privilèges (capabilities)
- Les risques des modules
- La comptabilité
- Le chiffrement de systèmes de fichiers
- Divers : les patchs de sécurité et les distributions sécurisées
- Qu'est ce qu'un privilège ?
- Les privilèges linux
- Les privilèges des processus
- Gestion des processus
- Exemples de processus
- Les privilèges des fichiers exécutables
- Exemples de fichiers exécutables
- Références
2.1 Qu'est ce qu'un privilège ?
Sur un système Unix classique, le compte root (UID égal à 0) possède tous
les droits. Il peut ainsi lire tous les fichiers et tuer tous les processus.
Si un programme a besoin d'un privilège alors le processus devra avoir
l'identité de root.
Par exemple un programme de sauvegarde n'a besoin que de pouvoir lire
tous les fichiers. En s'exécutant en tant que root, il obtient le contrôle
total du système et peut donc tuer tous les processus.
Les privilèges (capabilities) sont le partitionnement des
privilèges du compte root (UID = 0) en droits unitaires. Il est ainsi
possible d'allouer à des processus les seuls droits dont ils ont besoin.
2.2 Les privilèges linux
Le système de privilèges utilisé est celui défini par le draft POSIX
1003.1e "POSIX capabilities" qui est maintenant abandonné.
Actuellement seuls les processus sont associés aux privilèges. Deux
implémentations sont en cours de réalisation pour gérer les privilèges au
niveau des fichiers exécutables.
Chaque processus possède trois ensembles de privilèges :
- permitted(P) : les privilèges que le processus courant
possède
- effective(E) : les privilèges que le processus courant peut
exécuter
- inheritable(I) : les privilèges qui seront hérités par un
processus fils
2.3 Les privilèges des processus
L'implémentation du noyau 2.2 ne fait aucune référence à l'UID d'un
processus pour savoir quels sont ses droits, seul l'ensemble de ses
privilèges effectifs (E) est consulté.
Sur un système Unix classique les processus appartenant à root possèdent
tous les privilèges, les autres processus n'en possèdent aucun.
Le privilège CAP_SETPCAP permet de changer les privilèges d'autres
processus. Cette fonctionnalité n'existant pas sur un système classique, ce
privilège n'est donné à aucun processus sous Linux 2.2 .
Afin d'avoir un système fonctionnel à base de privilèges il est
nécessaire de modifier deux lignes dans les sources du noyau pour que les
processus appartenant à root acquièrent ce privilège (voir FAQ).
2.4 Gestion des processus
Les deux utilitaires à connaître sont :
- execcap <caps> <command-path> command-args...
permet d'exécuter un programme avec des privilèges réduits
- sucap <user> <group> <caps> <command-path> command-args...
permet d'exécuter un programme avec des privilèges réduits en spécifiant
l'utilisateur et le groupe d'exécution.
Note : utiliser les utilitaires fournis avec une version 1.92
ou plus récente de la bibliothèque libcap (voir Références)
2.5 Exemples de processus
Dans les exemples ci-dessous, le programme lancé est un serveur de
tamagoshi qui ouvrira une socket sur un port privilégié (999).
- execcap cap_net_bind_service=eip /usr/local/bin/tama 999
Le processus est exécuté en tant que root mais ne possède que le droit
d'ouvrir des ports privilégiés.
Si le programme possède une vulnérabilité, alors il pourra toujours être
utilisé pour accéder à des fichiers appartenant à root.
- execcap tama tama cap_net_bind_service=eip /usr/local/bin/tama 999
Le processus est exécuté en tant que tama mais possède le privilège
d'ouvrir des ports privilégiés.
Si le programme possède une vulnérabilité, alors il ne pourra être
utilisé que pour accéder à des fichiers appartenant à tama.
Il existe des conditions dans lesquelles le programme aura commencé à
être exécuté par le système alors que ses privilèges ne lui auront pas
encore été accordés.
2.6 Les privilèges des fichiers exécutables
Deux implémentations sont en cours de développement :
- fcaps : VFS layer patchs for capabilities
Permet d'accorder à tout fichier exécutable des privilèges.
L'ensemble de ces privilèges sont enregistrés au niveau du système de
fichiers.
- elfcap : Elf capabilities hack
Permet de retirer des privilèges à tout fichier exécutable au format elf.
L'ensemble de ces privilèges sont enregistrés au niveau de l'en-tête elf.
2.7 Exemples de fichiers exécutables
Les exemples ci-dessous comparent les deux solutions pour le programme
ping qui nécessite le privilège CAP_NET_RAW pour ouvrir
une socket en mode raw.
- fcaps :
- ping n'a pas besoin d'être SUID root
- Le processus a pour identité celle de l'utilisateur qui l'a lancé.
- elfcap
- ping doit être SUID root
- Le processus peut avoir pour identité celle de l'utilisateur qui l'a
lancé si l'option adéquate a été utilisée lors de la définition des
privilèges accordés; sinon il sera root.
Notes :
- le patch fcaps n'est pas sufisamment avancé pour être utilisé
sur des systèmes en production. Les utilitaires nécessaires sont ceux
fournis avec la libcap
- le patch elfcap est suffisament avancé pour être utilisé sur
des systèmes en production. Les utilitaires nécessaires doivent être
récupérés avec le patch. Ce système est actuellement limité aux fichiers au
format elf.
2.8 Références
Linux Capabilities FAQ 0.2
<ftp://ftp.guardian.no/pub/free/linux/capabilities/>
ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.3/
par
Andrew Morgan
<morgan@transmeta.com> :
bibliothèque (libcap), utilitaires et patchs noyaux.
Elf capabilities hack
<http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html>
par
Pavel Machek
<pavel@bug.ucw.cz> :
utilitaires et patchs noyaux.
Les modules ne rentrent pas en jeu dans la sécurité d'un système
Les modules possèdent le contrôle total de la machine et peuvent :
- permettre aux administrateurs d'améliorer la sécurité du système
- permettre aux pirates d'affaiblir la sécurité du système.
3.1 Qu'est-ce qu'un module ?
Un module est un morceau de code permettant d'ajouter des fonctionnalités
au noyau : pilotes de périphériques matériels, protocoles réseaux, etc.
Il peut être chargé dynamiquement sans avoir besoin de recompiler le
noyau ou de redémarrer le système.
Les modules sont exécutés dans l'espace mémoire du noyau :
- ils possèdent le contrôle total de la machine
- ils peuvent détourner ou créer un appel système
3.2 Avantages pour l'administrateur
- mise à jour d'un pilote sans recompiler un noyau et redémarrer le
système.
- Détourner certains appels systèmes pour surveiller l'activité du système
:
- rediriger ou journaliser les accès à certains fichiers
- journaliser les ajouts et les suppressions de modules;
fonctions pouvant être soumises à l'authentification préalable de
l'utilisateur.
3.3 Avantages pour les pirates
Prendre le contrôle total de la machine en détournant des appels
systèmes :
- modifier la configuration apparente de la machine : mode
promiscuous
- cacher des fichiers :
rendre invisible les fichiers commençant par un mot clé
- filtrer le contenu d'un fichier :
ôter des journaux, les lignes contenant l'adresse IP du pirate
- détourner les demandes de changement d'identité :
un compte utilisateur donné peut devenir administrateur
- sortir d'un environnement restreint (chroot)
- cacher un processus :
rendre invisibles les processus commençant par un mot clé
- rediriger l'exécution de programmes :
installer des backdoor sans modifier les programmes originaux
3.4 Références
- "
(nearly) Complete Linux Loadable Kernel Modules"
<http://www.infowar.co.uk/thc/files/thc/LKM_HACKING.html>
par pragmatic / THC : descriptions de nombreuses utilisations des
modules sous Linux avec les sources pour Linux 2.0.3x
- "
lcamtuf::pliki"
<http://dione.ids.pl/~lcamtuf/pliki.html>
par
Michal Zalewski
<lcamtuf@ids.pl> : de nombreux sources de modules ou de patchs noyaux
pour Linux 2.0.3x ou 2.2.x - la majorité en polonais.
-
Phrack Magazine
<http://www.phrack.com> :
- "Weakening the Linux Kernel" (Issue 52 article 18)
par
plaguez
<dube0866@eurobretagne.fr> : description et sources d'un cheval de
Troie s'initialisant par un module.
- "btrom" (Issue 54 article 03)
par riq : description et sources d'un programme de détection et de
désactivation de chevaux de Troie fonctionnant sur le modèle précédent.
Enregistrement automatique par le noyau des ressources utilisées par
chaque processus lors de leurs terminaisons :
- date de création
- utilisateur propriétaire
- nom de la commande
- utilisation de la mémoire
- terminal contrôlé
- temps processeur utilisé
- nombre d'entrées/sorties réalisées
4.1 Les utilitaires
Les utilitaires nécessaire à l'utilisation des données de comptabilités
sont ceux édités par GNU : acct-6.3.2.tar.gz
Cette archive renferme entre autres les utilitaires suivants :
- accton : active et désactive la comptabilité
- lastcomm : affiche des informations à propos des dernières
commandes
- sa : résume les informations de comptabilité
4.2 Mise en route
Pré-requis : le support noyau doit être activé.
(sélectionner l'option "BSD Process Accounting" dans le menu "General
setup")
La comptabilité est activée par la commande
accton /var/account/pacct
Le journal doit exister avant l'appel à cette commande,
il peut être préférable de restreindre les droits d'accès au journal.
Le comportement de la comptabilité peut être modifié via l'entrée
/proc/sys/kernel/acct qui contient 3 entrées :
- limite basse : espace libre nécessaire pour que la
comptabilité reste active.
- limite haute : espace libre nécessaire pour que la
comptabilité se réactive.
- fréquence : temps en secondes entre deux vérifications de
l'espace libre.
4.3 Statistiques
Les deux commandes suivantes permettent de synthétiser les données :
La commande dump-acct /var/account/pacct exporte au format texte
le contenu du fichier de comptabilité. Il est ainsi possible de réaliser de
façon simple ses propres statistiques avec des languages comme awk et perl.
- Fonctionnement
- Notes
- Algorithmes
- Exemple
- Références
5.1 Fonctionnement
- La commande losetup associe un loopback à une
partition. Si un algorithme de chiffrement est sélectionné alors un mot de
passe est demandé.
- L'opération de montage de la partition se fait en indiquant le
loopback associé à la partition désirée.
- Toutes les données envoyées au loopback sont écrites
chiffrées dans la partition. Lors d'une lecture dans le loopback,
les données correspondantes sont lues dans la partition et déchiffrées en
mémoire.
5.2 Notes
- à cause des lois sur l'exportation et l'utilisation de la
cryptographie, les fonctionnalités de chiffrement de Linux ne peuvent être
incluses dans la distribution standard. Des patchs officiels sont
disponibles pour ajouter ces fonctions aux sources du noyau. Ces patchs
sont hébergés en Norvège.
- les commandes losetup, mount et umount
doivent être patchées pour supporter ces fonctionnalités.
Les patchs nécessaires sont fournis avec les patchs des sources du
noyau.
- un fichier peut être associé à un loopback. Cela permet :
- de créer de petites partitions chiffrées qui peuvent être montées
seulement lorsqu'elles sont nécessaires.
- de sauvegarder de façon sécurisée une partition vers un fichier chiffré.
5.3 Algorithmes
Deux algorithmes ont été implémentés pour chiffrer des partitions :
Une option permet d'utiliser en mode CBC n'importe quel algorithme
présent dans la bibliothèque pour chiffrer des partitions.
Cette bibliothèque comprend les algorithmes suivants :
Blowfish, DES, DFC, IDEA, MARS, RC6 et Serpent.
5.4 Exemple
Sauvegarde de fichiers dans un fichier chiffré :
# dd if=/dev/urandom of=~/mon_fichier bs=1k count=100
# losetup -e twofish /dev/loop0 ~/mon_fichier
Password:
# mkfs -t ext2 /dev/loop0
# mount -t ext2 /dev/loop0 ~/mnt
# cp -pr ~/prive ~/mnt
# umount /dev/loop0
# losetup -d /dev/loop0
5.5 Références
6.1 Patchs de sécurité
- partition /proc restreinte :
tout utilisateur n'a accès qu'aux données concernant ses propres
processus, un groupe spécial permet d'accéder aux données de tous les
processus.
http://underley.zakopane.top.pl/linux/restricted-procfs.html
par
Daniel Podlejski <underley@zakopane.top.pl>
- liens et tubes nommés restreints dans /tmp :
un processus n'a accès à un lien ou à un tube nommé dans /tmp seulement
s'il lui appartient ou qu'il appartient à root.
http://www.sekure.org/english/resources.html
par
Sekure SDI
<http://www.sekure.org/> (Brazilian Info Security Team)
- pile non exécutable :
la pile est rendue non exécutable afin d'empêcher la majorité des
exploitations par débordement de buffer de fonctionner.
Le principal problème est la gestion des programmes en glibc2 qui
utilisent les sauts par trampoline et qui obligent la pile à être
exécutable.
Cette fonction est en cours de portage par
Solar Designer <solar@false.com>
lui-même.
6.2 Distributions sécurisées
- nmrcOS (
http://www.nmrc.org/nmrcOS/ : le but est de fournir un système
stable et sécurisé.
Basée sur une distribution slackware avec un noyau 2.0.36, il intègre
plusieurs patchs de sécurité pour le noyau : "Solar Designer's patch",
"Trusted path support", "Probe Detection Patch", etc. Un script durcit les
droits d'accès sur de nombreux fichiers sensibles.
- kha0s (
http://www.kha0s.org/) : fournit une distribution minimale basée sur
un noyau 2.2.5 ainsi que de nombreuses fonctions de chiffrement.
Cette distribution se trouve à l'état de développement.
- bastille-linux (
http://www.bastille-linux.org/) : basée sur une distribution RedHat,
le but est de constituer une distribution utilisable dans les universités et
les établissements éducatifs.
La première version devrait être distribuée en Octobre 1999.
- securelinux (
http://www.reseau.nl/securelinux/) : le but est de fournir une
distribution sécurisée "à tous les niveaux". Plus complète que les autres
distributions, elle devrait fournir toutes les fonctions comme la gestion
des privilèges, le chiffrement de partitions, etc.
A l'heure actuelle, le développement de la distribution n'a pas encore
commencé.
Historiquement, l'authentification des utilisateurs sous Unix se basait
sur la saisie d'un mot de passe et sa vérification à partir du fichier
/etc/passwd .
A chaque amélioration de ce schéma (/etc/shadow ,
One-Time-Passwords, etc.) tous les programmes (login,
ftpd...) devaient être réécrits pour supporter les nouvelles
fonctionnalités.
PAM se veut un mécanisme flexible d'authentification des utilisateurs.
Les programmes supportant PAM doivent pouvoir se lier dynamiquement à des
modules chargés d'effectuer l'authentification.
L'ordre d'attachement des modules et leurs configurations sont à la
charge de l'administrateur système qui gère cela de façon centralisée.
7.1 Configuration
Chaque application PAM doit posséder un fichier de configuration dans le
répertoire /etc/pam.d . Chacun de ces fichiers est composé de 4
colonnes :
- type de module :
- auth : authentification de l'utilisateur
- account : gestion des utilisateurs (ex : restrictions horaires)
- session : tâches à effectuer en début et fin de chaque session
ex : montage de répertoires, contrôle des ressources
- password : mise à jour du jeton d'authentification de l'utilisateur
- contrôle de réussite
- required : la réussite d'au moins un des modules required est nécessaire
- requisite : la réussite de tous les modules requisite est nécessaire
- sufficient : la réussite d'un seul module sufficient est suffisant
- optional : la réussite d'au moins un des modules required est
nécessaire si aucun autre n'a réussi
- chemin du module, en général dans /usr/lib/security .
- arguments optionnels
Le fichier /etc/pam.d/other fournit les configurations par
défaut pour tout type de module non spécifié dans le fichier de
configuration de l'application.
7.2 Quelques modules intéressants
- pam_cracklib : ce module utilise la bibliothèque cracklib
pour vérifier la solidité d'un nouveau mot de passe. Il peut également
vérifier que le nouveau mot de passe n'est pas construit à partir de
l'ancien.
- pam_limits : ce module permet de limiter les ressources
accessibles à un utilisateur et/ou à un groupe comme le nombre de processus
simultanés et leurs temps CPU, le nombre de fichiers ouverts simultanés et
leurs tailles, le nombre de connexions simultanées, etc.
La configuration se fait via le fichier
/etc/security/limits.conf
- pam_rootok : permet à root l'accès à un service sans avoir
à rentrer de mot de passe. A n'utiliser qu'avec chfn ou
chsh, surtout pas avec login.
- pam_time : permet de limiter les horaires d'accès. La
configuration se fait via le fichier /etc/security/time.conf
- pam_wheel : ne permet l'accès au compte root qu'aux seuls
membres du groupe wheel. A utiliser qu'avec su.
7.3 Références
® © Hervé Schauer Consultants 1999 -
142, rue de Rivoli -
75001 Paris
Téléphone : +33 1 41 40 97 00 -
Télécopie : +33 1 41 40 97 09
Courriel : <secretariat@hsc.fr>