Mi chiedevo se il profilo hardened di Gentoo fosse davvero più sicuro di qualsiasi altra distribuzione (come Debian, RHEL, Arch … ). Per coloro che non lo sanno, Gentoo hardened consente di costruire un sistema a livello di sistema con opzioni GCC di hardening specifiche (pie, ssp, relro, …) e altre poche cose (grsec / selinux …).

Ad esempio, so che Arch Linux non crea tutti i binari con quei flag di hardening di GCC, quindi implica una sorta di preoccupazione per la sicurezza?

So che OpenVPN è costruito senza PIE e parziale relro. Ciò significa che se viene trovato un exploit contro OpenVPN, uninstallazione Arch potrebbe essere meno sicura di una Gentoo?

TL; DR: è un vero vantaggio usare Gentoo Hardened rispetto a qualsiasi altra distribuzione in termini di sicurezza dei binari?

Risposta

È tutto nel codice sorgente! Gentoo hardened è una distribuzione basata sulla sicurezza il profilo hardened è davvero racchiude molto per renderlo davvero sicuro.

Ma vale la pena compilarlo? Una grande domanda tra i forum di Linux.

Diamo unocchiata al profilo rafforzato di Gentoo in termini di sicurezza:

mentre aggiunge un po di secu rity è così poco che non ne vale la pena nella maggior parte dei casi. Fornisce più sicurezza su una distribuzione binaria perché tutti hanno gli stessi binari e un utente malintenzionato non ha bisogno di indovinare dove può essere caricato uno specifico pezzo di codice ma eseguendo una distribuzione sorgente il tuo spazio degli indirizzi è già piuttosto unico. Lunico caso in cui fornisce un po di sicurezza quando un utente malintenzionato cerca di indovinare un indirizzo per un exploit, fare unipotesi sbagliata probabilmente bloccherà il processo e verrà ricaricato su un nuovo indirizzo. Hai dati sufficienti per un utente malintenzionato per farlo fastidio per ottenerlo? Se lo fai, dovresti utilizzare un profilo rinforzato, ma la sicurezza fisica e la crittografia del disco sono più importanti perché se vale così tanto sarà più facile derubarti.

Essere consapevoli del fatto che non esiste un profilo desktop rinforzato, quindi da solo renderà un po più difficile se si prevede di usarlo su un desktop.

Un altro motivo è se vuoi usare qualcosa come SELinux (che non richiede un profilo rinforzato) che ti dà un controllo granulare sul controllo degli accessi ma è anche molto restrittivo. Penso che valga la pena solo per reti di grandi dimensioni con molti utenti e diversi livelli di accesso ai dati sensibili.

Avevo bisogno di alcune delle funzionalità di SELinux ma ho deciso di utilizzare AppArmor in un modo insolito per realizzarle perché SELinux è troppo disturbo. Tutto ciò che AppArmor fa è fornire isolamento del processo o sandboxing. Se un utente malintenzionato ottiene laccesso tramite un exploint, sarà in grado di accedere solo ai file a cui ha accesso il servizio sfruttato. Lo uso con un profilo catch all che impedisce lesecuzione da tutte le directory scrivibili e home del mondo e laccesso a chiavi ssh / pgp, portachiavi, ecc. Funziona bene per server e desktop e non è troppo restrittivo. E se ho bisogno di eseguire codice dalla mia directory home per lo sviluppo posso lanciare una shell senza restrizioni tramite sudo.Posso lasciare il mio laptop sbloccato con il portafoglio aperto (uso il modulo kwallet pam) e sarà davvero difficile per te ottenere qualcosa come chiavi ssh o password (ho anche patch per kwallet quindi è richiede un passw ord per mostrare le password salvate), ma i programmi che ne hanno bisogno possono accedervi.

