Linux capabilities¶

Les capabilities Linux découpent les privilèges traditionnellement réservés à root en unités indépendantes, attribuables séparément à des threads ou à des binaires. Un processus ne détient ainsi que les privilèges strictement nécessaires à son fonctionnement, sans avoir à s'exécuter en root complet.

Modèle général¶

Chaque thread possède cinq ensembles (sets) de capabilities indépendants. Les vérifications de permission du kernel s'effectuent uniquement sur le set effective (pE).

           ┌──────────────┐
           │  pB (plafond) │  réductible, jamais augmenté
           └──────┬───────┘
                  │ contraint
  ┌───────────────▼──────────────────┐
  │         pP (permitted)           │
  │  ┌───────────────────────────┐   │
  │  │       pE (effective)      │   │
  │  └───────────────────────────┘   │
  │  ┌──────────┐  ┌──────────────┐  │
  │  │  pI      │  │  pA (ambient)│  │
  │  └──────────┘  └──────────────┘  │
  └──────────────────────────────────┘

File capabilities¶

En plus des sets par thread, les binaires exécutables peuvent porter des capabilities directement dans leurs attributs étendus (security.capability). Le kernel combine les sets du thread parent et ceux du fichier lors d'un execve.

Règle de transition à execve (simplifiée)¶

Après un execve, les nouveaux sets du thread sont calculés ainsi :

pP' = (fP & pB) | (fI & pI) | pA
pE' = pP'  si fE est positionné, sinon pE' = pA
pI' = pI
pA' = pA  (perdu si le binaire est setuid ou porte des file capabilities)

Inspection et manipulation¶

Voir les capabilities d'un processus¶

# Ses propres capabilities (capabilities du shell courant)
grep -E 'Cap(Inh|Prm|Eff|Bnd|Amb)' /proc/self/status

# D'un processus par son PID
grep -E 'Cap' /proc/1234/status

# Lecture lisible avec capsh
capsh --decode=$(grep CapEff /proc/self/status | awk '{print $2}')

# capsh affiche tous les sets du shell courant
capsh --print

Voir les file capabilities d'un binaire¶

# Un binaire
getcap /usr/bin/ping

# Audit de tous les binaires du système
sudo getcap -r / 2>/dev/null

Attribuer des file capabilities¶

# Donner cap_net_raw à ping (remplace le bit setuid)
sudo chmod u-s /usr/bin/ping
sudo setcap cap_net_raw=+ep /usr/bin/ping

# tcpdump : capture réseau sans root
sudo setcap 'cap_net_admin,cap_net_raw=ep' /usr/sbin/tcpdump

# Service HTTP sur port 80 sans root
sudo setcap cap_net_bind_service=+ep /usr/local/bin/mon-serveur

# Supprimer toutes les file capabilities
sudo setcap -r /usr/bin/ping

Notation de setcap¶

La syntaxe de setcap est :

cap_nom[,cap_nom...]=(e|i|p)[+|-]

Exemple : cap_net_bind_service=+eip active les trois sets pour ce fichier.

Ambient capabilities¶

Les ambient capabilities (pA) résolvent le cas fréquent d'un service qui exécute un script ou un binaire secondaire non setuid et doit lui transmettre certains privilèges sans modifier le binaire.

Conditions d'utilisation¶

Une capability peut être ajoutée dans pA seulement si elle est déjà dans pP et dans pI. Elle est automatiquement supprimée de pA si le processus exécute un binaire setuid ou un binaire portant des file capabilities.

Via prctl (code C)¶

// Ajouter CAP_NET_ADMIN dans le set ambient
prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_NET_ADMIN, 0, 0);

// Supprimer une ambient capability
prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_LOWER, CAP_NET_ADMIN, 0, 0);

// Vider le set ambient
prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_CLEAR_ALL, 0, 0, 0);

Via capsh (expérimentation shell)¶

# Ouvrir un sous-shell avec cap_net_admin en ambient
sudo capsh \
  --caps='cap_net_admin+eip' \
  --keep=1 \
  --user=unpriv \
  --addamb=cap_net_admin \
  -- -c 'capsh --print'

