Eseguibili firmati sotto Linux

Mi rendo conto che questa è una domanda antica, ma l'ho trovata solo ora.

Qualche tempo fa ho scritto il supporto per gli eseguibili firmati per il kernel Linux (intorno alla versione 2.4.3) e avevo l'intera toolchain per firmare gli eseguibili, controllando le firme in execve(2) tempo, memorizzare nella cache le informazioni di convalida della firma (cancellando la convalida quando il file è stato aperto per la scrittura o modificato in altro modo), incorporando le firme in programmi ELF arbitrari, ecc. Ha introdotto alcune penalità di prestazioni alla prima esecuzione di ogni programma (poiché il kernel doveva essere caricato intero file, piuttosto che richiedere semplicemente le pagine necessarie) ma una volta che il sistema era in uno stato stazionario, ha funzionato bene.

Ma abbiamo deciso di smettere di perseguirlo perché ha affrontato diversi problemi che erano troppo grandi per giustificare la complessità:

• Non avevamo ancora sviluppato il supporto per le librerie firmate . Le librerie firmate richiederebbero anche la modifica del ld.so caricatore e il dlopen(3) meccanismo. Questo non era impossibile, ma ha complicato l'interfaccia:dovremmo fare in modo che il caricatore chieda al kernel di convalidare una firma o il calcolo dovrebbe essere eseguito interamente nello spazio utente? Come ci si potrebbe proteggere da un strace(2) d se questa parte della convalida viene eseguita nello spazio utente? Saremmo costretti a vietare strace(2) interamente su un tale sistema?

  Cosa faremmo con i programmi che forniscono il proprio caricatore?

• Moltissimi programmi sono scritti in linguaggi che non si compilano in oggetti ELF. Dovremmo fornire lingua specifica modifiche a bash , perl , python , java , awk , sed , e così via, affinché ciascuno degli interpreti possa anche convalidare le firme. Dal momento che la maggior parte di questi programmi sono testo semplice in formato libero, mancano della struttura che ha reso così semplice l'incorporamento delle firme digitali nei file oggetto ELF. Dove sarebbero conservate le firme? Nelle sceneggiature? Negli attributi estesi? In un database esterno di firme?

• Molti interpreti sono completamente aperti su ciò che consentono; bash(1) può comunicare con sistemi remoti completamente da solo utilizzando echo e /dev/tcp , e può essere facilmente indotto a eseguire qualsiasi cosa un utente malintenzionato debba fare. Firmato o no, non potevi fidarti di loro una volta che erano sotto il controllo di un hacker.

• La principale motivazione per il supporto degli eseguibili firmati viene dai rootkit che sostituiscono il /bin/ps fornito dal sistema , /bin/ps , /bin/kill , e così via. Sì, ci sono altri motivi utili per avere eseguibili firmati. Tuttavia, i rootkit sono diventati molto più impressionanti nel tempo, con molti che si affidano al kernel hack per nascondere le loro attività agli amministratori. Una volta che il kernel è stato hackerato, l'intero gioco è finito. A causa della sofisticatezza dei rootkit, gli strumenti che speravamo di impedire venissero utilizzati stavano perdendo il favore della comunità degli hacker.

• L'interfaccia di caricamento dei moduli del kernel era completamente aperta. Una volta che un processo ha root privilegio, è stato facile iniettare un modulo del kernel senza alcun controllo. Avremmo potuto anche scrivere un altro verificatore per i moduli del kernel, ma l'infrastruttura del kernel intorno ai moduli era molto primitiva.

Il modello GNU/Linux/FOSS in realtà incoraggia la manomissione -- in un certo senso. Gli utenti ei produttori di distro devono essere liberi di modificare (manomettere) il software in base alle proprie esigenze. Anche solo ricompilare il software (senza modificare alcun codice sorgente) per la personalizzazione è qualcosa che viene fatto abbastanza spesso, ma interromperebbe la firma del codice binario. Di conseguenza, il modello di firma del codice binario non è particolarmente adatto a GNU/Linux/FOSS.

Invece, questo tipo di software si basa maggiormente sulla generazione di firme e/o hash sicuri dei pacchetti sorgente. In combinazione con un modello di distribuzione dei pacchetti affidabile e fidato, questo può essere reso altrettanto sicuro (se non di più, rispetto alla trasparenza nel codice sorgente) della firma del codice binario.

Il modulo del kernel DigSig implementa la verifica dei binari firmati da uno strumento chiamato bsign . Tuttavia, non c'è stato alcun lavoro su di esso dalla versione 2.6.21 del kernel Linux.

Dai un'occhiata a questo:http://linux-ima.sourceforge.net/

Non sta ancora firmando, ma abilita comunque la verifica.