Creare uno snapshot prima di iniziare e mantenere aperta una console root.

1. Prerequisiti

Servono Clang con target BPF, bpftool, libbpf, libelf, zlib, pkg-config, g++ e make. Il kernel della VM deve esporre /sys/kernel/btf/vmlinux e avere BPF LSM abilitato.

./scripts/check-environment.sh

Nell'elenco /sys/kernel/security/lsm deve comparire bpf. Lo script mostra anche lockdown, BPF non privilegiato, firma moduli, IMA/EVM e fs-verity: i primi requisiti sono bloccanti, gli altri sono avvisi di hardening.

2. Build e test parser

make test

make

3. Installazione policy sicura

sudo install -d -m 0755 /etc/bastionguard /var/log/bastionguard
sudo install -o root -g root -m 0600 config/rootguard.conf \
  /etc/bastionguard/rootguard.conf

4. Prima esecuzione: audit

sudo ./build/bastionguard-rootguard \

--policy /etc/bastionguard/rootguard.conf

Eseguire normali operazioni sudo, su o pkexec e verificare che siano classificate come TRUSTED.

5. Probe setuid innocuo

sudo ./scripts/prepare-vm-probe.sh

/opt/bastionguard-rootguard-test/unknown-setuid-test

In audit deve comparire un evento AUDIT per eseguibile sconosciuto.

6. Probe dei metadati

sudo ./scripts/prepare-metadata-probe.sh

Aggiungere alla policy e ricaricare:

[protected-paths]
required_path = /opt/bastionguard-rootguard-test/protected-metadata.txt
# Per testare anche l'espansione di directory:
recursive_path = /opt/bastionguard-rootguard-test

In audit, questi comandi devono riuscire ma produrre eventi:

sudo chmod 0666 /opt/bastionguard-rootguard-test/protected-metadata.txt
sudo chmod 0644 /opt/bastionguard-rootguard-test/protected-metadata.txt
sudo chown nobody:nobody /opt/bastionguard-rootguard-test/protected-metadata.txt
sudo chown root:root /opt/bastionguard-rootguard-test/protected-metadata.txt
sudo ln /opt/bastionguard-rootguard-test/protected-metadata.txt \
  /opt/bastionguard-rootguard-test/protected-metadata.link
sudo rm -f /opt/bastionguard-rootguard-test/protected-metadata.link

Il controllo periodico deve inoltre produrre integrity-drift dopo una modifica e integrity-restored quando mode e owner tornano alla baseline. Creare un nuovo file dentro una directory ricorsiva richiede un reload per inserirne il nuovo inode nella baseline; prima del reload resta coperto soltanto il monitoraggio globale dei metadati privilegiati.

7. Enforcement

Dopo avere ripristinato baseline e policy:

mode = enforce
unknown_action = block
metadata_action = block
global_metadata_action = block
credential_anomaly_action = block

Ricaricare con SIGHUP. Il probe setuid sconosciuto deve fallire con EPERM. Sul file protetto, chmod, chown, setfacl, setcap, rm, mv e la creazione di hardlink devono essere rifiutati quando attraversano gli hook coperti. sudo e gli altri eseguibili trusted devono continuare a funzionare.

8. Aggiornamenti e recovery

Prima di aggiornare pacchetti che sostituiscono file protetti:

portare metadata_action, global_metadata_action e, preferibilmente, mode in audit;
ricaricare la policy;
eseguire l'aggiornamento;
ricaricare nuovamente la policy per acquisire i nuovi inode;
riattivare l'enforcement.

In caso di policy errata:

sudo systemctl stop bastionguard-rootguard

La chiusura del daemon distrugge i link BPF e rimuove l'enforcement.

9. Test controllato della corruzione credenziali

Usare soltanto una VM isolata e sacrificabile, senza rete o dati reali. Con un PoC già noto e mantenuto privatamente dal ricercatore, verificare separatamente:

audit: il task nasce non-root, appare UID/EUID 0 senza transizione riconosciuta e deve produrre credential-anomaly;
enforcement: il primo uso di una capability, apertura/controllo permessi o modifica dei metadati deve ricevere EPERM;
controllare che PID/TGID/PPID, UID baseline, operazione e inode siano nel log;
ripetere con credential_anomaly_action=audit per distinguere detection da prevention;
misurare latenza e overhead di inode_permission sotto carico I/O.

Non esiste un test generico sicuro che dimostri resistenza a ogni exploit kernel. Un exploit con scrittura arbitraria può manomettere RootGuard, le mappe BPF o i risultati restituiti al daemon; i risultati devono quindi indicare il PoC, il kernel, la configurazione e gli hook effettivamente attraversati.

10. Test di manomissione fuori dagli hook

Per simulare la parte rilevabile dal controllo periodico, fermare temporaneamente RootGuard, modificare mode/owner o sostituire un file di prova, quindi riavviare con la stessa baseline solo in audit. Il daemon deve produrre integrity-drift. Questo test verifica il rilevamento userspace, non dimostra che una scrittura arbitraria nel kernel non possa falsificare stat(2).