Impedisci alle app di avere accesso completo ai file dell'utente

Naviga le tue risposte
4

Le applicazioni non dovrebbero avere accesso ai dati di altre applicazioni o ai dati privati dell'utente a meno che l'utente non li autorizzi. Non è una necessità ovvia? Ma ogni programma che lanciamo ha pieno accesso alla nostra cartella $ HOME, al nostro microfono e cam. La maggior parte degli utenti non si accorgerà nemmeno se (ad esempio) Skype inizia a inviare da qualche parte i propri file privati o lo streaming audio dal proprio microfono.

Sto cercando modi per risolvere questo problema. Sentiti libero di suggerire qualsiasi cosa, anche se il tuo metodo implica la scrittura di criteri SELinux, moduli LSM, patch del kernel, passaggio a un altro sistema operativo simile a UNIX.

Ecco alcune idee che ho avuto e motivi per cui le ho respinte:

  1. Creiamo nuovi utenti unix per ogni app non affidabile. Usiamo il bit SUID per fare in modo che l'app funzioni sempre come se fosse un utente. Male. Perché dobbiamo inserire nella blacklist tutte le app di cui non ci fidiamo e ogni nuova app che installiamo. Tonnellate di lavoro, facile perdersi qualcosa. Anche i binari potrebbero perdere la bandiera SUID quando aggiorniamo / reinstalliamo l'app. Inoltre, c'è un problema con i processi figli: in teoria, le app che non hanno qualche permesso, possono usare altre app per raggiungere il loro obiettivo. E se non usiamo SUID, sarà difficile ricordare che dobbiamo usare "su" per avviare ogni app non sicura.
  2. Utilizziamo la transizione del dominio SELinux per limitare le app non attendibili. Anche cattivo Lo stesso problema con # 1. Abbiamo bisogno di scrivere / aggiornare / iniettare politiche SELinux per ogni app di cui non ci fidiamo. Voglio che le app non abbiano accesso speciale per impostazione predefinita, non accesso completo.
  3. Creiamo nuovi utenti unix "fidati" per app affidabili. Possiamo utilizzare i gruppi per implementare varie categorie di dati privati: foto, note ecc. Ma non possiamo usare SUID e abbiamo bisogno di passare manualmente a quell'utente prima di avviare l'app (con password). Il problema di questa opzione sono i processi figli. Non possiamo permettere che tutti i processi figli del programma fidato siano attendibili (se apriamo il file multimediale nel gestore di file attendibile, non vogliamo che il lettore multimediale erediti lo stato di fiducia del file manager). Ma non possiamo nemmeno permettere a tutti i processi figli di rilasciare le loro autorizzazioni predefinite. Anche cattivo!
  4. Usiamo SELinux per implementare domini "fidati" per ogni app di fiducia. In questo caso non possiamo utilizzare la transizione automatica del dominio. Quindi dobbiamo cambiare dominio con password. Questa opzione è leggermente migliore di # 3 perché possiamo vietare l'avvio di app non affidabili in tali domini attendibili. Ma ancora brutto e scomodo.
  5. Se pensiamo di più, stiamo iniziando a vedere che non possiamo assolutamente associare i permessi ai binari eseguibili. Ad esempio, l'interprete Python potrebbe richiedere autorizzazioni diverse a seconda dello script eseguito. Quindi possiamo dimenticare le opzioni 1 e 2
  6. Possiamo creare il nostro modulo LSM (come SELinux). Ma come dovrebbe funzionare? Non sono sicuro di avere idee. Modalità interattiva? Chiedendo il permesso dell'utente ogni volta che un processo tenta di leggere i file privati? O dovremmo prendere alcune idee dal modello "lomac" (filigrana bassa)? Diciamo che leggere dati non affidabili rende l'ambiente contaminato e impedisce di leggere dati privati.
  7. Demone spazio utente + libreria LD_PRELOAD? In questo caso, le app non hanno accesso ai file privati per impostazione predefinita, ma possono contattare il daemon privilegiato e chiedere di aprire tali file e passare il descrittore di file. Questo è fattibile e assomiglierà ai vecchi "firewall interattivi" per Windows.

Altre idee? Per favore dimmi che conosci la soluzione pronta:)

Aggiorna

Ho iniziato a sviluppare il mio LSM (sostituzione SELinux). Sembra che nessuno qui sia interessato. Ma, nel caso, puoi trovarmi qui:

link

o qui:

[email protected]

    
posta Sion0 16.09.2018 - 09:43
fonte

3 risposte

1

