È sicuro gestire i dati attendibili in modo non sicuro?

Il significato della fiducia

Il significato di trusted è strano nella sicurezza del computer. Se qualcosa è affidabile, quindi per definizione non può essere dannoso in alcun modo. Quello che probabilmente stai chiedendo è invece se i dati che crei dovrebbero essere considerati fidati o non fidati. Rispondere a questo dipenderà molto dalla tua situazione particolare. In particolare, ciò che conta non è se tu voglia o meno "hackerarti", ma se ci sia o meno qualcosa che un utente malintenzionato può ottenere compromettendo il processo che sta processando i dati in modo non sicuro.

Un modo per pensarci è, sarebbe sicuro se il tuo file di configurazione avesse un'opzione exec=some_command che eseguisse automaticamente il comando all'avvio dell'applicazione (che non è particolarmente raro)? Se fosse sicuro, non ci sono motivi di sicurezza immediati per gestire in modo sicuro l'input.

Leggi, scrivi

Esiste un modello di sicurezza chiamato Biba Integrity Model . È caratterizzato dalla frase leggi, scrivi . Ciò significa che un livello di integrità inferiore (privilegio inferiore) non dovrebbe essere in grado di modificare i dati con un livello di integrità più elevato. In altre parole, puoi leggere più dati privilegiati, ma puoi solo scrivere su dati che sono meno privilegiati di quelli che già conosci. Questo modello di integrità è progettato specificamente per impedire a un processo privilegiato di fidarsi dei dati che un processo meno privilegiato potrebbe essere in grado di modificare. Attraverso questo, è possibile vedere che il modello consente a un determinato utente di modificare i file di configurazione delle applicazioni eseguite dallo stesso utente, ma non consentirebbe a un utente inferiore di modificare i file gestiti da un utente più privilegiato. Se i dati sono considerati trusted , sono esenti da restrizioni. Secondo questo modello di integrità, i tuoi dati sono affidabili? Esiste il potenziale per qualsiasi write up indesiderato?

Ci sono tre proprietà governate dal modello di integrità di Biba. Tratto da Wikipedia:

1. La proprietà Simple Integrity afferma che un soggetto con un determinato livello di integrità non deve leggere i dati a un livello di integrità inferiore (leggi).

2. La proprietà di integrità * (stella) afferma che un soggetto con un determinato livello di integrità non deve scrivere su dati con un livello di integrità più elevato (annotare).

3. Proprietà di richiamo afferma che un processo dal basso non può richiedere un accesso più elevato; solo con soggetti a un livello uguale o inferiore.

In altre parole, il programma analizza i dati in modo più privilegiato di un programma che dovrebbe essere necessario per modificare i dati "attendibili"? Se non è più privilegiato, un utente malintenzionato non può modificare i dati per elevarne i privilegi. Il massimo che possono fare è ottenere i privilegi che già possiedono. Questo è il motivo per cui /etc/passwd non è di proprietà dell'utente, ma le tue configurazioni di lettore multimediale sono!

Avvertimenti

Ci sono alcune altre cose a cui dovresti pensare prima di dichiarare che questa è una buona idea. È necessario chiedersi se, filosoficamente e praticamente, scrivere codice consapevolmente insicuro è una buona idea. Se non è eccessivamente difficile da elaborare in modo sicuro, è necessario porsi alcune cose.

• Ti ricorderai, in futuro, che il tuo codebase non è sicuro, o potresti ricrearlo di nuovo?
• Qualcun altro utilizzerà il tuo codice? Avranno lo stesso identico modello di minaccia che hai?
• Avrai mai eseguito l'applicazione con privilegi, con file di configurazione scrivibili con privilegi inferiori?
• I dati gestiti in modo insicuro possono generare bug confusi se vengono danneggiati accidentalmente?
• Ti senti a tuo agio nell'usare la scrittura di codice non sicuro? È una buona abitudine entrare?

Tutto dipende da ciò che chiami sicuro e da ciò che chiami dati sicuri. Se una applicazione serializza alcuni dati e più tardi questa applicazione o un'altra deserializza mentre non può essere mitigata nel frattempo, non vi è alcun problema di sicurezza speciale. Un esempio di caso d'uso è la serializzazione di sessione in applicazioni Web cluster. Se i dati sono stati moderati qui, hai davvero problemi più seri della semplice deserializzazione ¹ .

Ora immagina di archiviare i dati serializzati per un po 'su un computer personale, e prova a deserializzare dopo un po'. Nel frattempo sono accadute molte cose, e malware o incidenti fisici avrebbero potuto cambiare il file senza che l'utente se ne accorgesse. Oppure l'applicazione potrebbe essere cambiata in un diverso formato di serializzazione. In tal caso, è probabile che accadano cose brutte al momento della deserializzazione.

¹ in ogni caso, quando leggi dati di input che tu (una singola applicazione) non hai immediatamente prodotto, dovresti sempre essere pronto ad un errore e assicurarti che il tuo codice non possa rompere tutto ciò che lo circonda. Lanciare un'eccezione è generalmente soddisfacente, ma la scrittura di posta indesiderata in un database non lo è.