Intégration systemd¶

systemd expose directement les capability sets dans les unités de service, ce qui évite de modifier les binaires.

[Service]
User=unpriv

# Restreindre le bounding set : le service ne peut jamais acquérir
# de capabilities en dehors de cette liste
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMIN

# Remplir le set ambient : transmis à tous les exec() du service
# (doit être un sous-ensemble de CapabilityBoundingSet)
AmbientCapabilities=CAP_NET_BIND_SERVICE

# Interdire toute élévation de privilèges via setuid ou file caps
NoNewPrivileges=yes

ExecStart=/usr/local/bin/mon-daemon

Correspondance sets systemd → thread¶

Référence des capabilities importantes¶

Système de fichiers¶

Processus et utilisateurs¶

Réseau¶

Kernel et système¶

Sécurité et audit¶

Capabilities et namespaces (containers)¶

Dans un user namespace ou un réseau namespace, certaines capabilities donnent des droits uniquement à l'intérieur du namespace, sans affecter l'hôte.

# Créer un user namespace sans aucun privilège hôte
unshare --user --map-root-user --net bash

# Dans le namespace, on est "root" mais les capabilities
# sont limitées à ce namespace
capsh --print

Diagnostics courants¶

Vérifier pourquoi une opération échoue avec EPERM¶

# Identifier quelle capability serait nécessaire
strace -e trace=all commande 2>&1 | grep EPERM

# Afficher les sets du processus courant de manière lisible
capsh --print

# Décoder la valeur hexadécimale de /proc/PID/status
capsh --decode=$(grep CapEff /proc/self/status | awk '{print $2}')

Auditer les binaires avec des file capabilities¶

# Lister tous les binaires avec des capabilities sur le système
sudo getcap -r / 2>/dev/null

# Filtrer les binaires setuid (complémentaire)
find / -perm /4000 -type f 2>/dev/null

Vérifier les capabilities d'un service systemd¶

# Voir les capabilities effectives du processus principal d'un service
systemctl show mon-service.service -p MainPID --value | \
  xargs -I{} sh -c 'grep Cap /proc/{}/status'

# Via systemd directement
systemctl show mon-service.service -p CapabilityBoundingSet

Tester un bounding set réduit avec capsh¶

# Simuler un service avec uniquement cap_net_bind_service
sudo capsh \
  --drop=cap_sys_admin,cap_setuid,cap_setgid \
  --caps='cap_net_bind_service+eip' \
  -- -c 'capsh --print && mon-binaire'

Bonnes pratiques¶

• Principe du moindre privilège : identifier précisément quelle capability est nécessaire avant d'en accorder une. La page man 7 capabilities décrit opération par opération ce que couvre chaque capability.
• Éviter CAP_SYS_ADMIN : si un service en a besoin, analyser laquelle de ses sous-opérations est réellement utilisée — il existe souvent une capability plus fine.
• Préférer les directives systemd aux file capabilities quand c'est possible : les directives sont versionables, auditables et n'affectent pas le binaire sur disque.
• Toujours combiner avec NoNewPrivileges=yes dans systemd : empêche qu'un fils exec() d'un service récupère des privileges supplémentaires via setuid ou file capabilities.
• Auditer régulièrement avec getcap -r / : les mises à jour de packages peuvent réinstaller des binaires sans conserver les file capabilities, ou au contraire en ajouter.
• Méfiance dans les containers : CAP_NET_ADMIN dans un netns isolé ne donne pas accès au réseau hôte, mais CAP_SYS_ADMIN dans un container mal configuré peut le faire sortir de son isolation.

Voir aussi¶

• systemd-nspawn — containers légers et gestion des capabilities
• systemd.exec — directives CapabilityBoundingSet=, AmbientCapabilities=, NoNewPrivileges=
• man 7 capabilities — référence complète avec toutes les capabilities et les règles de transition
• man 8 setcap et man 8 getcap — manipulation des file capabilities
• man 1 capsh — shell avec capabilities réduites, outil de test
• man 2 prctl — API noyau pour manipuler les sets depuis le code
• Slides Michael Kerrisk — The Linux capabilities model