Sto eseguendo una macchina Ubuntu Linux. Quando eseguo applicazioni scritte da fornitori diversi come Chrome e Firefox, noto che sono tutte in esecuzione con il mio uid. Ma se è così, anche qualsiasi file che creano sul file system avrà lo stesso uid. Allora in che modo in Linux due app reciprocamente non attendibili possono proteggere i propri file l'uno dall'altro?
- l'utilizzo di un criterio ACL da parte dell'app A può comunque consentire all'app B di leggere i file di A, tramite la parte utente di (utente, gruppo, altro)
- le app devono utilizzare la crittografia per proteggere i propri dati gli uni dagli altri?
Risposta accettata:
La risposta letterale è che non esiste un'applicazione non attendibile in esecuzione con il tuo account. Se desideri eseguire un'applicazione non attendibile, eseguila con un account diverso o in una macchina virtuale.
I tipici sistemi operativi desktop come Unix e Windows e i tipici sistemi operativi mobili come Android e iOS hanno modelli di sicurezza diversi. Unix è un sistema operativo multiutente, con utenti reciprocamente non attendibili. Applicazioni sono considerati attendibili:tutte le applicazioni di un utente vengono eseguite nello stesso contesto di sicurezza. Servizi , d'altra parte, sono un po' meno affidabili:in genere vengono eseguiti con un account dedicato, per ridurre l'impatto in caso di vulnerabilità della sicurezza.
Ci sono due ragioni principali per cui il modello di sicurezza Unix funziona in questo modo:
- Un motivo negativo è la storia:quando Unix è stato progettato, le applicazioni provenivano da un piccolo gruppo di programmatori ed erano supportate dalla reputazione del fornitore o fornite come codice sorgente o entrambi. Le backdoor erano raramente temute nelle applicazioni. Inoltre, poche applicazioni comunicavano sulla rete, quindi c'erano relativamente poche opportunità per attivare e sfruttare le vulnerabilità. Pertanto non c'era un forte incentivo a isolare le applicazioni l'una dall'altra.
- Un motivo positivo è la funzionalità:isolare le applicazioni rende impossibili molte cose. Se ogni applicazione ha la propria area dati, ciò rende difficile la condivisione dei dati tra le applicazioni. In un tipico sistema Unix, è molto comune che gli stessi dati vengano gestiti da più applicazioni. Ciò è particolarmente vero poiché Unix non ha una chiara separazione tra "applicazioni" e "sistema operativo". Un browser web è un'applicazione. Non essere in grado di scaricare un file nella directory di tua scelta, perché il browser è confinato nella propria directory, è fastidioso. Il programma che visualizza menu e icone quando si accede è anche un'applicazione sullo stesso piano. Così sono i file manager, che per definizione hanno bisogno di accedere a tutti i tuoi file. Così sono le shell e altri interpreti che eseguono script dappertutto. Quando stampi un documento da un elaboratore di testi, ciò potrebbe comportare un'applicazione per convertire il documento in un formato stampabile e un'altra applicazione per inviare i dati alla stampante.
Sebbene oggi ci siano molti più autori di applicazioni rispetto a 40 anni fa, le applicazioni sono ancora generalmente distribuite attraverso canali attendibili, che portano un'indicazione di reputazione. (Questo è decisamente più vero per Linux che per Windows, il che è parte del motivo per cui i virus sono più comuni in Windows.) Si scopre che un'applicazione ha una backdoor verrebbe prontamente estratta dai repository di software Linux.
Correlati:Debian:ridimensionare la partizione di root senza disinstallare e reinstallare Linux (o perdere dati)?I sistemi operativi mobili sono stati progettati pensando a diverse minacce. Sono stati progettati per sistemi a utente singolo, ma con applicazioni provenienti da fonti del tutto non attendibili.
L'isolamento delle applicazioni sta iniziando a farsi strada sui sistemi Unix desktop. Alcune distribuzioni eseguono determinati programmi con framework di sicurezza come AppArmor o SELinux che limitano ciò che l'applicazione può fare. Il costo di queste restrizioni di sicurezza è che a volte rendono impossibili usi desiderabili, ad esempio impedendo a un'applicazione con restrizioni di aprire file in determinate directory.
La crittografia sarebbe completamente inutile. La crittografia protegge solo i dati in transito (in rete) o a riposo (memorizzato su un disco), non protegge i dati su un sistema attivo — se il sottosistema A decrittografa i suoi dati, spetta al sistema operativo impedire al sottosistema B di impedire l'accesso ai dati decrittografati, quindi non importa se i dati sono stati decrittografati da A o archiviati non crittografati. Il sistema operativo potrebbe crittografare i dati, ma solo per proteggerli in caso di furto del supporto di archiviazione.
Se vuoi eseguire codice di cui non ti fidi, la cosa migliore da fare è eseguirlo in una macchina virtuale. Concedi alla macchina virtuale l'accesso solo ai file di cui l'applicazione ha bisogno (ad es. non condividere la tua home directory).