Audit des binaires SUID/SGID : contrôles automatisés des risques et mesures de durcissement

Auditer les binaires SUID/SGID fait partie de tout plan d’exploitation : SUID (Set User ID) et SGID (Set Group ID) permettent à des programmes de s’exécuter avec les droits de leur propriétaire ou de leur groupe – souvent root – même si un utilisateur standard les lance. Cela est fonctionnellement nécessaire pour certains services, mais augmente sensiblement la surface d’attaque. Dans ce guide je décris une procédure pratique et reproductible : inventaire, contrôles de risques automatisés, options de durcissement, intégration dans les pipelines d’exploitation, stratégies de test et de reprise, ainsi que monitoring et gouvernance.

Pourquoi auditer les binaires SUID/SGID?

Les configurations SUID/SGID sont en contradiction avec le principe „Least Privilege“ (les utilisateurs et processus n’obtiennent que les droits strictement nécessaires). Les risques proviennent de :

• de nouveaux paquets ou outils locaux qui livrent involontairement des bits SetID;
• des bugs dans des programmes privilégiés pouvant conduire à une escalation de privilèges locale ou même distante;
• des chemins accessibles en écriture, des bibliothèques ou interprètes manipulés, que peut exploiter un binaire SUID;
• des systèmes de fichiers réseau partagés sans nosuid ou avec une politique root_squash incorrecte.

L’objectif n’est pas de supprimer systématiquement tous les bits SetID, mais une gestion contrôlée : documentée, testée et surveillée en permanence.

Auditer les binaires SUID/SGID : prérequis avant de commencer

Avant le travail technique, clarifiez les questions organisationnelles : responsabilités, workflow de changement, fenêtres de maintenance et capacités de rollback (reconstruction d’image, instantanés). Techniquement, vous devriez savoir :

• Quelles distributions et quels gestionnaires de paquets sont utilisés dans l’environnement (dpkg, rpm) – important pour l’attribution aux paquets et les hooks post-update.
• Si des sauvegardes standard ou des workflows d’images immuables existent, permettant d’annuler des changements.
• Si votre infrastructure utilise du stockage partagé (NFS/SMB) ou des conteneurs/orchestration – les deux influencent le comportement des SetID.

Auditer les binaires SUID/SGID : inventaire reproductible

Une base fiable est un inventaire automatisé, versionné et offrant des possibilités de diff. L’inventaire sert de Single Source of Truth pour la détection de dérive.

Script de scan réutilisable

#!/usr/bin/env bash
set -euo pipefail
out_dir="/var/lib/suid-audit"
mkdir -p "$out_dir"
find / -xdev -type f ( -perm -4000 -o -perm -2000 ) -print0 2>/dev/null 
  | xargs -0 -r stat --format '%n	%a	%U	%G	%s	%Y' 
  | sort > "$out_dir/inventory.raw.tsv"
# Optional: SHA256 hinzufügen (I/O-intensiv)

Remarque : sur des hôtes de grande taille, la charge d’E/S et la durée d’exécution sont à prendre en compte. Planifiez les scans en étages temporels ou via un centre d’images/AMIs, si possible.

Automatiser l’association aux paquets

#!/usr/bin/env bash
set -euo pipefail
inv="/var/lib/suid-audit/inventory.raw.tsv"
out="/var/lib/suid-audit/inventory.withpkg.tsv"
while IFS=$'t' read -r path perm owner group size mtime; do
  pkg="UNKNOWN"
  if command -v dpkg >/dev/null; then
    pkg=$(dpkg -S "$path" 2>/dev/null | head -n1 | cut -d: -f1 || true)
  elif command -v rpm >/dev/null; then
    pkg=$(rpm -qf "$path" 2>/dev/null || true)
  fi
  printf '%st%st%st%st%st%st%sn' "$pkg" "$path" "$perm" "$owner" "$group" "$size" "$mtime"
done < "$inv" | sort > "$out"

Les fichiers avec PACKAGE=UNKNOWN sont particulièrement critiques : ils se trouvent en dehors du cycle de patch normal et nécessitent une priorisation.

Auditer les binaires SUID/SGID : automatisation à l’échelle de l’entreprise

