SELinux vs. AppArmor vs. grsecurity [chiuso]

Chiuso . Questa domanda deve essere più focalizzata . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che si concentri su un problema solo modificando questo post .

Chiuso 2 anni fa .

Devo impostare un server che dovrebbe essere il più sicuro possibile. Quale miglioramento della sicurezza useresti e perché, SELinux, AppArmor o grsecurity? Puoi darmi qualche consiglio, suggerimento, pro / contro per quei tre?

PER QUANTO NE SO:

SELinux: il più potente ma il più complesso
AppArmor: configurazione / gestione più semplice rispetto a SELinux
grsecurity: configurazione semplice grazie all'auto training, più funzioni oltre al semplice controllo degli accessi

linux security hardening

Un "server" per fornire che tipo di servizio? A quale pubblico, in quale ambiente? Cosa ti costituisce "sicuro" in questo contesto? Sarebbero necessarie molte più informazioni per fornire una risposta utile. Ad esempio, un server IP Time-of-Day puro può essere molto sicuro: tutto il firmware della ROM, il radio imput, l'autonomia della batteria con ricarica automatica. Ma questa probabilmente non è una risposta utile per te. Quindi, che tipo di servizio? Gruppo di lavoro fidato, Internet, aziendale, rete punto-punto dedicata, ecc.? È necessaria l'alta disponibilità? Affidabilità? Integrità dei dati? Controllo di accesso? Give

— mpez0,

Risposte:

Ho fatto molte ricerche in questo settore. Ho persino sfruttato le regole di AppArmor per MySQL . AppArmor è la forma più debole di separazione dei processi. La proprietà che sto sfruttando è che tutti i processi hanno privilegi di scrittura su alcune delle stesse directory come /tmp/. La cosa bella di AppArmor è che interrompe alcuni exploit senza intralciare l'utente / gli amministratori. Tuttavia, AppArmor presenta alcuni difetti fondamentali che non verranno risolti presto.

SELinux è molto sicuro, è anche molto fastidioso. A differenza di AppAmoror, la maggior parte delle applicazioni legittime non funzionerà fino a quando SELinux non sarà stato riconfigurato. Molto spesso ciò causa la configurazione errata dell'amministratore SELinux o la disabilitazione del tutto insieme.

grsecurity è un pacchetto di strumenti molto ampio. Quello che mi piace di più è il chroot avanzato di grsecuirty. Questo è ancora più sicuro di SELinux, anche se ci vuole un po 'di abilità e del tempo per impostare una prigione chroot in cui SELinux e AppAprmor "funzionano".

C'è un quarto sistema, una macchina virtuale. Sono state rilevate vulnerabilità negli ambienti VM che possono consentire a un utente malintenzionato di "esplodere". Tuttavia una VM ha una separazione ancora maggiore di una chroot perché in una VM si condividono meno risorse tra i processi. Le risorse disponibili per una macchina virtuale sono virtuali, e possono avere poca o nessuna sovrapposizione tra altre macchine virtuali. Ciò riguarda anche il <buzzword>" cloud computing " </buzzword>. In un ambiente cloud potresti avere una separazione molto chiara tra il tuo database e l'applicazione web, che è importante per la sicurezza. È anche possibile che 1 exploit possieda l'intero cloud e tutte le VM in esecuzione su di esso.

— Torre
fonte

invece del <buzzword>tag puoi semplicemente scrivere "il mio culo", tutti sapranno cosa intendi;)

— Daniel Dinnyes,

Per VM intendi Xen, KVM o LXC / Docker? Inoltre, fai riferimento alle tue valutazioni.

— Daniel Dinnyes,

@Daniel Dinnyes non ci sono riferimenti qui, questa è l'opinione personale di un hacker che attacca le moderne applicazioni protette con queste tecniche di mitigazione - il grande risultato è che nulla è perfetto.

— Rook

@Daniel Dinnyes Se sei interessato a casi di uso improprio, inizia con i casi d'uso previsti. Installa distribuzioni che utilizzano queste tecnologie e distribuisci app su di esse. Scopri come distribuire e configurare questi sistemi di sicurezza, quindi cerca i punti deboli.

— Rook

@Daniel Dinnyes esamina i CVE emessi e soprattutto eventuali exploit pubblici per ciascuna piattaforma. Recentemente è stato trovato un ottimo bypass SELinux: exploit-db.com/exploits/40419

— Rook

Personalmente, userei SELinux perché finirò per prendere di mira un po 'di sapore di RHEL che ha questo set pronto per la maggior parte. In Red Hat esiste anche un set reattivo di manutentori e molta documentazione eccellente sulla configurazione di SELinux. Link utili di seguito.

— Ophidian
fonte

sì, ma yum e selinux sono così dannatamente fastidiosi.

— Rook,

Trovo che la CLI di yum sia significativamente più intuitiva di apt. SELinux è fastidioso quando stai provando a fare la tua strada con app non stock, ma non ho mai avuto problemi con le cose stock oltre a dover attivare alcuni sebool per abilitare funzionalità non predefinite (ad esempio Consenti agli script httpd php di connettersi al database)

— Ophidian,