Audit dei binari SUID/SGID: controlli di rischio automatizzati e misure di hardening

Auditare i binari SUID/SGID fa parte di ogni piano operativo: SUID (Set User ID) e SGID (Set Group ID) consentono ai programmi di essere eseguiti con i privilegi del loro proprietario o del loro gruppo – spesso root – anche quando vengono avviati da un utente normale. Questo è funzionalmente necessario per alcuni servizi, ma aumenta significativamente la superficie d’attacco. In questa guida descrivo una procedura pratica e riproducibile: inventario, controlli di rischio automatizzati, opzioni di hardening, integrazione nelle pipeline operative, strategie di test e rollback, oltre a monitoraggio e governance.

Perché auditare i binari SUID/SGID?

Le configurazioni SUID/SGID sono in contrasto con il principio del „Least Privilege“ (gli utenti e i processi ricevono solo i privilegi strettamente necessari). I rischi derivano da:

• pacchetti nuovi o strumenti locali che forniscono inaspettatamente i bit SetID;
• bug in programmi privilegiati che possono portare a escalation di privilegi locali o persino remote;
• percorsi scrivibili, librerie o interpreter manipolati che possono essere sfruttati da un binario SUID;
• filesystem di rete condivisi senza nosuid o con una politica root_squash configurata in modo errato.

L’obiettivo non è rimuovere indiscriminatamente tutti i bit SetID, ma gestirli in modo controllato: documentato, testato e monitorato in modo continuativo.

Auditare i binari SUID/SGID: prerequisiti prima di iniziare

Prima di iniziare il lavoro tecnico chiarite le questioni organizzative: responsabilità, workflow di change, finestre di manutenzione e capacità di rollback (Image-Rebuild, Snapshots). Dal punto di vista tecnico dovreste sapere:

• quali distribuzioni e gestori di pacchetti sono in uso nell’ambiente (dpkg, rpm) – importante per l’associazione ai pacchetti e i post-update hook.
• se esistono backup standard o workflow basati su immagini immutabili che permettono di annullare le modifiche.
• se la vostra infrastruttura utilizza storage condiviso (NFS/SMB) o container/orchestratori – entrambi influenzano il comportamento dei SetID.

Auditare i binari SUID/SGID: inventario riproducibile

Una base solida è un inventario automatizzato, versionato e con possibilità di diff. L’inventario funge da Single Source of Truth per il rilevamento della drift.

Script di scansione riutilizzabile

#!/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)

Nota: su host di grandi dimensioni bisogna considerare il carico I/O e i tempi di esecuzione. Pianificate le scansioni in modo sfalsato nel tempo o tramite Image/AMI-Center, se possibile.

Automatizzare l’associazione ai pacchetti

#!/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"

I file con PACKAGE=UNKNOWN sono particolarmente critici: si trovano al di fuori del normale ciclo di patch e richiedono priorità.

Auditare i binari SUID/SGID: automazione su scala aziendale

In ambienti di grandi dimensioni è consigliabile un controllo centralizzato (CM-Tools come Ansible, Salt, Puppet). Il flusso di lavoro consiste in Scan → Score → Ticket → Remediation → Verification. Un semplice Ansible-Check-Playbook a titolo di esempio:

---
- 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

Gli artefatti generati possono essere raccolti centralmente e iniettati in un sistema di ticketing/CMDB. Vantaggio: riproducibile e verificabile ai fini di audit.

Controlli di rischio e scoring automatizzati

La priorizzazione evita che le operation (Ops) vengano sommerse da un flusso di voci. Possibili fattori di scoring:

• Owner/Group (root root con peso maggiore);
• Percorso: al di fuori di /bin /usr/bin /sbin aumenta il rischio;
• Assegnazione al pacchetto: UNKNOWN con forte peso;
• Deviazione di mtime/hash rispetto alla baseline o al file del pacchetto;
• Integrità del percorso: directory world-writable lungo il percorso;
• Funzionalità: i binari che invocano shell, archiviano, aprono socket di rete o caricano moduli sono ad alto rischio.

I punteggi possono essere combinati numericamente; i ticket con valore superiore a una soglia vengono instradati in una coda „Immediate Review“.

Misure di hardening: scelta, effetto e test

Le misure importanti devono essere sempre accompagnate da test e da una chiara procedura di rollback.

Rimozione (disinstallazione)

La soluzione più pulita è rimuovere i pacchetti non necessari. Verificate le dipendenze dei pacchetti („apt rdepends / rpm -q –whatrequires“), informate i responsabili di business e eseguite backup preventivi.

