# selinux Vs. grsecurity

## Kernel78

Il titolo del topic è abbastanza esplicativo, senza scatenare flame o guerre di religione vorrei avere dei vostri pareri su questi sistemi.

Io non li conosco se non di nome e volendo iniare ad informarmi, da quale mi consigliereste di iniziare e perchè ?

----------

## .:chrome:.

dietro a SELinux ci sono spesso dei pregiudizi di carattere "politico", nel senso che un progetto portato avanti dalla NSA capisci bene che fa storcere il naso a molti, per questo troverai persone abbastanza contrarie...

personalmente non mi pongo quel problema, tuttavia preferisco ugualmente soluzioni "più open".

più che GRSecurtity, che offre una protezione dello stack superiore rispetto a SELinux, ma un controllo inferiore sul file system, prediligo l'accoppiata PaX e RSBAC, che oltre alla suddetta protezione dello stack e della memoria, offre un controllo sugli oggetti (file system e oggetti di rete) quasi sicuramente superiore rispetto a SELinux.

----------

## .:deadhead:.

Quel che posso aggiungere io è che entrambi girano su gentoo e che esiste il progetto hardened che si occupa di ciò. 

Come ti renderai conto leggendo la doc, SELinux ha un'organizzazione molto complessa che va a modificare in maniera indelebile il sistema. Al contrario GRSecurity in accoppiata con Pax ed eventualmente RSBAC permette una scelta granulare e modulare delle funzionalità da attivare e non stravolge l'uso e il comportamento delle macchine su cui gira [magari con rsbac un po' sì]

In entrambi i casi però sapere cosa si sta facendo è condizione necessaria: http://www.gentoo.org/doc/en/security/index.xml <- questo è un ottimo punto di partenza, indipendentemente da grsec o selinux.

----------

## .:chrome:.

 *.:deadhead:. wrote:*   

> Al contrario GRSecurity in accoppiata con Pax ed eventualmente RSBAC

 

solo una precisazione: GRSecurity e RSBAC non possono convivere. insistono sulle stesse porzioni di codice e non sono mia state sviluppate patch cumulative per entrambi.

L'unica soluzione è PaX + RSBAC

----------

## X-Drum

 *k.gothmog wrote:*   

> 
> 
> L'unica soluzione è PaX + RSBAC

 

quindi tu sconsigli l'accoppiata GRSecurity+PaX?

se ho ben capito

----------

## .:chrome:.

GRSecurity include già PaX, quindi basta quello  :Wink: 

----------

## X-Drum

 *k.gothmog wrote:*   

> GRSecurity include già PaX, quindi basta quello 

 

ahem vado a farmi un caffe'

sciauuuuuuu

----------

## power83

cosa sarebbero e a che servirebbero in dettaglio?!

----------

## .:chrome:.

 *power83 wrote:*   

> cosa sarebbero e a che servirebbero in dettaglio?!

 

hardening PESANTE del sistema. quanto basta per avere molte applicazioni che non girano più  :Wink: 

sono meccanismi di protezione molto avanzati, che si usano di solito per proteggere server in produzione, o macchine che contengono dati molto importanti.

non sono molto amichevoli: ti portano quasi alla follia  :Very Happy: 

http://www.grsecurity.net/

http://pax.grsecurity.net/

http://www.rsbac.org/

http://www.nsa.gov/selinux/

----------

## Dece

 *k.gothmog wrote:*   

> non sono molto amichevoli: ti portano quasi alla follia 
> 
> 

 

Non ho mai usato SELinux o GRSecurity in modo approfondito: da quel poco che ho provato, ho avuto l'impressione che su questo punto, le regole di RBAC di GRSecurity fossero un po' più semplici da definire rispetto a SELinux, in parte grazie al learning mode. Ma la pazzia è assicurata in ogni caso?  :Very Happy: 

----------

## .:chrome:.

 *Dece wrote:*   

> Non ho mai usato SELinux o GRSecurity in modo approfondito: da quel poco che ho provato, ho avuto l'impressione che su questo punto, le regole di RBAC di GRSecurity fossero un po' più semplici da definire rispetto a SELinux, in parte grazie al learning mode. Ma la pazzia è assicurata in ogni caso? 

 

che l'RBAC di GRSecurity sia più amichevole penso proprio di potertelo confermare.

voglio dire... con GRSecurity non mi è mai capitato, per una dimenticanza, di attivare le policy e trovarmi con il computer che non rispondeva neanche alla tastiera. con SELinux si  :Sad: 

io sono convinto che la soluzione migliore (ma è una mia idea) sia la patch cumulativa con PaX e RSBAC (da non confondere con RBAC), perché riesce ad essere davvero restrittivo oltre ogni llivello umanamente concepibile senza necessariamente uccidere la macchina (ma per ottenere questo bisogna davvero rimetterci la salute mentale, perché RSBAC è contorto oltre ogni immaginazione e la documentazione si ripromettono di scriverla da anni!)

----------

## X-Drum

 *k.gothmog wrote:*   

> 
> 
> http://www.nsa.gov/selinux/

 

http://www.nsa.gov/kids/home.cfm

omg!!!

cioè nsa 4 kids ma roba da suicidio:

"decrypting information...please wait" 

i cryptokids ma chi c*** sono??? asdf

----------

## horace

 *k.gothmog wrote:*   

>  *power83 wrote:*   cosa sarebbero e a che servirebbero in dettaglio?! 
> 
> hardening PESANTE del sistema. quanto basta per avere molte applicazioni che non girano più 
> 
> sono meccanismi di protezione molto avanzati, che si usano di solito per proteggere server in produzione, o macchine che contengono dati molto importanti.
> ...

 

riuppo questo thread perchè mi hanno chiesto di mettere in piedi un server che avrà esposte su internet solo le porte per ssh e openvpn. secondo voi, mi conviene pensare ad un profilo hardened oppure basta che le due applicazioni siano ben configurate e mi oriento sui gentoo-sources?

----------

## .:deadhead:.

Io comincerei a settare la macchina a modo senza grsecurity.

Leggi la guida alla sicurezza che è stata linkata sopra. Quando avrai fatto tutto , se lo ritieni necessario, studia ed eventualmente implementa anche grsecurity

----------

## ProT-0-TypE

inizia a fare una buona configurazione base (niente servizi inutili, banner che mostrano eventuali versioni,  sistema aggiornato,ecc ecc) ma soprattutto cerca di evitare in tutti i modi che gli utenti usino guessable password!

----------

## X-Drum

 *ProT-0-TypE wrote:*   

> banner che mostrano eventuali versioni

 

vabbeh non credo che questo accorgimento aiuti ad aumentare il livello di sicurezza

della tua macchina

----------

## Kernel78

 *OpenSSH FAQ wrote:*   

> 2.14 - Why does OpenSSH report its version to clients?
> 
> OpenSSH, like most SSH implementations, reports its name and version to clients when they connect, e.g.
> 
>     SSH-2.0-OpenSSH_3.9 
> ...

 

Quindi togliere quest'informazione potrebbe causare più inconveniente di quanti potrebbe prevenirne ...

/EDIT: a meno che uno non sia un fervente sostenitore di Winzozz e della sua "security trough obscurity" (o come cavolo si scrive)

----------

## horace

 *.:deadhead:. wrote:*   

> Io comincerei a settare la macchina a modo senza grsecurity.
> 
> Leggi la guida alla sicurezza che è stata linkata sopra. Quando avrai fatto tutto , se lo ritieni necessario, studia ed eventualmente implementa anche grsecurity

 

su questo hai perfettamente ragione: solo mi era venuto il dubbio sugli scenari in cui un sistema "normale" configurato con tutti i crismi del caso è insufficiente ed è preferibile una soluzione hardened

----------

## ProT-0-TypE

 *X-Drum wrote:*   

>  *ProT-0-TypE wrote:*   banner che mostrano eventuali versioni 
> 
> vabbeh non credo che questo accorgimento aiuti ad aumentare il livello di sicurezza
> 
> della tua macchina

 

Sicuramente non ti protegge, ma se un eventuale attaccante legge:

```
SSH-2.0-OpenSSH_3.9  FreeBSD-20061010
```

oppure

```
Apache 1.27
```

già lo faciliti perchè può concentrarsi su vulnerabilità ed exploit specifici per quel sistema operativo e per quella determinata versione del demone.

PS: In ogni caso per openssh la versione (SSH-2.0-OpenSSH_3.9) NON si può eliminare. Tutto quello che al massimo puoi fare è togliere il versionaddendum (che su Gentoo di default non dovrebbe esserci)

----------

## X-Drum

 *ProT-0-TypE wrote:*   

> 
> 
> Sicuramente non ti protegge, ma se un eventuale attaccante legge:
> 
> ```
> ...

 

un potenziale (e determinato) attaccante, di certo non è cosi stupido da fermarsi alla versione riportata

dagli eventuali software presenti sulla macchina, che vuole exploitare..

pensi davvero che il non mostrare la versione del software xyz possa fargli perdere tempo o non fargli

capire cosa si trova davanti? ...andiamo questa è davvero "security through obscurity"

esistono vari modi per identificare la versione, ed in ogni caso un attaccante "lamero"

che ad esempio per sfondare apache prova a priori tutti gli exploit conosciuti dalla versione 1.x 

all'attuale 2.x, di sicuro se ne strafrega della versione che mostra o meno il server

----------

## ProT-0-TypE

infatti non lo fermi così, non ho detto assolutamente questo. Il problema è che lo puoi invece velocizzare

In ogni caso oltre alle  varie versioni di apache esistono anche altri server web, e provare tutti gli esploit per tutte le versioni di tutti i possibili server web e sicuramente più lento e complicato di cercare vulnerabilità per quella determinata versione di un determinato demone. Senza contare che molti tool automatici si basano sulle informazioni della versione.

----------

## X-Drum

 *ProT-0-TypE wrote:*   

> Senza contare che molti tool automatici si basano sulle informazioni della versione.

 

i miei log dicono il contrario, 

ti posso assicurare che per apache ad esempio, ricevo su tutte le mie macchine "attacchi automatici" 

da parte di script, che non si curano affatto della versione, o che cmq non raccolgono nemmeno informazioni

sul server che stanno attaccando, infatti molti di questi script eseguono exploit per apache serie 1.x win32!!!

----------

## Kernel78

 *ProT-0-TypE wrote:*   

> Sicuramente non ti protegge, ma se un eventuale attaccante legge:
> 
> ```
> SSH-2.0-OpenSSH_3.9  FreeBSD-20061010
> ```
> ...

 

No, lo faciliti se usi un server non patchato con delle vulnerabilità note.

Se io uso la versione x.y.z di un sw e non ci sono vulnerabilità note posso anche farlo sapere a tutto il mondo e vivere considerevolmente sicuro, al contrario se io uso una versione con delle vulnerabilità note e aperte posso anche evitare di far sapere quale versione sia ma i tool automatici da lamer provano cmq ad aprirti anche se non gli dici che versione sei.

 *ProT-0-TypE wrote:*   

> 
> 
> PS: In ogni caso per openssh la versione (SSH-2.0-OpenSSH_3.9) NON si può eliminare. Tutto quello che al massimo puoi fare è togliere il versionaddendum (che su Gentoo di default non dovrebbe esserci)

 

Il codice sorgente non è così difficilmente modificabile, soprattutto se vuoi cambiare solo una stringa ma questo non cambia il concetto che quel messaggio non è messo come utilità per i cracker ...

----------

## ProT-0-TypE

Infatti non ho detto TUTTI, ho detto alcuni. Mostrando la versione tu non ottieni nessun vantaggio, però potresti facilitare qualcuno. Per questo motivo queste cose nei pen-test vengono segnalate

 *Quote:*   

> Il codice sorgente non è così difficilmente modificabile, soprattutto se vuoi cambiare solo una stringa ma questo non cambia il concetto che quel messaggio non è messo come utilità per i cracker ...

 

La versione di openssh non la puoi eliminare per il motivo che ha scritto sopra kernel78..

----------

## X-Drum

 *ProT-0-TypE wrote:*   

>  *Quote:*   Il codice sorgente non è così difficilmente modificabile, soprattutto se vuoi cambiare solo una stringa ma questo non cambia il concetto che quel messaggio non è messo come utilità per i cracker ... 
> 
> La versione di openssh non la puoi eliminare per il motivo che ha scritto sopra kernel78..

 

si infatti entrambe le citazioni sono sue   :Wink: 

----------

## Kernel78

 *ProT-0-TypE wrote:*   

> Infatti non ho detto TUTTI, ho detto alcuni. Mostrando la versione tu non ottieni nessun vantaggio, però potresti facilitare qualcuno. Per questo motivo queste cose nei pen-test vengono segnalate

 

Non è detto, nella mia citazione delle FAQ di openssh si legge che la versione serve ...

----------

