Quali sono le differenze pratiche tra la modalità mirata di SELinux e un sistema operativo basato sulle capacità?

5

Recentemente ho fatto una domanda sulle differenze tra funzionalità e controlli di accesso obbligatori.

Tra le risposte che ho ottenuto è stato fatto notare che sistemi come SE Linux in modalità mirata non sono un tipico sistema MAC, poiché la preoccupazione non è limitare il flusso di informazioni.

Quindi, in un framework come la modalità mirata di SE Linux in cui l'attenzione dovrebbe essere rivolta a ridurre al minimo i danni in caso di accesso non autorizzato, quanto è diverso in pratica da un sistema basato sulle capacità?

Nota, sto solo chiedendo le differenze pratiche, non le differenze teoriche. Sono possibili diversi attacchi su SELinux in modalità mirata rispetto a un sistema operativo basato su capacità? Possono entrambi impedire l'accesso allo stesso livello granulare? Ecc ...

    
posta Sonny Ordell 19.01.2012 - 05:50
fonte

2 risposte

2

Penso che molti dei problemi con i sistemi basati sulle capacità e la nostra comprensione di questi sia che ce ne sono pochi in circolazione. Tuttavia, sei fortunato: FreeBSD ha appena aggiunto Capsicum supporto alla versione 9.0. Capsicum è un progetto di ricerca per implementare un [pratico insieme pratico di funzionalità] [1]. Questo lavoro ha coinvolto persone del team di Google Security Research e include una build sperimentale del browser Chrome progettata per utilizzare il sistema.

Ciò che potrebbe interessarti maggiormente è l'elenco delle funzioni:

  • capabilities - refined file descriptors with fine-grained rights

In pratica, opererà come SELinux, con ovvie differenze amministrative. Ha analogie per digitare etichette.

  • process descriptors - capability-centric process ID replacement

Ha analogie con i domini di SELinux. Dal punto di vista dell'utente, potrebbe non sembrare diverso.

Ora, nella prossima serie di funzionalità si vede perché le funzionalità non sono ancora di uso comune:

  • anonymous shared memory objects - an extension to the POSIX shared memory API to support anonymous swap objects associated with file descriptors (capabilities)
  • rtld-elf-cap - modified ELF run-time linker to construct sandboxed applications
  • libcapsicum - library to create and use capabilities and sandboxed components

Mentre SELinux richiede il supporto del kernel e una politica e va bene da lì, i problemi di configurazione a parte, l'implementazione pratica delle funzionalità richiede un approccio modificato alle API disponibili e la successiva preparazione delle applicazioni per accedervi.

Ora specificamente per le tue domande:

Can they both prevent access to the same granular level?

Incredibilmente paragonabile, sì. SELinux può, ad esempio, descrivere un dominio di applicazione e dargli accesso a una determinata cartella per sola lettura. I sistemi basati sulla capacità, quando inizializzano il processo, semplicemente non gli consentono di scrivere su quel percorso, o rifiutano successivamente tali richieste. È il modo in cui vengono implementati che varia.

Are different attacks possible on SELinux in targeted mode than on a capability based operating system?

Onestamente, è abbastanza difficile da dire. Non conosco sistemi operativi basati su capacità schierate su larga scala che abbiano attratto l'interesse per essere seriamente testati su strada. Mi aspetto, tuttavia, che alla fine l'obiettivo rimanga lo stesso: persuadere un processo per eseguire il codice per te usando i suoi privilegi più elevati (capacità). Possono variare per sfruttare il modo in cui allo stesso modo i buffer overflow variano a seconda del programma scelto, ma alla fine l'obiettivo fondamentale è sempre lo stesso.

Potresti sempre fare un tentativo . C'è anche la documentazione su le modifiche API di cui ho parlato.

Dichiarazione di non responsabilità: non sono affiliato al Capsicum Project, all'Università di Cambridge o al Progetto FreeBSD in alcun modo.

    
risposta data 01.02.2012 - 01:40
fonte
1

Le funzionalità sono diverse dalle Autorizzazioni, che è ciò che SELinux chiama capacità (doh).

Ad esempio, le capacità possono essere trasferite ad altri programmi, eventualmente attenuati. Ciò è in contrasto con i modelli basati su ACL in cui i controlli di accesso sono gestiti separatamente dai programmi.

Pensa alle funzionalità come riferimenti non cancellabili agli oggetti, o forse a un sottoinsieme dei metodi sugli oggetti, che possono essere utilizzati in fase di esecuzione da un programma. Quindi se voglio che qualcuno mi aggiorni un rapporto, posso passargli una capacità (riferimento all'interfaccia rw del file), che possono fornire a un programma che agisce per loro conto. A loro volta, possono delegare il processo di aggiornamento a qualcun altro, trasmettendo la capacità. Non devo aprire directory per un accesso più ampio.

Questo porta a uno stile di programmazione in cui le relazioni sicurezza / affidabilità sono considerate in fase di progettazione e arrivano come un'estensione abbastanza naturale del caso d'uso: ad esempio, se consegno la mia videocamera a qualcuno da usare, sto dando loro anche il permesso di usalo.

    
risposta data 06.05.2015 - 22:47
fonte

Leggi altre domande sui tag