Dans les grands environnements, il est recommandé d’avoir un contrôle centralisé (outils de CM comme Ansible, Salt, Puppet). Le flux de travail consiste en Scan → Score → Ticket → Remediation → Verification. Un simple Ansible-Check-Playbook en exemple :

---
- name: Audit SUID/SGID binaries
  hosts: Linux_servers
  gather_facts: no
  tasks:
    - name: Find suid and sgid files
      find:
        paths: /
        file_type: file
        recurse: yes
        patterns: null
        excludes: /proc,/sys,/dev
        permissions: 4000,2000
      register: suid_files

    - name: Collect entries
      copy:
        dest: /var/lib/suid-audit/{{ inventory_hostname }}.json
        content: "{{ suid_files.files | to_nice_json }}"
      run_once: false

Les artefacts générés peuvent être collectés centralement et injectés dans un système de ticketing/CMDB. Avantage : reproductible et apte à l’audit.

Contrôles de risque automatisés et scoring

La priorisation empêche les équipes Ops d’être submergées par un flot d’entrées. Facteurs de scoring possibles :

• Propriétaire/Groupe (root root pondéré plus fortement) ;
• Chemin : en dehors de /bin /usr/bin /sbin augmente le risque ;
• Attribution au paquet : UNKNOWN pondérée fortement ;
• Écart mtime/hash par rapport à la baseline ou au fichier du paquet ;
• Intégrité du chemin : répertoires world-writable le long du chemin ;
• Fonctionnalité : les binaires qui lancent des shells, manipulent des archives, créent des sockets réseau ou chargent des modules sont à haut risque.

Un score peut être combiné numériquement ; les tickets dépassant un seuil sont dirigés vers une file „Immediate Review“.

Mesures de durcissement : choix, effets et tests

Les mesures importantes doivent toujours être accompagnées de tests et d’une procédure claire de rollback.

Suppression (désinstallation)

La solution la plus propre est de supprimer les paquets inutiles. Vérifiez les dépendances des paquets (« apt rdepends / rpm -q –whatrequires »), informez les responsables métier et effectuez des sauvegardes au préalable.

Retrait des SUID/SGID et test

sudo chmod u-s /usr/local/bin/problematic
# Testen mit User-Account
sudo -u appuser /usr/local/bin/problematic --smoketest
# Falls notwendig, Rollback
sudo chmod u+s /usr/local/bin/problematic

Les cas de test doivent être reproductibles et automatisés (unitaires / tests d’intégration smoke). Prévoyez des métriques observables (temps de réponse, codes de sortie).

Capabilities au lieu de SUID

Les capabilities offrent des droits plus fins que root (p.ex. cap_net_bind_service pour les ports <1024). Exemple :

sudo setcap 'cap_net_bind_service=+ep' /usr/bin/custom-server
getcap /usr/bin/custom-server

Attention : certains systèmes de fichiers (p.ex. certaines implémentations NFS) ne conservent pas ou ne transmettent pas les capabilities de manière fiable. Testez et documentez cela.

nosuid pour les volumes utilisateur

Ajoutez nosuid dans /etc/fstab pour les répertoires où les utilisateurs écrivent (home, volumes d’upload). Exemple :

UUID=xxxx-xxxx  /home  ext4  defaults,nosuid  0  2

Attention aux bind-mounts et à OverlayFS : nosuid peut être contourné par un bind-mount mal conçu. Vérifiez avec findmnt.

Services systemd au lieu d’outils SetUID

Si un processus nécessite des actions privilégiées, un service systemd avec une prise de privilèges contrôlée (PrivateTmp, CapabilityBoundingSet, NoNewPrivileges) peut être plus sûr qu’un binaire SUID. Avantages : journalisation, politiques de redémarrage et propriété claire.

Conteneurs, build-runners et SUID/SGID

Le comportement SUID/SGID dans les conteneurs est particulier : de nombreuses images de conteneurs contiennent des binaires SetID inutiles ; dans Kubernetes, vous devriez auditer les images dès le build (Image-Scanning). Les Build-Runner (CI) ne doivent jamais exécuter de SUID/SGID de manière non contrôlée. Mesures :