Ma cosa lo rende indurito? diamo unocchiata anche ad alcuni di questi elementi:

  • PaX è una patch del kernel che ci protegge da overflow di stack e heap. PaX lo fa utilizzando ASLR (address space layout randomization), che utilizza posizioni di memoria casuali nella memoria. Ogni shellcode deve utilizzare un indirizzo per saltare a essere incorporato in esso al fine di ottenere lesecuzione del codice e, poiché lindirizzo del buffer in memoria è randomizzato, questo è molto più difficile da ottenere. PaX aggiunge un ulteriore livello di protezione mantenendo i dati utilizzati dal programma in una regione di memoria non eseguibile, il che significa che un utente malintenzionato non sarà in grado di eseguire il codice che è riuscito a scrivere in memoria. Per usare PaX, dobbiamo usare un kernel abilitato per PaX, come hardened-sources.
  • PIE / PIC (codice indipendente dalla posizione): Normalmente, un eseguibile ha un indirizzo di base fisso dove sono caricati. Questo è anche lindirizzo che viene aggiunto agli RVA per calcolare lindirizzo delle funzioni allinterno delleseguibile. Se leseguibile è compilato con il supporto PIE, può essere caricato ovunque nella memoria, mentre deve essere caricato a un indirizzo fisso se compilato senza supporto PIE. Il PIE deve essere abilitato se vogliamo usare PaX per sfruttare ASLR.
  • RELRO (relocation read-only): quando eseguiamo leseguibile, il programma caricato deve scrivere in alcune sezioni che non non è necessario contrassegnarlo come scrivibile dopo lavvio dellapplicazione. Tali sezioni sono .ctors, .dtors, .jcr, .dynamic e .got [4].Se contrassegniamo queste sezioni come di sola lettura, un utente malintenzionato non sarà in grado di utilizzare determinati attacchi che potrebbero essere utilizzati durante il tentativo di ottenere lesecuzione del codice, come la sovrascrittura delle voci in una tabella GOT.
  • SSP ( protezione contro lo stack) viene utilizzato in modalità utente; protegge contro lo stack overflow posizionando un canarino sulla pila. Quando un utente malintenzionato vuole sovraccaricare lindirizzo EIP di ritorno sullo stack, deve anche superare il canarino scelto a caso. Quando ciò accade, il sistema può rilevare che il canary è stato sovrascritto, nel qual caso lapplicazione viene terminata, impedendo così a un utente malintenzionato di saltare a una posizione arbitraria in memoria ed eseguire codice da lì.
  • RBAC (controllo degli accessi basato sui ruoli): si noti che RBAC non è lo stesso di RSBAC, che presenteremo più avanti. Il RBAC è un controllo di accesso che può essere utilizzato da SELinux, Grsecurity, ecc. Per impostazione predefinita, il creatore di un file ha il controllo totale sul file, mentre RBAC forza lutente root ad avere il controllo del file, indipendentemente da chi ha creato esso. Pertanto tutti gli utenti del sistema devono seguire le regole RBAC impostate dallamministratore del sistema.

Inoltre, possiamo anche utilizzare i seguenti sistemi di controllo dellaccesso, che vengono utilizzati per controllare laccesso tra processi e oggetti. Normalmente, dobbiamo scegliere uno dei sistemi descritti di seguito, perché solo uno dei sistemi di controllo degli accessi può essere utilizzato alla volta. I sistemi di controllo degli accessi includono quanto segue:

  • SELinux (Linux con sicurezza avanzata)
  • AppArmor (armatura dellapplicazione)
  • Grsecurity, che contiene varie patch che può essere applicato al kernel per aumentare la sicurezza di un intero sistema. Se vogliamo abilitare Grsecurity nel kernel, dobbiamo usare un kernel abilitato per Grsecurity, che è hardened-sources.
  • RSBAC (controllo dellaccesso basato su set di regole): dobbiamo usare il kernel rsbac-sources costruire un kernel con supporto rsbac.

Tutto si riduce alla grande domanda come affermato in precedenza? Vale la pena compilare? Dipende davvero da come o cosa stai assicurando e vale la pena fare lo sforzo? O sarai in grado di proteggere veramente ciò che non vuoi che occhi indiscreti vedano?

Commenti

  • Ok, grazie per il chiarimento di tutti queste tecnologie di applicazione della sicurezza. Quindi, se capisco il tuo punto, questi elementi sono molto utili per migliorare la sicurezza di un sistema; ma chiedi a " se ne vale la pena la compilazione? ". Quindi, perché non sono abilitati per impostazione predefinita in alcune delle principali distribuzioni? Ho letto che PaX su un desktop potrebbe rompere alcuni binari (sentito parlare di java o firefox); è lunico motivo?
  • Il motivo per cui PaX e grsecurity non sono limpostazione predefinita in molte distribuzioni è dovuto alla politica e allego. Gli sviluppatori di entrambi hanno personalità che si scontrano fortemente con il team di sviluppo del kernel Linux. In aggiunta a ciò, non desiderano perdere tempo per suddividere la loro patch in blocchi che sarebbero accettati a monte, e invece usano il loro tempo per sviluppare più funzionalità di sicurezza.
  • Nota anche che grsecurity è non un sistema di controllo degli accessi. Spender (creatore di grsecurity) si irrita molto quando le persone lo chiamano un sistema di controllo degli accessi e lo confrontano con SELinux. : P Grsecurity è una combinazione di patch del kernel che aumenta la sicurezza del kernel eliminando le classi di bug. Il sistema di controllo degli accessi RBAC che ha è irrilevante rispetto al resto. Le funzionalità di sicurezza di Grsecurity ' sono così estese che occuperebbe molto più spazio di quello che potrebbe essere messo in un singolo post. Dai unocchiata a grsecurity.net per vedere un elenco piuttosto completo.
  • mentre aggiunge un po di sicurezza, ' è così piccolo che ' non ne vale la pena nella maggior parte dei casi – Uh, questo è totalmente sbagliato. E la sicurezza non ha davvero nulla a che fare con gli indirizzi nascosti. ' m stupito che questa risposta abbia ricevuto voti favorevoli.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *