Sécurité système

Rappels

Système de contrôle d’accès discrétionnaire (DAC) où tout est fichier :

Ne pas oublier sur Linux

• ACL étendues (getfacl / setfacl)
• On peut ainsi (un peu) s’orienter vers du contrôle d’accès par rôles (RBAC)

Concept d’utilisation

• Utilisateur spécifique par processus/fonctionnalité (compte de service)
• Groupe commun
• Contrôle plus fin possible avec ACL étendues

Serveur web (httpd:http) et PHP FPM (php:http)

srw-rw---- 1 httpd http    0  5 mars  16:21 /run/php-fpm.sock
-r-------- 1 php   http 3272 13 févr.  2021 /etc/myapp/privkey.pem

Répertoire de numérisation pour photocopieur

ls -lR /srv/partage

drwxrwx---+ 7 root secretariat 4096 15 janv.  2019 Secrétariat

/srv/partage/Secrétariat
total 38
drwxrwx-w-  2 root secretariat 4096 15 janv.  2019 Numérisation

getfacl /srv/partage/Secrétariat

# file: srv/partage/Secrétariat
# owner: root
# group: secretariat
user::rwx
group::rwx
other::---
user:photocopieur:--x

DAC souffre de nombreuses limitations :

• les utilisateurs ont un contrôle complet de leurs ressources (CRUD + nouveaux droits)
• les programmes ont les mêmes droits que leur utilisateur

Si un programme en UID 0 est compromis, le système entier est compromis

Security-Enhanced Linux apporte un système de contrôle d’accès mandataire (MAC) où le noyau applique une politique de contrôle complémentaire.

SELinux utilise des contextes de sécurité composés :

• d’une identité (_u, propriétaire du contexte)
• d’un rôle (_r)
• d’un domaine pour les sujet (utilisateurs ou processus) ou d’un type pour les objets (ressources passives) (_t).

Le contexte d’un objet peut être vu avec ls -Z :

drwxr-xr-x root root system_u:object_r:etc_t  /etc

Écrire une politique de sécurité est difficile. Certaines distributions appliquent par défaut une politique SELinux, comme RHEL qui se base sur le FHS.

chroot / jail

chroot (appel système et commande) simule une autre racine à l’intérieur du système de fichiers

• seuls les fichiers sous la nouvelle racine seront visibles
• nécessite de recréer une arborescence FHS (/, /dev, /proc, /sys…), et d’exposer les biliothèques nécessaires
• nécessite des privilèges élevés pour être utilisé (ou CAP_SYS_CHROOT), mais utiliser root ne respecte pas les moindre privilèges ( setuid)
• chroot is not and never has been a security tool (Alan Cox)
• This call […] is not intended to be used for any kind of security purpose (chroot(2))

chroot / jail

jail est une alternative plus robuste sous FreeBSD avec :

• un appel système
• un jeu de commandes (jail, jls et jexec)

Un jail a aussi son propre environnement réseau (nom d’hôte et adresse IP.)

Faute de mieux, on a le programme firejail sous Linux, utilisant les namespaces et seccomp-bpf

setuid et setgid

Ces deux appels systèmes changent l’utilisateur et le groupe principal du processus :

• fait par la plupart des services sérieux lancés en root

• sinon, écrire un service systemd adapté (systemd.exec(5))

• y dédier un compte de service spécifique

• y dédier un groupe spécifique à un ensemble de services

  (cf. exemple ACL)

Pour limiter les privilèges requis sur certaines actions sensibles, Linux propose les capabilities(7)

seccomp(-bpf)

À l’origine, seccomp(2) est un appel système pour jeter ses droits et se restreindre à la manipulation de fichiers déjà ouverts (SECCOMP_SET_MODE_STRICT).

Effectuer un appel système autre que exit, sigreturn, read ou write conduit à se faire tuer par le noyau.

Le mode filtre Berkley Packet Filter (SECCOMP_SET_MODE_FILTER) permet de préciser la liste des appels systèmes autorisés.

seccomp-bpf a ainsi été particulièrement utilisé par Chromium OS dont le code source peut servir de référence d’implémentation.

La fonctionnalité Linux des Control groups (cgroups(7)) permet de :

• organiser les processus en groupes hiérarchiques
• limiter leurs ressources
• les superviser (systemd-cgtop)

Ils sont présentés à l’utilisateur comme un simple système de fichiers monté (/sys/fs/cgroup) : tout est fichier.

systemd crée par défaut un cgroup sous system.slice pour chaque service ( systemd-cgls).

Les (*_)namespaces(7) permettent de cloisonner les applications sur plusieurs types de ressources :

Avec les fonctionnalités précédentes, il est possible sur un même système hôte (noyau) :

• de mettre en place des conteneurs Linux (sans noyau)
• d’isoler les processus et les ressources associées

Ces conteneurs peuvent être gérés :

• bas niveau avec les commandes LXC (lxc-*)
• avec systemd-nspawn / systemd-machined (machinectl)
• plus haut niveau avec Docker ou containerd pour faciliter la diffusion et le déploiement

Voir aussi les Recommandations pour la mise en place de cloisonnement système, ANSSI

Avantages

• isolation des composants applicatifs au sein des conteneurs
• réduction des privilèges (user_namespaces…)
• scalabilité horizontale facilitée par la répétabilité du déploiement

Inconvénients

• complexité accrue de l’architecture applicative (quel conteneur héberge quoi ?)
• complexité accrue de l’administration (socle + gestionnaire)
• jonction (plus) forte entre administration système et développement (devops)
• est-ce adapté pour assurer une sécurité élevée ? (confiance dans l’isolation offerte par le noyau)

Lorsqu’une segmentation plus importante ou des fonctionnalités spécifiques du noyau sont requises (comme le filtrage réseau), l’isolation par conteneurs ne suffit plus.

On peut alors employer la virtualisation où un hyperviseur (comme KVM, VirtualBox, Xen ou VMware) émule ou partage les ressources physiques (CPU, mémoire, stockage, I/O) de l’hôte.

Le matériel doit être configuré pour supporter la virtualisation (bits Intel VT-x ou AMD-V)

Voir aussi les Problématiques de sécurité associées à la virtualisation des systèmes d’information, ANSSI

Avantages

• accès aux fonctionnalités spécifiques du noyau
• isolation plus marquée, reposant sur des fonctionnalités du CPU
• performances accrues grâce aux ressources matérielles pouvant être dédiées

Inconvénients

• matériel dédié pour un hyperviseur type 1 (bare metal)
• possible complexité de l’architecture de virtualisation (cluster d’hyperviseurs, stockage SAN…)
• coût des potentielles licences (VMware…)
• est-ce adapté pour assurer une sécurité très élevée ? (confiance dans l’isolation offerte par l’hyperviseur et le CPU)