• Image-Scanning dans le CI : refuser les builds contenant des SUID/SGID dans l’image de base ou signaler pour revue ;
• Runtime : évitez –privileged ou cap-add sans revue ;
• Externalisez les opérations privilégiées dans des services dédiés et fortement contrôlés.

SELinux und AppArmor: ergänzende Härtung

Les systèmes Mandatory Access Control (MAC) tels que SELinux ou AppArmor renforcent la barrière : même un binaire SUID/SGID vulnérable peut être RESTreint par des politiques SELinux. Utilisez le MAC comme couche de protection additionnelle, et non comme substitut à une politique SetID propre.

Monitoring, Drift-Kontrolle und Integration in SIEM

Un audit n’a de valeur que dans la mesure où l’on peut détecter les changements et y répondre. Recommandations :

• Diffs de baseline réguliers via systemd-timer ou cron ;
• Règles auditd pour les modifications Write/Attr dans les chemins système et pour les appels execve des binaires privilégiés ;
• Centralisation des logs vers le SIEM avec workflows d’alerting pour scores élevés ;
• Tickets automatisés en cas d’écarts dépassant des seuils définis.

Exemple de règle auditd :

# Überwache Write/Attr in /usr/bin und /usr/sbin
auditctl -w /usr/bin -p wa -k suid_sgid_usrbin
auditctl -w /usr/sbin -p wa -k suid_sgid_usrsbin

Reporting, Governance und Compliance

Mettez en place un modèle Owner et Review : chaque binaire SUID/SGID doit avoir un Owner documenté, une Business-Justification, une procédure de test et un intervalle de revue. Générez des rapports avec les champs suivants : Host, Path, Owner, Mode, Package, SHA, Risk-Score, Owner-Approval, Last-Test-Date.

Troubleshooting: typische Fallen und Rückfallstrategie

Reproduzierbare Tests

Avant toute modification : tests smoke automatisés et cas d’acceptation manuels. En cas d’échec, documentez les codes de sortie et les logs, remettez temporairement le bit et analysez les causes.

Paketupdates setzen SUID/SGID zurück

C’est normal : les gestionnaires de paquets remettent les fichiers dans l’état défini par le paquet. Mesures : vérifications post-update, paquet-pinning ou hooks post-installation qui détectent les modifications et créent des tickets.

Shared Storage und root_squash

Sur NFS sans root_squash, un root distant peut escalader des problèmes SUID/SGID. Configurez root_squash sur le serveur NFS, nosuid côté client et vérifiez les options d’export.

Praxis-Checkliste: Runbook für Audit, Härtung und Rückfall

Phase A – Bestandsaufnahme

• Générer un inventaire (chemin, Mode, Owner/Group, mtime, SHA optionnel, association au paquet).
• Versionner la baseline et la stocker dans la CMDB/artefact-store.

Phase B – Bewertung

• Catégoriser et prioriser selon un score.
• Obtenir la confirmation de l’Owner et documenter le Business-Use-Case.

Phase C – Härtung

• Supprimer si possible, sinon retirer SUID/SGID ou les remplacer par des capabilities.
• Appliquer nosuid sur les volumes utilisateur, vérifier les services systemd.

Phase D – Test & Rollback

• Déployer des smoke-tests automatisés, tenir prêts les commandes de rollback (chmod u+s, réinstallation du paquet, chattr -i).
• Définir les fenêtres de maintenance et les procédures d’acceptation.

Phase E – Betrieb

• Diffs réguliers, règles auditd, intégration SIEM et revues périodiques avec confirmations de l’Owner.

Schlussfazit

Auditer les binaires SUID/SGID n’est pas un projet ponctuel, mais un processus opérationnel continu. Inventaire automatisé, un modèle de scoring fiable, intégration aux systèmes CM et de ticketing, chemins de test et de repli clairement définis ainsi que le monitoring via auditd et SIEM réduisent la surface d’attaque sans perturber les opérations nécessaires. La clé est la gouvernance : responsabilités, raisons documentées et revues régulières. Ainsi, l’équilibre entre sécurité et disponibilité est préservé.

