Eseguibili firmati sotto Linux

Question

Per ragioni di sicurezza è opportuno verificare l'integrità del codice prima dell'esecuzione, evitando software manomessi da un aggressore.Quindi, la mia domanda è

Come firmare il codice eseguibile ed eseguire solo software attendibile su Linux?

Ho letto il lavoro di van Doom et al., Progettazione e implementazione di eseguibili firmati per Linux, e quella dell'IBM TLC (Client Linux affidabile) di Safford & Zohar.TLC utilizza il controller TPM, il che è carino, ma il documento è del 2005 e non sono riuscito a trovare alternative attuali.

Conosci altre opzioni?

AGGIORNAMENTO:E riguardo agli altri sistemi operativi?AprireSolaris?Famiglia BSD?

Answer 1

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

Answer 2

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

Ho scritto il supporto per gli eseguibili firmati per il kernel Linux (intorno alla versione 2.4.3) qualche tempo fa e avevo predisposto l'intera toolchain per firmare gli eseguibili, controllando le firme su execve(2) tempo, memorizzare nella cache le informazioni di convalida della firma (cancellare 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à in termini di prestazioni alla prima esecuzione di ogni programma (perché il kernel doveva essere caricato nel file intero file, anziché semplicemente richiedere la pagina delle pagine necessarie), ma una volta che il sistema era in uno stato stazionario, ha funzionato bene.

Ma abbiamo deciso di smettere di perseguirlo perché presentava diversi problemi troppo grandi per giustificarne la complessità:

• Non avevamo ancora creato il supporto per biblioteche firmate.Le librerie firmate richiederebbero anche la modifica del file ld.so caricatore e il dlopen(3) meccanismo.Questo non era impossibile ma complicava 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 proteggerebbe da a strace(2)d processo se questa parte della convalida viene eseguita nello spazio utente?Saremmo costretti a vietarlo strace(2) interamente su un sistema del genere?

  Cosa dovremmo fare? programmi che forniscono il proprio caricatore?

• Moltissimi programmi sono scritti in linguaggi che non vengono compilati in oggetti ELF.Avremmo bisogno di fornire specifico della lingua modifiche a bash, perl, python, java, awk, sed, e così via, affinché ciascuno degli interpreti possa farlo Anche convalidare le firme.Poiché 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 verrebbero conservate le firme?Nelle sceneggiature?Negli attributi estesi?In un database esterno di firme?

• Molti interpreti lo sono spalancata su ciò che consentono; bash(1) può comunicare con sistemi remoti interamente da solo utilizzando echo E /dev/tcp, e può essere facilmente indotto con l'inganno a eseguire qualsiasi operazione di cui un utente malintenzionato ha bisogno.Firmati o no, non potevi fidarti di loro una volta che erano sotto il controllo di un hacker.

• La motivazione principale per il supporto degli eseguibili firmati deriva dai rootkit che sostituiscono quelli forniti dal sistema /bin/ps, /bin/ps, /bin/kill, e così via.Sì, ci sono altri motivi utili per avere eseguibili firmati.Tuttavia, i rootkit sono diventati molto più efficaci nel corso del tempo, e molti ne hanno fatto affidamento nocciolo hack per nascondere le proprie attività agli amministratori.Una volta violato il kernel, il gioco finisce.A causa della sofisticazione 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 molto 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 attorno ai moduli era molto primitiva.

Answer 3

Il modello di GNU / Linux / FOSS in realtà incoraggia manomissione - di una sorta. Utenti e distro-maker devono essere liberi di modificare (manomettere) il software per soddisfare le loro esigenze. Anche solo ricompilare il software (senza modificare il codice sorgente) per la personalizzazione è qualcosa che è fatto abbastanza spesso, ma si rompono binario di firma del codice. Di conseguenza, il modello di firma del codice binario non è particolarmente adatto a GNU / Linux / FOSS.

Al contrario, questo tipo di software si basa più sulle firme di generazione e / o hash sicure dei pacchetti sorgenti. In combinazione con un modello di distribuzione del pacchetto affidabile e di fiducia, questo può essere fatto solo come sicura (se non di più, vis-à-vis la trasparenza nel codice sorgente) come binario di firma del codice.

Answer 4

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

