Protezione dei contenuti delle cartelle dai processi

2

Consideriamo quanto segue:

  1. Linux è la piattaforma a cui sto facendo riferimento qui
  2. Esiste una partizione sul sistema crittografata con una password complessa (tramite il meccanismo LUKS, se pertinente)
  3. Questa partizione contiene informazioni sensibili che desidero isolare dal resto del sistema

Supponendo quanto sopra, come posso (come amministratore del sistema) applicare una regola che nega sistematicamente l'accesso in lettura del contenuto di tale partizione crittografata a tutti i processi attualmente in esecuzione sul sistema (compresi quelli avviati anche da parte mia) tranne per pochi (come il gestore di file per accedere ai contenuti della partizione). Ovviamente questo riguarda i periodi in cui la partizione è montata e sbloccata sul sistema in modo che ogni processo possa leggerlo da quel punto.

Fondamentalmente, quello che sto chiedendo è un modo per isolare un dispositivo montato dal resto del sistema scegliendo solo i processi che possono leggere da esso e negando l'accesso a qualsiasi altro programma che non fa parte di quell'elenco.

Credo che SELinux o AppArmor dovrebbero (in teoria) essere in grado di farlo ma non sono proprio sicuro di come configurarli.

Inoltre, non sono ancora sicuro se questa domanda è appropriata per essere qui o su superuser.

    
posta Alex 20.02.2018 - 21:05
fonte

1 risposta

0

Per isolare l'accesso a un punto di montaggio in modo che solo determinati programmi possano accedervi, è possibile utilizzare MAC o DAC. Quando si utilizza DAC, è necessario fornire un modo per eseguire automaticamente il programma di destinazione come un gruppo.

Controlli di accesso obbligatori

Un sistema di controllo di accesso obbligatorio, o MAC, è un framework per limitare le azioni che un determinato oggetto (ad esempio un processo o un gruppo di thread) può utilizzare per operare su un oggetto (ad es. un file, una directory o un'interfaccia di rete). I controlli di accesso sono generalmente applicati dal kernel e il processo confinato non ha voce su quali oggetti è autorizzato ad accedere e in che modo. Per il tuo caso d'uso, dovresti usare SELinux anziché AppArmor. AppArmor richiede un profilo esplicito per ogni singolo programma che sta limitando. Un nuovo programma non sarà affatto limitato. Ci sono modi in cui ciò comporta l'impostazione di un profilo per il processo di init, causandone l'ereditarietà da parte di tutti gli altri processi sul sistema, ma è una tecnica hacky e non testata. SELinux d'altra parte è specificamente progettato per politiche di isolamento a livello di sistema, sebbene per processo policy mirate sono anche supportate.

Puoi specificare un particolare contesto SELinux per un dato punto di mount specificando l'opzione context= durante il montaggio, usando fstab(5) o invocando direttamente mount(8) . Il contesto viene utilizzato per determinare quali autorizzazioni SELinux sono necessarie per accedervi, senza dover etichettare ogni file.

Controlli di accesso discrezionali

Controlli di accesso discrezionali, o DAC, sono le autorizzazioni UNIX standard che governano tutti gli accessi al filesystem su un sistema Linux. Si chiama discrezionale perché un utente che possiede un determinato file o directory può, a sua discrezione, modificare le sue autorizzazioni. Per utilizzare DAC per proteggere un punto di montaggio in modo che solo programmi specifici possano leggere e scrivere su di esso, si vorrebbe che il punto di montaggio fosse la modalità 0770, di proprietà dell'utente root e di un nuovo gruppo che si crea. Qualsiasi processo in esecuzione in questo gruppo sarà in grado di inserire, leggere, scrivere ed eseguire qualsiasi cosa sul punto di montaggio. Ci sono alcuni modi per farlo:

  • Contrassegna il tuo programma setgid , che lo farà eseguire automaticamente come il gruppo posseduto dall'eseguibile. Qualsiasi passaggio a un contesto setgid causerà il sistema per ignorare tutte le variabili ambientali potenzialmente pericolose e proteggi il processo dai debugger invasivi.
  • Configura il tuo sudoers per consentirti di eseguire i tuoi programmi approvati come dato gruppo, con o senza fornire una password. Funziona in modo simile all'opzione precedente, ma utilizza sudo .

Una tecnica molto più sicura ma più invasiva sarebbe quella di creare un utente completamente diverso, con il proprio ambiente desktop (se ne si usa) e la propria home directory. Quando devi accedere a qualcosa di sensibile, assicurati che i file e le directory sensibili siano leggibili solo da root e dal tuo nuovo utente sicuro. Questo potrebbe interrompere il tuo flusso di lavoro in quanto dovrai accedere a un altro utente, ma non sarà soggetto agli avvertimenti (non trascurabili) con l'isolamento dell'applicazione che sono spiegati di seguito.

Avvertimenti

È estremamente importante comprendere appieno le implicazioni di un particolare processo di accesso alle informazioni sensibili. A meno che il programma non sia specificamente progettato per rimanere protetto in queste circostanze, potrebbero esserci modi imprevisti per dirottarlo. Un file manager grafico, per esempio, non può essere isolato sotto Linux, in quanto avrà accesso al tuo cookie X11, e quindi qualsiasi altro programma grafico con accesso X11 in esecuzione con lo stesso utente (anche se il gruppo è diverso) sarà in grado di prendi screenshot, inietti i movimenti del mouse e le battute , e altro ancora. Questo naturalmente avrebbe vanificato i tentativi di isolamento. Tutti gli altri problemi saranno specifici per i singoli programmi. Tentativo di isolare il processo senza conformarsi a una particolare politica formale come Biba o Bell-LaPadula può essere rischioso.

    
risposta data 21.02.2018 - 07:58
fonte

Leggi altre domande sui tag