Non ho trovato nessuna soluzione adatta a me. Così, alla fine, ho iniziato a sviluppare il mio LSM (Linux Security Module). Attualmente, è nella fase iniziale di sviluppo, ma consente già di raggiungere (quasi) ciò che volevo. Ecco i principi di base:

  1. L'utente può definire fino a 64 autorizzazioni. Le autorizzazioni sono identificate dal numero, ma possono anche avere alias leggibili. Esempi:

    • 1="Autorizzazione a leggere le foto private"
    • 2="Autorizzazione a leggere e scrivere cookie del browser"
    • 3="Autorizzazione a leggere e scrivere note private"

  2. Usando una semplice utility, l'utente può contrassegnare qualsiasi file da impostare:
    a) autorizzazioni richieste per leggere questo file;
    b) autorizzazioni richieste per modificare questo file;
    c) permessi che questo file possa avere se eseguito.
    Esempi:

    • Autorizziamo l'autorizzazione n. 1 (leggi foto private) necessaria per leggere alcuni file di foto particolari.
    • Impostiamo il programma "/ bin / firefox" non può avere alcuna autorizzazione se eseguito (senza significato perché questo è l'impostazione predefinita).
    • Impostiamo il programma "/ bin / cat" che può avere qualsiasi autorizzazione se eseguito.
    • Impostiamo il programma "/ bin / imageview" che può avere l'autorizzazione n. 1 ma non altre.

  3. IMPORTANTE I programmi (processi) non possono avere permessi che il loro genitore non ha. Esempi:

    • "/ bin / firefox" non può usare "/ bin / cat" per leggere le foto private. "cat" perderà tutte le autorizzazioni se lanciato da "firefox".

  4. PID 1 (padre di tutti i processi userspace) inizia con permessi completi. Successivamente, le autorizzazioni di ogni programma è determinato rimuovendo i permessi che questo programma non ha dai suoi genitori permessi.

  5. Per impostazione predefinita, i programmi non hanno permessi. E i file non hanno bisogno di permessi per leggerli / modificarli. Quindi abilitare il mio LSM non può rompere nulla.

  6. Ci sono anche piani per implementare permessi di sistema come "usa internet" o "usa il microfono".

Qualcosa di simile ... Per favore dimmi se vedi violazioni critiche in questa logica.

Sul mio PC, sono stato costretto a dare le autorizzazioni complete ai seguenti programmi: systemd, agetty, login, bash, xinit, sh, startkde, start_kdeinit_wrapper, start_kdeinit, kdeinit5, konsole

Ora i programmi che lancio dal menu KDE o da konsole potrebbero avere qualsiasi autorizzazione. Ma la maggior parte di loro no naturalmente.

    
risposta data 24.09.2018 - 18:42
fonte
4

Applications should not have access to data of other applications or to user's private data unless user allows them. Isn't this an obvious need?

No, questo non è ovvio. Tradizionalmente, il software installato sul sistema era considerato attendibile, ovvero non era previsto che gli utenti si limitassero ad accedere a Internet e scaricare alcune possibili applicazioni dannose. Inoltre, non ci si aspettava che gli utenti eseguissero software non sicuro che potrebbe interagire male con qualche sito remoto e fornire quindi a un utente malintenzionato remoto l'accesso ai dati locali.

Quindi il limite di sicurezza in UNIX (e in altri sistemi operativi) è designato dall'utente e non dall'applicazione. In effetti, non c'è nemmeno un concetto di applicazione come vorreste avere: applicazioni complesse (come Office) sono in realtà costituite da diversi binari, librerie, file di configurazione ecc.

Penso che questo design sia ancora valido in molti casi d'uso, vale a dire casi in cui i sistemi non vengono modificati molto in primo luogo o dove viene installato solo il software affidabile. Ma ora ci sono anche casi in cui gli utenti effettivamente installano software da fonti potenzialmente non attendibili o installano software potenzialmente insicuro e si aspettano che questo software non faccia molto male. In questi casi il paradigma originale di utilizzare solo l'utente come limite di sicurezza non è sufficiente.

Esistono sistemi operativi progettati con un paradigma diverso, vale a dire dove è comune che gli utenti scarichino eventuali applicazioni dannose da Internet e vogliano limitare l'accesso ai dati privati. Ad esempio, in Android ciascuna applicazione viene essenzialmente installata come proprio utente e quindi il limite utente viene utilizzato per limitare l'accesso ai dati generati da un'altra applicazione (questo è leggermente semplificato su come funziona).

Quindi, se consideri le applicazioni non affidabili per impostazione predefinita, è meglio eseguire un sistema operativo progettato attorno a questo paradigma dall'inizio invece di provare a modificare un sistema operativo progettato con un paradigma diverso. Quando ti sei reso conto di te stesso, qualsiasi tentativo di applicare i concetti di applicazioni non fidate a un sistema progettato intorno a applicazioni attendibili è goffo e scomodo da utilizzare.

    
risposta data 16.09.2018 - 11:12
fonte
3

Raccomando di consultare AppArmor in alternativa a SELinux; fornisce il comportamento desiderato ed è più semplice da mantenere. Tuttavia, è molto lavoro definire i profili di AppArmor adatti ai tutti programmi che potresti voler eseguire, quindi generalmente lo utilizzeresti solo con programmi non sicuri o di bassa sicurezza a meno che lo sviluppatore / editore non ha fornito un profilo.

Detto questo ... i sistemi operativi generici non sono, in generale, progettati per questo tipo di sandboxing. Il sandboxing è diventato sempre più popolare come caratteristica del sistema operativo negli ultimi anni, ma ci sono ancora buoni motivi per cui non è implementato come universalmente come ci si potrebbe aspettare. In breve, il sandboxing è difficile da ottenere (sia per gli agenti di sicurezza sandbox che per gli sviluppatori che devono far funzionare correttamente la loro app all'interno della sandbox), e non è il modo in cui la sicurezza del sistema operativo generale ha funzionato di solito e quindi è incompatibile con un sacco di codice legacy.

I primi approcci alla sandboxing su Linux e sistemi operativi simili spesso usavano chroot jail , e quelli sono ancora un'opzione ( anche se sono difficili da ottenere correttamente). Tuttavia, ora ci sono altre opzioni più configurabili e meno fragili. La "containerizzazione" di processi che utilizzano sistemi come Docker rende relativamente semplice separare i processi dal resto del sistema , sebbene Docker stesso non sia particolarmente progettato per il caso d'uso che descrivi. Potrebbe essere possibile adattarlo, o la sua tecnologia, per i tuoi usi.

Come per altri sistemi operativi ...

  • FreeBSD supporta "jail" (con un comando jail ) che i processi sandbox. Probabilmente è il più simile all'utilizzo di Linux con tecniche di sandboxing, e infatti eseguirà la maggior parte del software Linux e supporta gran parte dello stesso hardware.
  • Le app Android vengono eseguite in modalità sandbox, con le autorizzazioni specificate in un manifest che fa parte del pacchetto dell'app. Le versioni moderne di Android generalmente consentono un controllo preciso sulle autorizzazioni ottenute da ciascuna app, quindi non è necessario decidere tra fornire a un'app tutte le autorizzazioni desiderate e non eseguirla affatto. Sebbene non sia generalmente previsto per l'uso come sistema operativo desktop, offre una vasta gamma di software disponibili e può essere convinto di funzionare sulla maggior parte dell'hardware.
  • Il sistema Chrom [e | ium] esegue le applicazioni in modalità sandbox ed è essenzialmente un browser Web come sistema operativo. È di uso limitato se non esegui la maggior parte del tuo lavoro online, sebbene le versioni più recenti possano anche eseguire app Android.
  • MacOS supporta il sandboxing e lo utilizza estensivamente per le app installate dall'app store. Le app MacOS tradizionali continueranno comunque a funzionare con i privilegi completi. Software proprietario (con alcuni componenti open-source) e (legalmente) richiede l'hardware Apple.
  • Apple iOS esegue tutte le app in modalità sandbox con una modalità di autorizzazione molto simile a Android, ma è molto restrittiva in ciò che consente. Un sacco di app, ma molto restrittive su quale hardware verrà eseguito (iPad, iPhone, iPod Touch) e molto proprietario. Fornisce inoltre al proprietario nominale un minimo controllo di basso livello sul dispositivo.
  • Windows 10 supporta l'app sandboxing (utilizzato per le app dall'app store e alcune app integrate), sebbene la maggior parte delle app Windows tradizionali continuino a funzionare con piena affidabilità (è difficile sandbox di programmi di terze parti). Software proprietario, ma supporta l'esecuzione di file binari di Linux come nelle versioni recenti (in genere senza sandboxing speciale, tuttavia, e non supporta i moduli del kernel di Linux).
risposta data 16.09.2018 - 12:22
fonte

Leggi altre domande sui tag

client / server attendibile dopo l'autenticazione su HTTPS per poi passare a testo normale? Come reimpostare la password di ingegnere da / etc / shadow