Rimuovere SUID/SGID e 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

I casi di test devono essere riproducibili e automatizzati (Unit/Integration smoke tests). Pianificate metriche osservabili (response time, exit codes).

Capabilities invece di SUID

Le capabilities concedono privilegi più fini rispetto a root (es. cap_net_bind_service per le porte <1024). Esempio:

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

Attenzione: alcuni file system (es. specifiche implementazioni NFS) non memorizzano o trasmettono le capabilities in modo affidabile. Testate e documentate questo comportamento.

nosuid per i volumi utente

Impostate nosuid in /etc/fstab per le directory in cui gli utenti scrivono (home, volumi di upload). Esempio:

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

PRESTate attenzione a bind-mount e OverlayFS: nosuid può essere aggirato da un bind-mount mal progettato. Controllate con findmnt.

Servizi systemd invece di strumenti SetUID

Se un processo richiede azioni privilegiate, un servizio systemd con assunzione di privilegi controllata (PrivateTmp, CapabilityBoundingSet, NoNewPrivileges) può essere più sicuro di un binary SUID. Vantaggi: logging, RESTart-Policies e ownership chiara.

Container, Build-Runners e SUID/SGID

Il comportamento SUID/SGID nei container è particolare: molte immagini container contengono binari SetID non necessari; in Kubernetes è consigliabile sottoporre le immagini container ad audit già in fase di build (image scanning). I build-runner (CI) non devono mai eseguire SUID/SGID in modo incontrollato. Misure:

• Image-Scanning nel CI: rifiutare build con SUID/SGID nell’immagine base o segnalarli per revisione;
• Runtime: evitare –privileged o cap-add senza revisione;
• Esternalizzare le operazioni privilegiate in servizi dedicati e fortemente controllati.

SELinux und AppArmor: ergänzende Härtung

I sistemi Mandatory Access Control (MAC) come SELinux o AppArmor aumentano la barriera: anche un binario SUID/SGID con vulnerabilità può essere limitato dalle policy di SELinux. Utilizzate il MAC come ulteriore involucro protettivo, non come sostituto di una policy SetID pulita.

Monitoring, Drift-Kontrolle und Integration in SIEM

Un audit è valido solo quanto la capacità di rilevare cambiamenti e reagire. Raccomandazioni:

• Diff di baseline regolari via systemd-timer o cron;
• Regole auditd per modifiche write/attr in percorsi di sistema e per chiamate execve a binari privilegiati;
• Centralizzazione del forwarding dei log in SIEM con workflow di alerting per punteggi elevati;
• Ticket automatici su deviazioni oltre soglie definite.

Esempio di regola 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

Implementate un modello proprietario e di revisione: ogni binario SUID/SGID deve avere un proprietario documentato, una giustificazione aziendale, una procedura di test e un intervallo di revisione. Generate report con i seguenti campi: Host, Percorso, Proprietario, Modalità, Pacchetto, SHA, Punteggio di rischio, Approvazione del proprietario, Data dell’ultimo test.

Troubleshooting: typische Fallen und Rückfallstrategie

Reproduzierbare Tests

Prima di qualsiasi modifica: test smoke automatizzati e casi di accettazione manuali. Se qualcosa fallisce, documentate i codici di uscita e i log, ripristinate temporaneamente il bit e analizzate le cause.

Paketupdates setzen SUID/SGID zurück

Questo è normale: i package manager riportano i file allo stato definito dal pacchetto. Misure: controlli post-update, pinning dei pacchetti o hook post-install che rilevino modifiche e generino ticket.

Shared Storage und root_squash

Su NFS senza root_squash gli utenti root remoti possono sfruttare problemi SUID/SGID per escalation. Abilitate root_squash sul server NFS, impostate nosuid sui client e verificate le opzioni di export.

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

Phase A – Bestandsaufnahme

• Creare inventario (percorso, modalità, proprietario/gruppo, mtime, SHA opzionale, associazione al pacchetto).
• Versionare la baseline e conservarla in CMDB/archivio degli artefatti.

Phase B – Bewertung

• Catalogare e prioritizzare basandosi su score.
• Conferma del proprietario e documentazione del caso d’uso aziendale.

Phase C – Härtung

• Rimuovere se possibile; altrimenti rimuovere i bit SUID/SGID o sostituirli con capabilities.
• Impostare nosuid sui volumi utente, verificare i servizi systemd.