Ressources complémentaires et prochaines étapes

Commencez par un groupe pilote (p. ex. dix hôtes représentatifs), générez une baseline, implémentez un scoring et des tickets automatisés pour les priorités >X. Étendez ensuite à l’ensemble du parc et intégrez les builds d’images / pipelines CI.

Auditer les binaires SUID/SGID : exploitation, automatisation et intégration CI/CD

Pour l’exploitation en production, auditer les binaires SUID/SGID va au-delà de la simple détection : il s’agit de changements sûrs et reproductibles, de traçabilité et d’interventions minimales sur la disponibilité. Les modèles opérationnels suivants aident à réduire les risques et à rendre la remédiation automatisable sans provoquer d’indisponibilités en production.

Flux GitOps / Policy-as-Code

Plutôt que des modifications directes sur les hôtes, un modèle de changement basé sur Git est recommandé : le scan génère des artefacts (JSON/TSV) → PR automatique dans un dépôt de politiques → Review & Test → Rollout via orchestrateur (Ansible/Cm/Fleet). Avantage : historique des modifications, protocole de revue et possibilité de rollback simple.

Canary et déploiement progressif

Les modifications des bits SetUID/SetGID devraient être déployées avec une approche canary : d’abord un petit groupe d’hôtes non critiques, tests smoke automatisés, période d’observation, puis extension progressive. En cas de problème : revert automatique du changement de permissions et création automatique d’un ticket.

Exemple : CI‑Gate pour les images (échec du build si SUID/SGID)

# GitLab CI job: fail build if image contains suid/sgid files
suid_check:
  image: docker:latest
  script:
    - docker run --rm -v /:/host:ro alpine:3.12 sh -c "find /host -xdev -type f ( -perm -4000 -o -perm -2000 ) -print | wc -l" | grep -q '^0$'
  tags:
    - privileged
  allow_failure: false

Dans le pipeline CI, au lieu d’un arrêt brutal on peut générer un avertissement et un ticket automatique, en fonction du jeu de données et de l’environnement.

Requêtes live et recherche forensique avec osquery

Pour des analyses ad hoc rapides ou une administration asynchrone, osquery offre une API centrale pour les requêtes de fichiers. Exemple :

SELECT path, uid, gid, mode, sha256 FROM file WHERE mode & 04000 = 04000 OR mode & 02000 = 02000;

Le résultat peut être importé dans Fleet/outils collectifs et enrichi avec des informations CMDB.

Corrélation des logs d’audit : execve et changements de propriétaire

Outre les diffs de baseline, la corrélation des logs d’audit est utile : surveillez les appels execve des binaires privilégiés et les modifications de fichiers le long du chemin. Exemple de recherche avec ausearch :

# Execve-Aufrufe eines gegebenen Binaries suchen
ausearch -k suid_sgid_usrbin -x /usr/bin/problematic --raw | aureport -x --summary

Vous détecterez ainsi tôt les usages inhabituels et pourrez accélérer l’analyse des incidents.

Systèmes de fichiers distribués et particularités

Pour NFS/Gluster/Ceph, attention : nosuid peut se comporter différemment selon l’option de montage et la configuration du serveur ; root_squash, insecure/secure et les options d’export déterminent le risque. Dans les déploiements en cluster, privilégiez des baselines locales vérifiables par hôte et validez que les Capabilities ou les xattr sont transmis correctement.

Remédiation automatisée et sécurisée (Pattern)

• Dry‑Run : la modification ne génère qu’une PR avec le chmod/setcap proposé ;
• Approval : une personne évalue l’impact métier et accepte la PR ;
• Canary : appliquer à un petit groupe, exécuter des smoke tests ;
• Auto‑Rollback : en cas d’échec des tests ou d’alertes, effectuer un revert et ouvrir un ticket.

Cette vision de bout en bout relie l’inventaire, le CI/CD, la forensique et le SIEM et permet de réduire de manière automatisée mais contrôlée les risques SUID/SGID dans de larges environnements.

Pour ce sujet, les bits SUID et SGID sont également importants. L’article met ces aspects en perspective de manière claire et montre ce qui importe au quotidien.