Non è la firma ancora, ma permette comunque di verifica.

Answer 5

posso rispondere alla domanda dal punto di vista Solaris 10 e 11 del sistema operativo, tutti i file binari sono firmati. Per verificare l'utilizzo della firma 'elfsign' ...

$ elfsign verify -v /usr/bin/bash
elfsign: verification of /usr/bin/bash passed.
format: rsa_sha1.
signer: O=Oracle Corporation, OU=Corporate Object Signing, OU=Solaris Signed Execution, CN=Solaris 11.
signed on: Fri Oct 04 17:06:13 2013.

Oracle ha recentemente aggiunto un processo di avvio verificato per Solaris 11 troppo, per i dettagli vedere - Solaris Avvio verificato Introduzione

Ci sono alcune forcelle grado di produzione del codice OpenSolaris, tre la pena indagare sono illumos, SmartOS e OmniOS.

Answer 6

Date un'occhiata a Medusa DS9 . Ho giocato con lui una lunga ( molto ) tempo fa, ma se non ricordo male, è possibile registrare i binari specifici e ogni modifica è stato permesso a livello di kernel. Naturalmente, si può essere sovrascritta con accesso locale alla macchina, ma non è stato davvero facile. C'è un demone intelligente, chiamato poliziotto, controllando tutto ciò che accade sulla macchina e se si verifica qualcosa di fuori dal comune, che inizia a urlare.

Answer 7

Non ho mai provato, ma dare un'occhiata a: http: / /blog.codenoise.com/signelf-digitally-signing-elf-binaries . La soluzione funziona senza bisogno di supporto per il kernel, e sembra di essere pronti ad andare.

Il codice per il firmatario può essere trovato alla http://sourceforge.net/projects/signelf/

Non risolve il "Esegui unico codice di fiducia su linux" questione, ma lo fa in parte risolvere il problema facendo un modo per il programma per rilevare sé una possibile manomissione / corruzione

Answer 8

http://en.wikipedia.org/wiki/PKCS

Usa un PKCS7 (S / MIME) segno di esso. Generare il proprio CERT / coppia di chiavi private, auto-firmare il CERT e poi firmare il file con la chiave privata e cert con PKCS7. Sarà allegare il CERT ad esso, e poi si può controllare se stesso in fase di esecuzione utilizzando il comando openssl (uomo smime o semplicemente fare aiuto openssl). Questo è prova di manomissione perché, anche se la chiave pubblica è nei file che date fuori, la firma S / MIME per quella chiave pubblica può essere generato solo con la chiave privata che non si distribuirà. Quindi, se il file è firmato dal vostro cert, deve essere stato firmato da qualcuno con la chiave privata e dal momento che non ha dato la chiave privata a chiunque, deve provenire da voi.

Ecco come fare il certificato auto-firmato.

http://www.akadia.com/services/ssh_test_certificate.html