Phase D – Test & Rollback

• Eseguire smoke test automatizzati, avere pronti i comandi di rollback (chmod u+s, reinstall del pacchetto, chattr -i).
• Definire finestra di manutenzione e criteri di accettazione.

Phase E – Betrieb

• Diff regolari, regole auditd, integrazione SIEM e revisioni periodiche con conferme del proprietario.

Conclusione

Auditare i binari SUID/SGID non è un progetto una tantum, ma un processo operativo continuo. Inventario automatizzato, un modello di scoring affidabile, integrazione con sistemi CM e di ticketing, percorsi di test e rollback documentati e monitoraggio tramite auditd e SIEM riducono la superficie di attacco senza compromettere le operazioni necessarie. Cruciale è la governance: responsabilità (ownership), motivazioni documentate e revisioni regolari. In questo modo si mantiene l’equilibrio tra sicurezza e disponibilità.

Weiterführende Ressourcen und nächste Schritte

Avviate con un gruppo pilota (ad es. dieci host rappresentativi), generate una baseline, implementate lo scoring e ticket automatizzati per priorità >X. Estendete poi all’intera flotta e integrate i processi di Image-Build/CI-Pipelines.

SUID/SGID-Binaries auditieren: Betrieb, Automatisierung und CI/CD‑Integration

Per l’esercizio in produzione l’audit dei binari SUID/SGID va oltre il semplice rilevamento: si tratta di modifiche sicure e riproducibili, tracciabilità e interventi minimi sulla disponibilità. I seguenti pattern operativi aiutano a ridurre i rischi e a rendere la remediation automatizzabile senza causare downtime di produzione.

GitOps‑/Policy‑as‑Code‑Workflow

Invece di applicare modifiche dirette sugli host è preferibile un modello di cambiamento basato su Git: lo scan genera artefatti (JSON/TSV) → PR automatico su un policy‑repo → Review & Test → rollout tramite orchestrator (Ansible/Cm/Fleet). Vantaggi: storia delle modifiche, registro delle review e possibilità di rollback semplice.

Canary und stufenweiser Rollout

Le modifiche ai bit SetID dovrebbero essere introdotte con approccio canary: prima un piccolo gruppo di host non critici, smoke test automatizzati, periodo di osservazione e poi estensione graduale. In caso di problemi: revert automatico della modifica dei permessi e apertura del ticket.

Beispiel: CI‑Gate für Images (Build‑Fail bei 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

Nel CI, al posto di un arresto netto, si può generare un avviso e creare automaticamente un ticket, a seconda del dataset e dell’ambiente.

Live‑Querying und forensische Suche mit osquery

Per analisi ad hoc rapide o gestione asincrona osquery fornisce un’API centrale per interrogazioni sui file. Esempio:

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

Il risultato può essere importato in Fleet/strumenti collettivi e arricchito con informazioni dalla CMDB.

Audit‑Log‑Korrelation: execve und Owner‑Changes

Oltre ai diff di baseline, la correlazione dei log di audit è utile: monitorate le chiamate execve dei binari privilegiati e le modifiche ai file lungo i percorsi. Esempio di ricerca con ausearch:

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

In questo modo si individuano precocemente pattern di utilizzo anomali e si accelera l’analisi degli incidenti.

Distributed Filesystems und Besonderheiten

Per NFS/Gluster/Ceph da considerare: nosuid può comportarsi in modo diverso a seconda delle opzioni di mount e della configurazione del server; root_squash, insecure/secure e le opzioni di export determinano il livello di rischio. Nei setup di cluster preferire baseline locali verificabili per host e convalidare se le Capabilities o gli xattr vengano trasmessi correttamente.

Remediation automatizzata e sicura (Pattern)

• Dry‑Run: Change genera solo una PR con il chmod/setcap proposto;
• Approval: una persona verifica l’impatto sul business e accetta la PR;
• Canary: applicare a un gruppo ristretto, eseguire Smoke Tests;
• Auto‑Rollback: in caso di errori nei test o alert eseguire il revert e aprire un ticket.

Questa visione end‑to‑end collega inventario, CI/CD, analisi forense e SIEM e consente di ridurre i rischi SUID/SGID in grandi ambienti in modo automatizzato ma controllato.

Per questo argomento sono importanti anche il Suid Bit e il Sgid Bit. Il contributo inquadra questi aspetti in modo comprensibile e mostra a cosa prestare attenzione nella pratica quotidiana.