Se sì, quali sono questi sistemi operativi? Sono appositamente realizzati? Quanto è difficile applicare questo tipo di verifica del programma ai sistemi operativi di tutti i giorni che usiamo?
In caso negativo, perché la gente non ha inventato tali sistemi operativi?
La verifica della firma del pacchetto è abbastanza comune con i gestori di pacchetti di oggi. Quello che sto chiedendo è la verifica della firma al momento del caricamento.
iOS e Android convalidano entrambi la firma di ogni singolo pezzo di codice prima di caricarli in memoria.
Anche le app UWP di Windows vengono controllate per la firma prima di essere caricate.
Package signature verification is quite common with today's package managers. What I'm asking about is signature verification at loading time.
La differenza è enorme in termini di prestazioni. Una firma del pacchetto viene controllata quando viene installata e non in seguito.
Per essere efficace, la firma del codice deve essere controllata per ogni binario prima che venga eseguito o caricato.
Inoltre, il sistema operativo (o l'ambiente di runtime) deve prestare particolare attenzione per assicurarsi che una pagina di memoria contrassegnata come eseguibile sia firmata (o, almeno, che sia stata caricata da qualcosa che è stato firmato correttamente). Tali requisiti sono estremamente difficili da applicare su qualsiasi ambiente che non è stato progettato con la firma del codice in mente perché tende a rompere un sacco di codice legacy.
Perché non tutti i sistemi operativi verificano la firma dei programmi? Semplicemente perché nei primi tempi, la maggior parte dei programmi sono stati scritti e compilati localmente e, al giorno d'oggi, alcune applicazioni aziendali sono specificamente sviluppate localmente. Molti programmi di alta qualità vengono distribuiti come sorgente e possono essere compilati localmente. Spesso ha senso nei server ad alte prestazioni poiché le opzioni di compilazione possono essere utilizzate per modificare un programma per esigenze specifiche. Se potessi utilizzare solo eseguibili firmati da fonti conosciute, tutto ciò non sarebbe possibile.
Ovviamente per un sistema operativo destinato agli utenti finali come Android o iOS le cose vanno diversamente, e ha senso consentire solo l'eseguibile installato da fonti ben conosciute.
Ma anche sul mio Windows box, sarei molto deluso se non potessi scrivere, compilare ed eseguire un programma in C o C ++ ...
Un esempio utilizzato occasionalmente negli ambienti di istruzione e aziendali è AppLocker , che può limitare l'esecuzione dell'applicazione a una whitelist basata su attributi definiti dall'amministratore, incluso il nome dell'editore da una firma o l'hash di un file specifico.
Il problema più grande è ovviamente il sovraccarico amministrativo, dovendo in particolare autorizzare tutti i programmi di cui un utente potrebbe aver bisogno. Inoltre, molti editori non firmano le loro applicazioni. E naturalmente non è una soluzione infallibile - ad es. un bug in un programma whitelist potrebbe ancora essere sfruttato per eseguire codice arbitrario 1 .
In realtà, la firma dell'eseguibile non è nemmeno la parte importante. La whitelist può essere implementata dal percorso per tutte le differenze che fa: ciò che è importante in questo schema è che l'utente non ha permessi di scrittura nella directory del programma 2 . Supponendo che sia vero, quale vantaggio offre la verifica in fase di esecuzione oltre la verifica al momento dell'installazione? Nessuno può cambiare il programma installato. Se il vettore di attacco è la modifica offline dei file, la crittografia del disco completo è la risposta corretta.
1 La maggior parte di questi bug non sarebbe considerata grave in un ambiente normale, dove non porterebbe ad un'escalation dei privilegi. W ^ X può ancora essere bypassato con POR .
2 Anche la verifica della firma dell'eseguibile mancherà di moduli esterni (ad esempio librerie con collegamenti dinamici) per impostazione predefinita. L'attivazione di può avere impatti significativi sulle prestazioni .
Linux ha già i meccanismi necessari nel kernel (dalla versione 3.7), chiamato IMA :
The goals of the kernel integrity subsystem are to detect if files have been accidentally or maliciously altered, both remotely and locally, appraise a file's measurement against a "good" value stored as an extended attribute, and enforce local file integrity. These goals are complementary to Mandatory Access Control (MAC) protections provided by LSM modules, such as SElinux and Smack, which, depending on policy, can attempt to protect file integrity.
Con IMA, i file sensibili possono essere etichettati come "immutabili" (che è ciò che si farebbe con i file eseguibili), che li firma con una speciale chiave RSA. La firma viene convalidata all'accesso ai file, impedendo la manomissione offline. L'esecuzione di file che non sono immutabili può essere vietata tramite le politiche di SElinux.
Naturalmente, l'usabilità di tale sistema è ridotta. Per creare ed eseguire i propri file su tale sistema, è necessario disporre di una chiave privata attendibile per firmarli prima. È probabile che gli aggiornamenti del software richiedano un riavvio per aggiornare i file immutabili prima che vengano bloccati.
La verifica del tempo di caricamento è molto costosa e non infallibile.
Are there any OSes that verify program signatures before executing them?
EDIT : come indicato nei commenti, tali sistemi operativi. ChromeOS per es.
If so, what are these OSes? Are they specially crafted? How difficult is it to apply this kind of program verification to the everyday OSes we use?
È abbastanza difficile verificare un programma al momento del caricamento. Inoltre, anche se lo si esegue correttamente, una volta avviato il programma, l'autore dell'attacco può ancora fornire input non validi e causare problemi (overflow del buffer). Detto questo, ci sono moduli software che verificano le loro firme al momento del caricamento (attestazione del software, ad esempio OpenSSL conforme ai FIPS). Avere un sistema operativo farlo per ogni singolo processo è molto costoso.
Poiché l'attenzione si sposta verso il cloud computing, vorrai assicurarti di essere in grado di eseguire software di elevata sicurezza anche su sistemi non attendibili. Direi che non verranno fatte molte ricerche sulla protezione del sistema dal software in esecuzione. Invece, l'attenzione sarà più concentrata sul calcolo affidabile anche in un ambiente non affidabile. Puoi avere una catena di fiducia di base come l'attestazione del sistema o del software (fai riferimento al link in basso) se vuoi al momento del caricamento. L'importante è garantire che il software non venga compromesso in fase di esecuzione.
Guarda questa discussione: Un programma interpretato in esecuzione può dimostrare crittograficamente che è la stessa di una versione di codice sorgente pubblicata?
Molte risposte menzionano sistemi operativi generali con supporto relativamente recente, ma non vedo alcun riferimento ai TPM e al Trusted Computing Group . Un TPM fornisce l'hardware minimo necessario per eseguire l'esecuzione firmata con una catena di integrità dall'avvio del firmware come un modulo di scheda madre di livello consumer standardizzato. Funziona consentendo alle fasi di avvio di estendere i registri di hash con le misurazioni di ogni fase successiva prima dell'esecuzione e quindi di fornire un meccanismo di memorizzazione dei blocchi bloccato che può essere condizionale su questi valori di registro hash.
Con il TPM che risolve il problema di Chicken and Egg per PKI e avvio anticipato, l'accesso alle risorse potrebbe essere limitato al software consentito in una politica specifica fino a che punto tale codice fosse a sua volta libero da exploit. Senza un avvio verificato, il controllo della firma in fase di runtime non ha alcun senso, senza alcun motivo per ritenere che il sistema PKI e il criterio non siano modificati.
A mia conoscenza (che non è attuale), solo Apple e Google hanno avuto abbastanza controllo delle loro piattaforme hardware per sperimentare TPM on-by-default e non penso che abbiano implementato uno stile completo di TCG di avvio verificato. Ma la minaccia di essere lasciati indietro da un'improvvisa diffusione di questi nuovi dispositivi ha spinto i produttori di sistemi operativi a iniziare a implementare alcuni componenti di integrità del runtime.
In primo luogo, sono chiaramente un non esperto su tutto ciò che sto per dire, quindi sii cauto ...
Nel mondo del software libero in cui vivo, le persone stanno lavorando su build riproducibili . L'obiettivo è che ogni binario scaricato possa essere verificato dall'utente stesso, beh, costruendolo. Molti distribuzioni e progetti software sono interessati a questo. Se ricordo bene, questa idea è stata avviata dai bitcoin people e seguita dal progetto tor.
Da quanto ho sentito, alcune persone hanno suggerito dopo che un numero sufficiente di pacchetti sono riproducibili, l'hash potrebbe essere condiviso in alcuni modi p2p. Quindi, per rispondere alla tua domanda, secondo le mie opinioni, al momento del caricamento, un verificatore può semplicemente eseguire l'hash del file binario e controllare se corrisponde all'hash pubblicato dagli altri, sebbene possa essere lento a seconda della velocità della connessione Internet (forse la connessione deve andare attraverso tor).
Inoltre, mi capita di conoscere 2 distro più di altre, quindi le elaborerò di più con loro:
Da quanto ho sentito, Debian renderà riproducible-build un requisito di policy dopo che un numero sufficiente di pacchetti è riproducibile.
Guix implementa il comando guix challenge in modo che sia possibile verificare l'hash della tua build locale con build ufficiale su Hydra.
Non sono un 'esperto' ma solo un utente comune di alcuni strumenti.
Condivido le build riproducibili un po 'di più e in quanto i commenti non erano il posto giusto, quindi la condivisione qui. Da quel poco che ho capito, usato e sperimentato, quello che fa ti dà un pacchetto .deb insieme a un file di testo .buildinfo. Il file di testo buildinfo avrà nomi e numeri di versione di tutte le librerie che erano necessarie nell'ambiente di compilazione per creare il binario.
Quindi se sei sospettoso riguardo un pacchetto binario (dall'archivio o anche esterno) che ha il file di testo buildinfo, può o non può essere trivia per testare i pacchetti ricreando l'ambiente di compilazione esatto e confrontando gli hash dei pacchetti binari finali.
Potrebbe anche essere possibile avere una sorta di rete di fiducia in modo che più persone possano saltare e dire che gli hash corrispondono rendendolo un po 'più affidabile forse . Potrebbero esserci casi limite che non conosco.
Microsoft Windows 7+ può essere configurato per consentire solo Programmi autenticati con firma da eseguire.
Ma devi capire, questo significa solo che sai chi ha creato il virus che ha distrutto il tuo computer. Non è davvero una funzione di sicurezza, perché non ti dice nulla su un'applicazione che è firmata. Sì, tu sai che $ RANDOM_GUY proveniente da Cina, Ucraina, Angola, ovunque sia stato creato. Ma a cosa serve davvero questo, se i tuoi dati importanti sono crittografati e $ RANDOM_GUY richiede 20BTC per decrittografarli. E se il software ruba tutti i tuoi dati, allora a cosa ti serve sapere che $ RANDOM_GUY probabilmente lo ha rubato?
Leggi altre domande sui tag operating-systems digital-signature