Dovrai convincere OpenSSL di fidarti del tuo cert come una radice di autorità (-CAfile), quindi verificare con che come la radice, e di controllare anche il CERT sul file è il proprio (l'hashing del CERT) e controllo l'hash. Si noti che anche se non è documentato, lo stato di uscita di OpenSSL riflette la validità del segno che si sta verificando quando si fa uno SMIME verificare. E '0 se corrisponde, non-zero se non lo fa.

Si noti che tutto questo non è sicuro, perché se il controllo è nel codice, possono semplicemente rimuovere il controllo, se vogliono battere. L'unico modo sicuro per farlo sarebbe quello di avere il controllo del sistema operativo e farlo controllare il vostro binario e si rifiutano di farlo funzionare se non è firmato. Ma dal momento che non ci sono pedine in OS e Linux può essere modificato per rimuovere / bypass comunque ... Che cosa questo è veramente buono per è solo rilevamento dei file corrotti di più che cercare di impedire alla gente di voi bypassando.

Answer 9

Sono d'accordo che la filosofia Linux, GNU ed altri circostante. ruota intorno armeggiare. D'altra parte, credo anche che alcuni sistemi meritano protezione contro le vulnerabilità come il software manomissione, che possono minare la privacy e l'integrità degli utenti di un sistema.

implementazioni kernel non può tenere il passo con il ciclo di sviluppo rapido del kernel stesso. Vi consiglio invece di attuare una forma di verifica della firma file eseguibile utilizzando strumenti userspace. Luogo eseguibili in un'immagine di archivio o del filesystem e firmare l'immagine utilizzando una chiave privata; se quella chiave privata rimane sulla vostra macchina di sviluppo (private), quando il server viene violato, gli aggressori hanno ancora modo di firmare le proprie immagini e iniettare il proprio codice, senza ingannare il sistema per montare le immagini senza segno. Si estende lungo la catena:

• sono i vostri servizi contenuto in sola lettura immagini runtime-montato;
• hanno la macchina scappare di una firma, di sola lettura del file system;
• implementare avvio sicuro sulle macchine, l'esecuzione di un bootloader che impone l'integrità del supporto di avvio;
• fiducia che le persone della tua organizzazione non manomettere le vostre macchine.

Come tutto a destra è uno sforzo difficile. E 'molto più semplice per aggirare il tutto creando il sistema sotto un altro approccio:

• utenti quarantena dal sistema. Non introdurre mezzi per utenti di eseguire comandi sul sistema. Evitare sborsare dall'interno dei programmi che si basano su dati utente-fed.
• progettare i procedure di distribuzione con la gestione della configurazione e garantire che le distribuzioni sono "ripetibili", nel senso che portano allo stesso risultato funzionale quando si distribuisce più volte. Questo permette di "nuke dall'orbita" macchine che si sospetta siano stati compromessi.
• trattare le macchine come se fossero compromessi: eseguire regolarmente controlli per verificare l'integrità dei sistemi. Salvare i dati sulle immagini separate e ridistribuire sistemi regolarmente. Sign Immagini e hanno sistemi rifiutano immagini senza segno.
• uso certificati: favorire un approccio "certificato pinning". Non distribuire un certificato di origine per le applicazioni (che fornirà il rigetto automatico delle firme che non sono stati certificati dalla vostra organizzazione), ma per lo meno avere il sistema di gestione delle impronte digitali di immagini attuali e notificare agli amministratori quando le impronte digitali sono cambiate. Anche se è possibile implementare tutto questo utilizzando catene di chiavi, l'autenticazione basata su certificati è stato progettato per questa applicazione precisa.

Answer 10

Mi piace pensare alla sicurezza come una catena. Il collegamento più debole della catena può compromettere l'intero sistema. Quindi il tutto diventi " impedire ad un utente non autorizzato di ottenere la password di root ".

Come suggerito dal @DanMoulding la sorgente del software è anche importante e in futuro probabilmente negozi ufficiali di applicazione del sistema operativo sarà lo standard. Pensate a Play Store, i negozi Apple o Microsoft.

  

Credo installazione e distribuzione di codice maligno è il segreto   problema molto più insidioso. Dopo tutto, al fine di caricare codice cattivo è   avuto modo di essere prima installato nel sistema da qualche parte. Più strati di   la sicurezza sono di solito meglio, naturalmente. La domanda è: vale la pena   il costo?

A mio parere la risposta è "dipende". È possibile ridurre il rischio attraverso l'adozione di una serie di politiche di sicurezza come suggerito da @sleblanc. È possibile crittografare il file system ( https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup ), utilizzare sola lettura i file system per i binari o utilizzare un meccanismo per firmare e verificare i binari.

Tuttavia qualsiasi meccanismo si utilizza non c'è niente che puoi fare una volta che l'accesso root è ottenuto da un utente malintenzionato. Gli strumenti di verifica della firma può essere sostituito con una versione alterata o semplicemente disabili e non importa se gli strumenti eseguiti in user-space o kernel-space, una volta che la macchina è stata compromessa (anche se quest'ultimo sarebbe più sicura, naturalmente ).

Quindi sarebbe bello se il kernel di Linux potrebbe incorpora un modulo di verifica della firma e un altro strato di sicurezza tra l'utente root e il sistema operativo.

Per esempio, questo è l'approccio adottato sul recente MacOS versioni. Alcuni file non può essere modificato (e talvolta letto) anche da parte l'account di root e non ci sono restrizioni anche sulle politiche e moduli del kernel (per esempio solo firmato o kext autorizzato può essere caricato sul sistema). di Windows ha adottato più o meno lo stesso approccio con AppLocker .