# Gentoo profilo hardened

## stifler83

Ho installato sul mio server di casa gentoo hardened se qualcuno ha qualche tips and trick da passarmi o comunque si è già cimentato nella sua configurazione e vuole darmi una mano l'accetto volentieri  :Smile:  sopratutto per quanto riguarda pax ed rbac  :Wink: 

----------

## ago

allora...puoi iniziare a capire cosa stai facendo, leggendo qui

Successivamente puoi dare uno sguardo a un quickstart su pax e come puoi ben vedere, sul sito upstream c'è la doc su pax

Per quanto riguarda grsecurity: trovi una guida qui

Per la scrittura di policy rbac, oltre alla documentazione, se vuoi un parere tecnico, puoi sempre fare un salto su #gentoo-it ( freenode ) troverai utenti preparati in merito.

P.S. Devo cmq segnalarti che le documentazioni che ti ho linkato, prodotte dal team gentoo, sono un tantino obsolete e anche in fase di "ristrutturazione" come puoi vedere sul bugzilla

Spero di essere stato esaustivo  :Smile: 

----------

## Pes88

Colgo l'occasione di questo thread per porre anche io una domanda, gentoo-hardened + selinux potrebbe essere una buona soluzione per un server virtuale??? Un buon compromesso tra sicurezza è prestazioni?

 O le altre distribuzioni ( mi riferisco principalmente a debian e redhat ) mi danno un livello di sicurezza migliore ?

E secondo voi il fatto di dover compilare ogni cosa è troppo impegnativo per un server di piccole dimensioni???

----------

## djinnZ

PAX serve (detto in modo molto riduttivo) a proteggersi dagli exploit e lo si può utilizzare indipendentemente da grsec/selinux/appaarmour (nelle ultime versioni è comparso anche questo). L'impatto sulle prestazioni non è drammatico ma lo si avverte, soprattutto in fase di build e se vuoi usare java o mono saltano fuori diversi fastidi (basta vedere OOo ed il bug per la compilazione irrisolto da almeno due anni).

grsec è meglio se segui il wiki ufficiale del progetto.

Selinux... premesso che è rognoso, premesso che ha un impatto sulle prestazioni ed in particolare sull'IO (l'unico trucco è montare i filesystem preimpostando gli attributi in certi casi), premesso che una cosa partorita dalla NSA non può essere utile, premesso che mi ricorda troppo le policy del piffero di quell'altro... se vuoi farti del male usalo. Di buono ha solo che è l'unico sistema di sicurezza che ha già un nutrito pacchetto di policy predefinite.

@Pes88 vedi che esiste anche il crossbuild od il banale chroot e pacchetti binari (soluzione che ho applicato per anni, compilo, verifico le dipendenze e poi aggiorno). Non devi compilare sul server (anzi sarebbe meglio evitarlo).

Debian è debian (non mi piace, a causa di certi loschi figuri tendo sempre ad associare la definizione di debianista a solone del piffero, ma è apprezzabile, aggiornamento più lento rispetto a gentoo ma molto solido e ben verificato) ma quanto a RH (che schifo dalla rel 4, per gravi mancanze) è come usare M$ senza il supporto hardware di M$, stessi costi, stesse assurde limitazioni, stessa impostazione del "reinstalla al minimo problema", stesso divieto implicito a personalizzare. Stai parlando di un prodotto commerciale ottuso a misura del tecnico bimbominkia buono solo a metter il dvd nel computer e reinstallare ma con il software commerciale lo impongono, è solo grazie a questo ed all'idiota tendenza a pensare che più una cosa costa meglio deve essere che si mantiene in piedi IMHO (ok hanno provato ad impormelo e sono un tantino storto in materia).

 *ago wrote:*   

> puoi sempre fare un salto su #gentoo-it ( freenode ) troverai utenti preparati

 a farti venire il mal di testa...  :Laughing: 

----------

## ago

 *Pes88 wrote:*   

> Colgo l'occasione di questo thread per porre anche io una domanda, gentoo-hardened + selinux potrebbe essere una buona soluzione per un server virtuale??? Un buon compromesso tra sicurezza è prestazioni?
> 
>  O le altre distribuzioni ( mi riferisco principalmente a debian e redhat ) mi danno un livello di sicurezza migliore ?

 

Allora..andiamo con ordine...con gentoo-hardened hai la particolarità di compilare il tutto avendo poi dei binari in posizione random in memoria...e in questo modo aiuti pax a svolgere il suo lavoro.

 *djinnZ wrote:*   

> PAX serve (detto in modo molto riduttivo) a proteggersi dagli exploit e lo si può utilizzare indipendentemente da grsec/selinux/appaarmour

 

Forse è stato troppo riduttivo..pax non protegge da tutti i tipi di exploit ma diciamo buffer overflow e roba annessa...

 *Pes88 wrote:*   

> E secondo voi il fatto di dover compilare ogni cosa è troppo impegnativo per un server di piccole dimensioni???

 

No, ovviamente non settando un makeopts molto alto qualsiasi pc riesce a compilare..ovviamente ognuno ha la sua tempistica, ma se l'hardware è sano ( disco , ram, cpu ) va a buon fine..

Cmq tornando al punto che chiedevi...usare gentoo-hardened + selinux può essere una buona soluzione ma specifichiamo meglio:

nella maggior parte dei casi dire di usare gentoo hardened comprende l'uso di pax/grsec, e in base a quello che so, è molto difficile far funzionare insieme grsecurity + selinux se non addirittura praticamente impossibile

Detto questo non ti resta che usare tutta la toolchain hardened senza grsecurity e usare selinux. A questo punto visto che selinux è un software che ti permette di scrivere/utilizzare policy mac mi sento obbligato di informarti che anche grsecurity ha il suo sistema mac chiamato rbac.

In sintesi se vuoi gentoo-hardened + della policy mac puoi scegliere l'ultima soluzione postata.

N.B. usare selinux come è stato già detto significa usare al 90% delle policy già fatte, mentre con rbac crei la tua policy con poca fatica ma perfettamente adatta al tuo sistema.

 *djinnZ wrote:*   

> @Pes88 vedi che esiste anche il crossbuild od il banale chroot e pacchetti binari (soluzione che ho applicato per anni, compilo, verifico le dipendenze e poi aggiorno). Non devi compilare sul server (anzi sarebbe meglio evitarlo).

 

Come mai evitare di compilare?

su red hat e debian se ne potrebbe parlare diversamente ma si rischia di andare OT  :Wink: 

----------

## Pes88

ok!! 

Quindi diciamo che la soluzione migliore è gentoo-hardened + grsecurity, cosi mi faccio un bel po di esperienza nello scrivere le policity !!  :Smile: 

Io avevo scelto  selinux, perché ho visto che è quello più diffuso, è ho pensato che fosse il migliore! 

La mia unica preoccupazione per questo server è di ottenere un buon livello di sicurezza , prima di tutto la sicurezza dipende principalmente da chi configura il software, quindi una configurazione scadente mi pregiudica tutto il sistema, però una gentoo-hardenden+grsecurity+firewall è buona soluzione??

 O si possono trovare soluzioni software migliori???

----------

## ago

Imho puoi sempre valutare soluzioni tipo bsd  :Wink: 

----------

## Pes88

 *Quote:*   

> 
> 
> Imho puoi sempre valutare soluzioni tipo bsd 
> 
> 

 

Perchè usare un sistema tipo FreeBSD dovrebbe garantire un miglior livello di sicurezza?? 

Ho visto che le politiche di sicurezza più o meno sono uguali...

----------

## djinnZ

PAX è indipendente da grsec e può convivere con selinux (ma a questo punto andrei più su apparmour o se vuoi farti del male vai su rsbac che resta il top in termini di possibilità ma anche di rogne). Per certi versi è il giusto completamento dell'hardening ma opera a livello kernel.

grsec con selinux è possibile ma sarebbe una inutile duplicazione dei controlli, fanno entrambi pressapoco le stesse cose. Diciamo che se devi installarti il tipico server smb+web+sql+php+java selinux ti offre un buon livello di protezione già pronto, grazie al lavoro di pebenito&c ed alla diffusione della soluzione (puoi anche andarti a scopiazzare le policy da centos per dirne una). Però è lento (soprattutto con moti piccoli file, ti ho già indicato il tip per aggirare ma richiede un partizionamento estremamente complesso), non è questa gran cosa e gli attributi occupano spazio.

grsec +pax è un buon compromesso per un sistema su misura, senza dipendenze e servizi inutili.

rsbac ti consente anche di decidere cosa può scrivere e cosa no il singolo processo in base alla porta ip alla quale si è connesso, all'utente proprietario ed all'ora in cui viene eseguito per dirne una ma è qualcosa di mostruoso da configurare (d'altro canto l'estrema granularità dovrebbe essere il suo punto di forza).

Ed almeno nella mia esperienza è facile che policy ed attributi vadano in malora (backup necessario) o che perdi l'accesso all'amministratore, che è realmente distinto rispetto agli altri sistemi.

Caveat: rsbac non brilla per stabilità, è estremamente complesso ed articolato e per scrivere le policy devi partire praticamente da zero e persino la documentazione ufficiale del progetto ha dei buchi (nel senso che ci sono funzioni completamente non documentate). Predisporre le policy è realmente una fatica immane. Ti sconsiglio vivamente il cimento a meno che non hai molto tempo da perdere e certo non su una macchina per lavoro.

Con le applicazioni bytecode il problema essenziale è che non puoi impostare i permessi speciali per accedere a memoria o device su un codice generato al momento, dovresti attribuire al runtime i privilegi di amministratore ed a questo punto rendi il sistema vulnerabile a tutti gli exploit possibili. Ovviamente puoi anche decidere di utilizzare parzialmente le opzioni di pax e grsec.

Tip importante che ora mi sovviene: abilita tutte le opzioni grsec per logging, chroot jail etc (compresa la flag per abilitarle tutte di default) e poi te le disabiliti tramite sysctl.conf. Decisamente meglio anche se non potrai fare a meno di avere una sfilza di log di violazione ad ogni avvio.

Attenzione che qualche incompatibilità con xen/kvm c'è (virtualbox crasha che è un piacere ma non mi sono ancora neppure applicato a vedere se riporta un qualche errore e se non dipende da un errore di configurazione).

@ago: vero che il revdep-rebuild non è più così necessario ma non mi pare utile utilizzare su una macchina di lavoro una distribuzione che può richiedere ore per il ripristino di una funzione durante l'aggiornamento.

Compili su un'altra macchina, al massimo usi un chroot, quando sei certo che tutto sia stato aggiornato e le dipendenze risolte aggiorni con i binari.

Te lo immagini un webserver che resta fermo per due ore perchè dopo aver aggiornato la libc devi attendere che siano ricompilati apache, java, php e server sql. O che si schianti apache e solo dopo un giorno ti rendi conto che lo dovevi ricompilare?

Meglio evitare. Lo dico perché mi è successo ai tempi della prima gentoo o forse quando ancora andavo di LFS, ho aggiornato, me ne sono andato, ma non mi sono accorto che il demone di stampa (forse era ancora lpd) si schiantava. Mezza giornata di lavoro persa ed il pomeriggio a lavorare a rilento mentre ricompilavo mezzo mondo.

Perché complicarsi la vita inutilmente?

Un'ultima considerazione: le distribuzioni binarie, in particolare RH, richiedono policy estremamente severe che su gentoo non sono così indispensabili come sembra dato che (sempre che non sei così scemo da abilitare ed installare l'impossibile) non hai altro che quel che ti serve ed hai deciso di installare, non ci sono potenziali pacchetti vulnerabili autoconfigurati in automatico. Mi pare che fosse proprio RH o suse che in automatico ti installava nis bind e telnet ad ogni aggiornamento e li lasciava attivi e malconfigurati (tanto le impostazioni di default del firewall prevedevano i rifiuto di tutte le connessioni... che str******).Last edited by djinnZ on Fri Jan 14, 2011 7:09 pm; edited 1 time in total

----------

## lavish

Ciao stifler83, Pes88, etc  :Smile: 

Sono l'"utente preparato in merito" a Grsecurity RBAC, con vaghe nozioni anche sugli altri sistemi MAC... e no, sono qui non per farvi venire il mal di testa.

Tralasciando un attimo le varie considerazioni piu' o meno corrette gia' fatte dagli altri, la cosa principale che dovete capire su un sistema in cui implementare una policy di sicurezza e' "cosa voler proteggere da chi". Rispondere a questa domanda in modo esaustivo non e' per nulla banale, ma farlo vi condurra' sicuramente verso la soluzione migliore per voi. Ricordate in ogni caso che nell'ambito della sicurezza non esiste una panacea e ogni sistema soddisfa un determinato set di esigenze.

Ci tengo a precisare alcune cose, riguardo a quanto detto da prima:

PaX non e' indipendente da Grsecurity, ma ne fa parte;

Grsecurity e' utilizzabile con SELinux, ma usare i sistemi di controllo degli accessi delle 2 soluzioni penso sia da folli;

le policy di SELinux non ben testate su gentoo, non sono l'unico a ritenere che SELinux sia per ora usabile in produzione solo su Fedora/RH,

visto il suo utilizzo su Ubuntu, penso che il sistema MAC piu' diffuso sia AppArmor, non SELinux anche se sicuramente e' di quest'ultimo che si sente parlare maggiormente.

Inoltre aggiungo qualche considerazione personale:

Usare chroot per proteggere le applicazioni, a meno di non farne hardening dei chroot tramite Grsecurity, e' non solo inutile, ma anche dannoso;

dei sistemi *BSD, l'unico che implementa un sistema MAC e' FreeBSD, ma a parte alcuni aspetti teorici non ne so molto.

Ciao  :Smile: 

----------

## djinnZ

 *lavish wrote:*   

> PaX non e' indipendente da Grsecurity, ma ne fa parte;

 a livello di codice e progetto, nelle opzioni di configurazione puoi lasciare anche la sezione grsec del tutto disabilitata (impostare mac integration a none, ovviamente). Chiaramente la protezione è estremamente parziale e si pone qualche problema in più ma ... se non ritieni necessario e vuoi solo evitare buffer overflow ed isolare i processi kernel basta ed avanza ( quanto sia utile poi è una questione di ... risultati  :Laughing:  ma val la pena di tenerlo presente).

A queste condizioni non incasina troppo selinux, lo ho usato ed andava (era selinux il problema). gradm non dovrebbe poter proprio funzionare con selinux attivo per dirne una.

Tanto per discorrere della cosa, considera che i tempi d'accesso (copia sequenziale in scrittura o lettura dell'intera dir, in scrittura sia creando che riscrivendo) su una partizione da 20GB con più 16GB di roba in file della dimensione media di mezzo kB (quindi ho specificato che ero di fronte ad un filesystem saturo) si dimezzavano al mount con context=... (non ho mai verificato la differenza di prestazioni tra selinux con context ed un sistema normale ma credo che ci sia comunque una differenza notevole). A livello di filesystem solo ext3 mi è parso gestirlo bene (xfs i problemi li dovrebbe aver risolti da tempo, reiser 3 continuava ad andar male per quel che so e le versioni successive... boh.

Vero anche che sono passati diversi annetti da quando usavo selinux ma non credo che lo abbiano migliorato più di tanto.

Adesso non posso ripescare la configurazione del vecchio server ma problemi non me ne ha dati.

 *lavish wrote:*   

> Usare chroot per proteggere le applicazioni

 Dipende da cosa vuoi proteggere. Se vuoi proteggere il sistema dalle applicazioni concordo che resta una str... (che poi se ti ricordi da quale ambito è partita...); se vuoi proteggere le applicazioni dal sistema (principalmente per superare le incompatibilità di path e libreria di applicativi proprietari, come capita a me) non è che ci siano molte alternative a parte la virtualizzazione, che comunque pone altri limiti in ordine al partizionamento soprattutto.

Se poi vuoi proteggere la funzionalità delle applicazioni dagli upgrade l'unica strada alternativa (e certamente migliore, la compilazione è un carico pesante) è il crossbuild.

Per me gli upgrade diretti, su un sistema "in produzione", restano una soluzione pericolosa.

Che poi molti usino il chroot per ragioni di sicurezza dipende anche dalla presenza di pacchetti come chroot-bind e dalla completa assenza di qualsiasi documentazione in tal senso.

@ago: quale bsd? net, free, open o cosa?

@stifler83 & pes88: ora dovresti avere un'idea delle possibilità. Chiaramente se tutto il tuo problema è impedire che da un ambiente virtualizzato si possa influire sull'host senza badare alle cavolate che gli uttenti delle macchine virtuali possono fare mi orienterei prima di ogni cosa sulla costruzione di una immagine totalmente read only del sistema, a kernel assolutamente monolitico.

Considera anche che con il patchset hardened il kernel gradisce poco eventuali altre patch ed il suo aggiornamento è leggermente più lento rispetto ai kernel "normali" (i driver proprietari possono essere un autentico incubo da gestire per dirne una).

bada che i profili hardened, hardened+selinux ed selinux sono diversi e non puoi passare allegramente dall'uno all'altro.

Per esempio sul mio sistema attuale uso solo le impostazioni base per pax e grsec solo per il chroot jail in pratica.

Di più non credo proprio che mi serva per l'uso che ne faccio. Ma questa è la mia esigenza visto che tutto quello che posso temere è qualche script kiddie  che tenti di bucare il server acceso quattro/otto ore al giorno, su ip dinamico o che tentino di entrare nel wifi che attivo manualmente solo quando devo connettermi.

----------

## Pes88

Grazie mille per le risposte, mi avete dato un bel po di informazioni!   :Razz:   :Razz:   :Razz:   :Razz: 

Penso che metterò su gentoo-hardened + grsecurity ....   :Laughing:   :Laughing:   :Laughing: 

----------

## ago

Mi secca fare diversi quote...rispondo in maniera veloce:

@djinnz intendevo freebsd

Per quanto riguarda la compilazione, non ho mai avuto problemi simili e certamente non escludo che li possa riscontrare in futuro, ma se si presta poco poco di attenzione non succede mai nulla di tragico. Certo che se per un minuto che il server va giù ti levano mezzo stipendio, ci pensi due volte  :Very Happy: 

@pes

Siccome si è parlato di linux, hardening e altro, e tu chiedevi ancora più sicurezza, ti suggerivo di provare il sistema bsd, qualora non l'avessi già fatto, e fare successivamente dei test con cui puoi stabilire qual'è più affidabile...il senso era più o meno questo.

----------

## djinnZ

 *ago wrote:*   

> se si presta poco poco di attenzione

 dato che l'errore di distrazione o la riscrittura frettolosa di una intera configurazione capita facilmente ed il costo, in termini di risorse, di un chroot è veramente minimo... più che altro non mi sono mai fatto il problema di farne a meno.

Poiché una gentoo hardened con kernel grsec qualche problema in più lo comporta (anche una acl personalizzata e dimenticata in fase di aggiornamento può bloccare qualcosa) sconsiglio di fare a meno del chroot se non si è più che scafati e non su una macchina di lavoro.

In generale mantenere uno snapshot pre-update del portage e generare i pacchetti binari (gestione implicita nel chroot) potrebbe essere un'alternativa ma sono troppo sfaticato per andare a pensare di ripristinare.

----------

## mack1

Ciao volevo solo aggiungere un paio di link che ti possono aiutare:

1-uno script che ti mostra le varie features di pax/grsecurity attive sul tuo sistema:

http://www.trapkit.de/tools/checksec.html

2-una comparazione dell'uso di alcune tecniche di hardening (grsec/pax con relro,ssp,alsr, bit nx,etc) da parte di alcune distro linux (gentoo hardened,opensuse,ubuntu,fedora e debian):

http://labs.mwrinfosecurity.com/notices/security_mechanisms_in_linux_environment__part_1___userspace_memory_protection/

http://labs.mwrinfosecurity.com/notices/assessing_the_tux_strength_part_2_into_the_kernel/

Ciao

----------

## theroot

Ciao a tutti,

ho letto con interesse la vostra discussione, sto infatti pensando di fare un installazione di Gentoo Hardened nella speranza di rendere più sicure le macchine che gestisco, visto che mi è già successo di trovarmi qualche rootkit (difficile sempre capire quale da quale servizio entrano). Devo ammettere che qualche dubbio mi è rimasto...

Sono dell'idea di utilizzare Pax + Grsec e, se ho capito bene, anche PIE che va a braccetto con Pax. Mi viene un primo dubbio sul fatto che l'utilizzo di Pax+Pie potrebbe appesantire la macchina diminuendo sensibilmente le prestazioni. Avete esperienza in merito?

Sulla mia Gentoo, lanciando

```
eselect profile list
```

vedo che ci sono più profili 'hardened'. Volendo usare Pax + Grsec, il profilo che dovrei scegliere è il numero 8?

```

Available profile symlink targets:

  [1]   default/linux/amd64/10.0

  [2]   default/linux/amd64/10.0/desktop

  [3]   default/linux/amd64/10.0/desktop/gnome

  [4]   default/linux/amd64/10.0/desktop/kde

  [5]   default/linux/amd64/10.0/developer

  [6]   default/linux/amd64/10.0/no-multilib

  [7]   default/linux/amd64/10.0/server

  [8]   hardened/linux/amd64

  [9]   hardened/linux/amd64/no-multilib

  [10]  selinux/2007.0/amd64

  [11]  selinux/2007.0/amd64/hardened

  [12]  selinux/v2refpolicy/amd64

  [13]  selinux/v2refpolicy/amd64/desktop

  [14]  selinux/v2refpolicy/amd64/developer

  [15]  selinux/v2refpolicy/amd64/hardened

  [16]  selinux/v2refpolicy/amd64/server

```

La scelta del filesystem può indicere sulla sicurezza della macchina? Io sono un afecionados reiserfs.

 *Quote:*   

> @Pes88 La mia unica preoccupazione per questo server è di ottenere un buon livello di sicurezza , prima di tutto la sicurezza dipende principalmente da chi configura il software, quindi una configurazione scadente mi pregiudica tutto il sistema, però una gentoo-hardenden+grsecurity+firewall è buona soluzione??

 

Sul discorso firewall si potrebbe aprire una discussione che finirebbe per essere OT. In realtà il firewall è un buon compromesso ma non è la soluzione: se infatti sono attivi solo i servizi necessari e il bind sull'ip pubblico viene fatto solo dai servizi che devono essere visti dal mondo, il firewall non è necessario ma utile. In caso di attacco alla macchina è probabilissimo trovarsi le regole di fw cambiate  :Sad: 

E' sicuramente un 'in più' avere un firewall davanti ai server.

 *Quote:*   

> @djinnZ Compili su un'altra macchina, al massimo usi un chroot, quando sei certo che tutto sia stato aggiornato e le dipendenze risolte aggiorni con i binari.

 

Io tengo una macchina o hard disk uguale all'altra, compilo su quella di backup e se vedo che tutto si è aggiornato correttamente e continua a funzionare, replico l'aggiornamento sull'altra; non è proprio la soluzione 'più comoda' ma in diverse occasioni mi ha salvato da restart falliti dopo un emerge.

 *Quote:*   

> @djinnZ Dipende da cosa vuoi proteggere. Se vuoi proteggere il sistema dalle applicazioni concordo che resta una str... (che poi se ti ricordi da quale ambito è partita...); se vuoi proteggere le applicazioni dal sistema (principalmente per superare le incompatibilità di path e libreria di applicativi proprietari, come capita a me) non è che ci siano molte alternative a parte la virtualizzazione, che comunque pone altri limiti in ordine al partizionamento soprattutto.

 

 *Quote:*   

> lavis Usare chroot per proteggere le applicazioni, a meno di non farne hardening dei chroot tramite Grsecurity, e' non solo inutile, ma anche dannoso.

 

Mi aiutate a capire meglio? Ho sempre pensato che chrootare i servizi esposti in rete (esempio: bind, postfix, ecc ecc) servisse da un lato per replicare l'ambiente minimo che serve al servizio, dall'altro a fare in modo che un attaccante veda come root la directory chroot del servizio e non tutto il filesystem. Non è così?

Ho ancora qualche domanda in mente, continuo a documentarmi e leggere, leggere...e magari trovo la risposta da solo  :Smile: 

Ciao a tutti.

----------

## djinnZ

Beh le prestazioni calano per forza ma nulla di preoccupante (sarà la millesima volta che lo ripeto, va a finire che dovrò editare la signature).

I profili sono 8 o 9 secondo se vuoi multilib o meno.

reiserfs 3.6 mi ha dato problemi solo con selinux.

Una volta acquisiti i privilegi di root ci sono diversi modi di tirarsi fuori dal chroot ed andare a romper le scatole al sistema host od ai suoi servizi, grsec ha delle opzioni apposite per evitare seccature di questo genere (come CHROOT_SHMAT, FINDTASK, SYSCTL E UNIX, anche se al momento proprio lo ho disabilitato).

Usando il chroot su un sistema "normale" hai un minimo di protezione in più ma... non è questa gran garanzia e proprio un minimo in più.

Premesso che ormai nessuno più si sogna di andare ad impostare adeguatamente i permessi nel chroot ed il primo vecchio trucco era crearsi un eseguibile suid (CONFIG_CHROOT_CHMOD) per lanciare una shell superuser da utente normale e legittimo.

Come ho detto io lo trovo comodissimo al contrario, per poteggere i servizi "chrootati" (che orrido barbarismo) dagli aggiornamenti del sistema, non per proteggere il sistema dalle loro eventuali vulnerabilità.

Lasciando perdere le implicazioni del codice ricorda che PAX non implica grsec e viceversa e che pie è una cosa del compilatore. Vedi a cosa serve ogni cosa e decidi se abilitarlo.

Per esempio se usi il chroot solo per compilare le protezioni servono solo a crearti problemi.

----------

## ago

 *djinnZ wrote:*   

> ricorda che PAX non implica grsec e viceversa

 

Sul viceversa io direi di no, di fatti abilitando grsec ti trovi abilitato forzatamente PaX..se poi c'è qualche trucchetto per disabilitarlo me lo sto perdendo  :Very Happy: 

 *theroot wrote:*   

> Mi viene un primo dubbio sul fatto che l'utilizzo di Pax+Pie potrebbe appesantire la macchina diminuendo sensibilmente le prestazioni. Avete esperienza in merito?

 

Pax+pie+ssp etc. non rallentano..forse grsec potrebbe appesantire ( io non ho mai notato particolari rallentamenti )

 *theroot wrote:*   

> vedo che ci sono più profili 'hardened'. Volendo usare Pax + Grsec, il profilo che dovrei scegliere è il numero 8?

 

pax+grsec li puoi usare anche su ubuntu, se ha senso o meno è un'altro discorso, ma il punto è che basta patchare i sorgenti del kernel.

 *theroot wrote:*   

> Sul discorso firewall si potrebbe aprire una discussione che finirebbe per essere OT. In realtà il firewall è un buon compromesso ma non è la soluzione: se infatti sono attivi solo i servizi necessari e il bind sull'ip pubblico viene fatto solo dai servizi che devono essere visti dal mondo, il firewall non è necessario ma utile. In caso di attacco alla macchina è probabilissimo trovarsi le regole di fw cambiate 
> 
> E' sicuramente un 'in più' avere un firewall davanti ai server.

 

Il firewall nel tuo caso non serve a nulla...a limite qualche regola particolare ti evita qualche possibile piccolo DoS ma nulla di più

----------

## djinnZ

 *ago wrote:*   

> se poi c'è qualche trucchetto

   :Shocked:  giuro che alle volte... mi trattengo a stento. basta usare il profilo custom come tuitte le persone normali. *ago wrote:*   

> Pax+pie+ssp etc. non rallentano

 come ho detto non val la pena di curarsene, non con gentoo e non su una cpu attuale ma puoi sempre provare a compilare OOo su un vecchio athlon per vedere

----------

## ago

 *djinnZ wrote:*   

> basta usare il profilo custom come tuitte le persone normali.

 

pardon..non ci avevo fatto caso usando sempre altri profili

----------

## theroot

La prima installazione di Gentoo Hardened è riuscita con successo, devo solo prendere praticità con pax e grsec, per ora sono ancora 2 entità non pienamente sotto il mio controllo; dopodiché posso mettere gli hard disk nel pc di destinazione. 

Come faccio solitamente, ho messo l'hard disk da installare nel mio pc e ho avviato il mio sistema operativo Gentoo: dopo aver formattato e copiato stage e portage hardened mi sono chrootato e ho compilato il kernel. Una volta terminato e configurato grub, posso partire con il gentoo hardened...

Domanda leggermente OT: invece di fare il boot sul sistema hardened che non ha ambiente grafico, è fattibile lanciare il mio sistema Gentoo e poi chrootarmi per poi installare i pacchetti mancanti? Il mio dubbio principale è se può cambiare qualcosa visto che il mio sistema Gentoo non è hardened e non ha la stessa versione del kernel.

Tornando al discorso sicurezza, districandomi nella documentazione Gentoo, non aggiornatissima, viene consigliato di emergere chpax e paxctl se si usano alcuni pacchetti tipo x11, java... Non essendo il mio caso ho lasciato stare: avete notato problemi su macchine server senza averli installati?

Mi rimetto a configurare la macchina, prossimo passo e creare delle regole (simili a quelle di Selinux) per qui se provo a lanciare un servizio non nella sua porta standard non ci riesco  :Smile: 

Per testare pax e grsec avete suggerimenti?

A presto

P.S: ho lasciato il syslog con la configurazione di default di Gentoo Hardened, grsec.log e kern.log hanno delle dimensioni stratosferiche... a breve non li loggo più.

----------

## ago

 *theroot wrote:*   

>  invece di fare il boot sul sistema hardened che non ha ambiente grafico, è fattibile lanciare il mio sistema Gentoo e poi chrootarmi per poi installare i pacchetti mancanti? Il mio dubbio principale è se può cambiare qualcosa visto che il mio sistema Gentoo non è hardened e non ha la stessa versione del kernel.

 

chrootandoti usi gcc hardened

 *theroot wrote:*   

> Tornando al discorso sicurezza, districandomi nella documentazione Gentoo, non aggiornatissima, viene consigliato di emergere chpax e paxctl se si usano alcuni pacchetti tipo x11, java... Non essendo il mio caso ho lasciato stare: avete notato problemi su macchine server senza averli installati?

 

vedi a cosa servono e se fanno al tuo caso

 *theroot wrote:*   

> Per testare pax e grsec avete suggerimenti?

 

```
paxtest blackhat
```

 o mettiti a fare pentest

 *theroot wrote:*   

> P.S: ho lasciato il syslog con la configurazione di default di Gentoo Hardened, grsec.log e kern.log hanno delle dimensioni stratosferiche... a breve non li loggo più.

 

Male, ad occhio direi che c'è qualche problema

----------

## djinnZ

 *theroot wrote:*   

> è fattibile lanciare il mio sistema Gentoo e poi chrootarmi per poi installare i pacchetti mancanti?

 Il problema è nelle use e nella configurazione dei kernel. Di norma al profilo e kernel hardened si accompagnano acl ed xattr. Non so qual è la tua configurazione ma nel caso verifica e provvedi ad attivare le stesse cose anche nell'host non-hardened.

Guarda che una cosa è fare a meno di X altra fare a meno della grafica. Puoi benissimo pensare di installare solo i pacchetti grafici ma non X ed usarli "da remoto", come si è sempre fatto sui server dai lontani anni '70 in cui X è nato.

 *theroot wrote:*   

> chpax e paxctl

 la questione è: se hai X o java senza non puoi proprio far funzionare il sistema ma non è che altri pacchetti non ne abbiano necessità quindi almeno paxctl ci vuole, chpax è utile se hai binari legacy ed hai abilitato PAX_EI_PAX invece e non è detto che ti serva per forza.

 *theroot wrote:*   

> grsec.log e kern.log

 Verifica NETFILTER_XT_MATCH_GRADM=n tra le tante, azzera i log, avvia il sistema senza nulla, dopo avvii l'autolearn e fai partire i servizi uno alla volta e configuri le eccezioni.

Bada che per default, se non erro, i processi anonimi non possono usare nessuna porta piuttosto. Controlla quale utente lo esegue.

----------

## theroot

 *djinnZ wrote:*   

>  *theroot wrote:*   è fattibile lanciare il mio sistema Gentoo e poi chrootarmi per poi installare i pacchetti mancanti? Il problema è nelle use e nella configurazione dei kernel. Di norma al profilo e kernel hardened si accompagnano acl ed xattr. Non so qual è la tua configurazione ma nel caso verifica e provvedi ad attivare le stesse cose anche nell'host non-hardened.
> 
> 

 

Avevo il sospetto che non fosse così semplice; per non rischiare di lasciare qualche pezzo per strada mi fido di più riavviare sul SO hardened e lavorarci direttamente.

 *ago wrote:*   

> paxtest blackhat o mettiti a fare pentest

 

Oh caspita, paxtest è masked (almeno su amd64).

 *djinnZ wrote:*   

> 
> 
> Guarda che una cosa è fare a meno di X altra fare a meno della grafica. Puoi benissimo pensare di installare solo i pacchetti grafici ma non X ed usarli "da remoto", come si è sempre fatto sui server dai lontani anni '70 in cui X è nato.
> 
> 

 

Senza installare le librerie di X non credo di riuscire ad installare, ad esempio, wireshark con il flag gtk.

 *djinnZ wrote:*   

> 
> 
> .....almeno paxctl ci vuole, chpax è utile se hai binari legacy ed hai abilitato PAX_EI_PAX invece e non è detto che ti serva per forza
> 
> 

 

Ok, paxctl l'ho installato, PAX_EI_PAX l'ho abilitato, mentre NETFILTER_XT_MATCH_GRADM è disabilitato (ho lasciato il valore originario) anche se non mi dispiace abilitarla, per ora la lascio così alla fine dell'installazione la provo.

Sul discorso kern.log e grsec.log:

 *djinnZ wrote:*   

>  azzera i log, avvia il sistema senza nulla, dopo avvii l'autolearn e fai partire i servizi uno alla volta e configuri le eccezioni.
> 
> 

 

 *ago wrote:*   

> Male, ad occhio direi che c'è qualche problema

 

Ho riletto con attenzione la quickstart di grsec (http://grsecurity.net/quickstart.pdf) ed ho trovato la soluzione al problema dei log enormi, praticamente loggavo tutto l'impossibile: ho seguito i suggerimenti del paragrafo Kernel Auditing (settando i vari OFF, tranne (Un)Mount logging che è ON e non modificabile da make menuconfig).

Ho trovato interessante CONFIG_GRKERNSEC_BLACKHOLE che ho abilitato, anche sbagliando a configurare il firewall sono sicuro che la macchina non manda pacchetti RST a seguito di richieste su porte non attive.

Nella mia conf è abilitata (non modificabile da make menuconfig) CONFIG_GRKERNSEC_SYSCTL_ON

```
CONFIG_GRKERNSEC_SYSCTL_ON:                                             

   If you say Y here, instead of having all features enabled in the                                       

   kernel configuration disabled at boot time, the features will be                                        

   enabled at boot time.  It is recommended you say Y here unless                                         

   there is some reason you would want all sysctl-tunable features to                                     

   be disabled by default.  As mentioned elsewhere, it is important                                        

   to enable the grsec_lock entry once you have finished modifying                                         

   the sysctl entries.

```

vediamo se ho capito bene: questa config va a braccetto con kernel.grsecurity.grsec_lock.

Configuro il mio sistema attivando in /etc/sysctl.conf i parametri kernel che mi servono; una volta completato aggiungo nel file kernel.grsecurity.grsec_lock = 1 e al prossimo boot non riuscirò più a modificare niente con sysctl.

 *djinnZ wrote:*   

> ...dopo avvii l'autolearn e fai partire i servizi uno alla volta e configuri le eccezioni

 

Ora installo tutti i pacchetti server che mi servono, li configuro e poi lancio l'autolearn subito prima di farli partire (spengo prima anche vixie-cron, syslog, ssh, iptables e la rete?)

----------

## ago

 *theroot wrote:*   

> Oh caspita, paxtest è masked (almeno su amd64).

 

Non è stabile, è testing, c'è una bella differenza con masked

----------

## djinnZ

Sembra che hai capito qual è l'andazzo tuttavia:  *theroot wrote:*   

> mi fido di più riavviare sul SO hardened e lavorarci direttamente.

 Guarda che è semplice, verifica che tutte le use e le opzioni del kernel relative ad acl, quota, security labels, xattr e compagnia corrispondano, niente di più. In realtà sarebbe solo un problema di configurazione del kernel ma nel dubbio ti consiglio di attivarle, l'importante è che ci sia il supporto non che le usi (sull'host non-hardened).

Piuttosto visto che ti sei dimenticato di installare chpax e paxctl darei un bell'emerge -e @world per esser certo che non ci siano binari privi delle eccezioni necessarie al loro corretto funzionamento.

 *theroot wrote:*   

> Senza installare le librerie di X non credo di riuscire ad installare, ad esempio, wireshark con il flag gtk.

 X (server) ha bisogno di accedere all'hardware per funzionare e ha problemi con alcune funzioni di pax e grsec le librerie X necessarie ai programmi no. E sono due cose distinte e separate. L'unico problema che puoi trovare è che di sicuro non potrai aprire un socket od una connessione di rete con user anonimo quindi se lanci un programma grafico da remoto su untente anonimo (o quale hai configurato bloccato) grsec lo schianta ma non c'entra niente con il suppporto grafico.

Rifletti più che altro se ti conviene abilitare X (use) per pacchetto piuttosto che globalmente e ricorda che emerge xorg è male.

 *theroot wrote:*   

> Ok, paxctl l'ho installato, PAX_EI_PAX l'ho abilitato

 e quindi ti serve anche chpax (e non rompere sono pochi Kb di eseguibile) *theroot wrote:*   

> mentre NETFILTER_XT_MATCH_GRADM è disabilitato (ho lasciato il valore originario) anche se non mi dispiace abilitarla, per ora la lascio così alla fine dell'installazione la provo.

 perfetto, per ora lascialo disabilitato, dopo aver configurato le policy la abiliti. Adesso ti darebbe solo ulteriori log di violazione e ti complica il lavoro.

 *theroot wrote:*   

> Sul discorso kern.log e grsec.log

 Io uso la configurazione "custom" da sempre (anche perchè quando ho inizato ad usare grsec era l'unica opzione accettabile e perchè preferisco avere mano libera nelle singole scalte) quindi non ricordo le altre opzioni quali selezioni bloccano.

In ogni caso sysctl_on abilita tutte le opzioni controllabili da sysctl invece di lasciarle disabilitate. Solo questione di preferenze nella gestione di sysctl.conf, senza devi abilitare quel che ti serve con devi disabilitare quello che non ti serve.

grsec_lock invece disabilita la possibilità di ricorrere a gradm per gestire le eccezioni.

Sono due cose distinte.

C'è anche una opzione per restringere il logging ad un singolo gruppo se è per questo.

 *theroot wrote:*   

> ... lancio l'autolearn subito prima di farli partire ...

 esatto, avviato l'autolearn devi riavviare (non ti serve fermali) i servizi uno alla volta secondo l'ordine di boot, poi aggiungi ad rc ed avvii manualmente tutti i serivizi che ti servono.

Continua a studiartelo, male non ti fa di certo e (strano) pare che per te non sia un problema.

ps: paxtest & C devo ancora comprendere quale utilità possano avere ma poi mi dicono che sono il solito retrogrado.

----------

## ago

 *djinnZ wrote:*   

> ps: paxtest & C devo ancora comprendere quale utilità possano avere ma poi mi dicono che sono il solito retrogrado.

 

Ti dice se pax sta funzionando correttamente o meno  :Razz: 

----------

## djinnZ

appunto...  :Confused: 

----------

## theroot

 *ago wrote:*   

>  *theroot wrote:*   Oh caspita, paxtest è masked (almeno su amd64). 
> 
> Non è stabile, è testing, c'è una bella differenza con masked

 

Intendevo masked perché ho riportato quello che mi dice emerge:

```

emerge paxtest -pv

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "paxtest" have been masked.

!!! One of the following masked packages is required to complete your request:

- app-admin/paxtest-0.9.9-r1 (masked by: ~amd64 keyword)

- app-admin/paxtest-0.9.7_pre5 (masked by: ~amd64 keyword)

- app-admin/paxtest-0.9.7_pre4 (masked by: ~amd64 keyword)

- app-admin/paxtest-0.9.6 (masked by: ~amd64 keyword)

- app-admin/paxtest-0.9.5-r1 (masked by: ~amd64 keyword)

For more information, see the MASKED PACKAGES section in the emerge

man page or refer to the Gentoo Handbook.

```

Per fare i test lo compilerò partendo dal sorgente.

----------

## theroot

 *Quote:*   

> ....e quindi ti serve anche chpax (e non rompere sono pochi Kb di eseguibile)

 

L'hanno fatto per me, per farmi risparmiare qualche Kb  :Wink: 

```
* Messages for package sys-apps/chpax-0.7:

 * chpax is now obsolete in favor of sys-apps/paxctl which uses PT_PAX_FLAGS

 * Please use paxctl from now on. Any bugs filed for chpax will be closed as

 * WONTFIX

```

 *Quote:*   

> Continua a studiartelo, male non ti fa di certo e (strano) pare che per te non sia un problema.

 

Pian piano porto avanti l'installazione, tra letture, configurazioni servizi e ciocchi con mdadm (mannaggia a loro che usano metadata di default diverso rispetto alle versioni precedenti... opps perdonate l'OT). Sotto la conf a cui sono arrivato per grsec+pax e queste le USE per make.conf:

USE="mmx sse sse2 pic"

```

CONFIG_PAX_PER_CPU_PGD=y

CONFIG_PAX=y

# PaX Control

# CONFIG_PAX_SOFTMODE is not set

CONFIG_PAX_EI_PAX=y

CONFIG_PAX_PT_PAX_FLAGS=y

CONFIG_PAX_NO_ACL_FLAGS=y

# CONFIG_PAX_HAVE_ACL_FLAGS is not set

# CONFIG_PAX_HOOK_ACL_FLAGS is not set

CONFIG_PAX_NOEXEC=y

CONFIG_PAX_PAGEEXEC=y

# CONFIG_PAX_EMUTRAMP is not set

CONFIG_PAX_MPROTECT=y

# CONFIG_PAX_ELFRELOCS is not set

CONFIG_PAX_KERNEXEC=y

CONFIG_PAX_ASLR=y

CONFIG_PAX_RANDUSTACK=y

CONFIG_PAX_RANDMMAP=y

CONFIG_PAX_MEMORY_SANITIZE=y

# CONFIG_PAX_MEMORY_UDEREF is not set

CONFIG_PAX_REFCOUNT=y

CONFIG_PAX_USERCOPY=y

CONFIG_GRKERNSEC=y

# CONFIG_GRKERNSEC_LOW is not set

# CONFIG_GRKERNSEC_MEDIUM is not set

# CONFIG_GRKERNSEC_HIGH is not set

CONFIG_GRKERNSEC_HARDENED_SERVER=y

# CONFIG_GRKERNSEC_HARDENED_SERVER_NO_RBAC is not set

# CONFIG_GRKERNSEC_HARDENED_WORKSTATION is not set

# CONFIG_GRKERNSEC_HARDENED_WORKSTATION_NO_RBAC is not set

# CONFIG_GRKERNSEC_CUSTOM is not set

CONFIG_GRKERNSEC_KMEM=y

CONFIG_GRKERNSEC_IO=y

CONFIG_GRKERNSEC_PROC_MEMMAP=y

CONFIG_GRKERNSEC_BRUTE=y

CONFIG_GRKERNSEC_MODHARDEN=y

CONFIG_GRKERNSEC_HIDESYM=y

# CONFIG_GRKERNSEC_NO_RBAC is not set

CONFIG_GRKERNSEC_ACL_HIDEKERN=y

CONFIG_GRKERNSEC_ACL_MAXTRIES=3

CONFIG_GRKERNSEC_ACL_TIMEOUT=30

CONFIG_GRKERNSEC_PROC=y

# CONFIG_GRKERNSEC_PROC_USER is not set

CONFIG_GRKERNSEC_PROC_USERGROUP=y

CONFIG_GRKERNSEC_PROC_GID=10

CONFIG_GRKERNSEC_PROC_ADD=y

CONFIG_GRKERNSEC_LINK=y

CONFIG_GRKERNSEC_FIFO=y

# CONFIG_GRKERNSEC_ROFS is not set

CONFIG_GRKERNSEC_CHROOT=y

CONFIG_GRKERNSEC_CHROOT_MOUNT=y

CONFIG_GRKERNSEC_CHROOT_DOUBLE=y

CONFIG_GRKERNSEC_CHROOT_PIVOT=y

CONFIG_GRKERNSEC_CHROOT_CHDIR=y

CONFIG_GRKERNSEC_CHROOT_CHMOD=y

CONFIG_GRKERNSEC_CHROOT_FCHDIR=y

CONFIG_GRKERNSEC_CHROOT_MKNOD=y

CONFIG_GRKERNSEC_CHROOT_SHMAT=y

CONFIG_GRKERNSEC_CHROOT_UNIX=y

CONFIG_GRKERNSEC_CHROOT_FINDTASK=y

CONFIG_GRKERNSEC_CHROOT_NICE=y

CONFIG_GRKERNSEC_CHROOT_SYSCTL=y

CONFIG_GRKERNSEC_CHROOT_CAPS=y

# CONFIG_GRKERNSEC_AUDIT_GROUP is not set

# CONFIG_GRKERNSEC_EXECLOG is not set

CONFIG_GRKERNSEC_RESLOG=y

# CONFIG_GRKERNSEC_CHROOT_EXECLOG is not set

# CONFIG_GRKERNSEC_AUDIT_PTRACE is not set

# CONFIG_GRKERNSEC_AUDIT_CHDIR is not set

CONFIG_GRKERNSEC_AUDIT_MOUNT=y

CONFIG_GRKERNSEC_SIGNAL=y

CONFIG_GRKERNSEC_FORKFAIL=y

CONFIG_GRKERNSEC_TIME=y

CONFIG_GRKERNSEC_PROC_IPADDR=y

# CONFIG_GRKERNSEC_RWXMAP_LOG is not set

# CONFIG_GRKERNSEC_AUDIT_TEXTREL is not set

CONFIG_GRKERNSEC_EXECVE=y

CONFIG_GRKERNSEC_DMESG=y

# CONFIG_GRKERNSEC_HARDEN_PTRACE is not set

# CONFIG_GRKERNSEC_TPE is not set

CONFIG_GRKERNSEC_RANDNET=y

CONFIG_GRKERNSEC_BLACKHOLE=y

# CONFIG_GRKERNSEC_SOCKET is not set

CONFIG_GRKERNSEC_SYSCTL=y

# CONFIG_GRKERNSEC_SYSCTL_DISTRO is not set

CONFIG_GRKERNSEC_SYSCTL_ON=y

CONFIG_GRKERNSEC_FLOODTIME=10

CONFIG_GRKERNSEC_FLOODBURST=4

```

 *Quote:*   

> esatto, avviato l'autolearn devi riavviare (non ti serve fermali) i servizi uno alla volta secondo l'ordine di boot, poi aggiungi ad rc ed avvii manualmente tutti i serivizi che ti servono. 
> 
> 

 

Come faccio a sapere l'ordine di boot?

----------

## djinnZ

dai log, se usi baselayout 1 devi installare showconsole ed abilitare i log su openrc abiliti e basta. Ma non è necessario che segui l'ordine esatto, te lo consigliavo solo come approccio sistematico.

In alternativa vedi nei log di pax e grsec quali servizi hanno causato eccezioni e li riavvi con l'autolearn installato.

Il risultato non cambia.

mdadm sta mandando in bestia anche me...   :Confused: 

----------

## theroot

Continua un po' a singhiozzo la mia avventura con grsec e pax, inizio finalmente a vedere la fine dopo aver installato e configurato tutti i servizi che mi servono e dopo aver trovato l'ordine di boot corretto.

Ho iniziato a 'testare' pax, vorrei essere sicuro che i programmi siano compilati correttamente, in particolare che l'utilizzo della memoria sia random e non sequenziale e che la parte di memoria di tipo 'dati' non sia eseguibile (PAX+PIE+,forse,SSP... li sto 'usando tutti', non l'ho capito). Spero si sia capito cosa voglio dire, anche se comprendo di non essere ancora ferrato al meglio.

Dicevo, ho provato a ricavare info sul servizio apache2 in esecuzione sulla macchina

```
 pspax -p 5622

USER     PID    PAX    MAPS ETYPE      NAME             CAPS       

root     5622   PeMRs  w^x  ET_DYN     apache2           =  
```

Con riferimento a http://en.wikibooks.org/wiki/Grsecurity/Additional_Utilities#Controlling_PaX_Flags_.28paxctl.29

è bene che 'e' e 's' siano disabilitate? Questo vale anche per tutti gli altri programmi in esecuzione.

Ho verificato inoltre con che flag è stato compilato:

```
paxctl -v /usr/sbin/apache2

PaX control v0.5

Copyright 2004,2005,2006,2007 PaX Team <pageexec@freemail.hu>

- PaX flags: -------x-e-- [/usr/sbin/apache2]

   RANDEXEC is disabled

   EMUTRAMP is disabled

```

Mi aiutate a capire? Non sono sicuro di aver capito bene.

```
S = PAX_SEGMEXEC è la stessa cosa di RANDEXEC ???

E = PAX_EMUTRAMP == EMUTRAP ok
```

----------

## ago

 *theroot wrote:*   

> Ho iniziato a 'testare' pax, vorrei essere sicuro che i programmi siano compilati correttamente, in particolare che l'utilizzo della memoria sia random e non sequenziale e che la parte di memoria di tipo 'dati' non sia eseguibile (PAX+PIE+,forse,SSP... li sto 'usando tutti', non l'ho capito). Spero si sia capito cosa voglio dire, anche se comprendo di non essere ancora ferrato al meglio.

 

é semplice e se non erro è stato già detto( non ho voglia di rileggere ). Pax + un "programma" a se mentre pie/ssp è una caratteristica che ottieni compilando con gcc hardened.

Per le flag di pax -x/-e è corretto..preoccupati se vedi -m

----------

## mack1

@theroot qui trovi uno script che ti permette di testare il sistema:

http://www.trapkit.de/tools/checksec.sh

ciao

----------

## theroot

Ciao a tutti,

ho messo in piedi un server gentoo hardened, ricalcando quanto ho fatto in primavera. 

Mi sono accorto che la macchina è più lenta di prima, ovvero quando lo stesso server non era hardened.

Faccio un esempio: il web gallery (gallery.menalto.com) quando importo foto e quindi utilizza 'convert', del pacchetto ImageMagik, è eterno e per eterno intendo un tempo fuori da ogni logica tanto che lascio li e chissà quando finisce

La configurazione del server è:

- AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

- 2 hd NUOVI in raid software (western digital raid edition) da 500 GB

- 2 banchi di memoria NUOVI per un totale di 4 GB (prima erano  2GB)

Cercando nei log di sistema (audit, auth, kernel, syslog, messages, debug, daemon, grsec) e quelli di apache non trovo anomalie

Sapete aiutarmi?

----------

## djinnZ

Il kernel hardened comporta un impatto negativo sulle prestazioni.

Quindi schiatta e non lamentarti.  :Twisted Evil:  Non solo hai voluto gentoo ma anche harded, se questo non è "causa del suo mal"...  :Twisted Evil: 

Dai uno sguardo a 

```
GRKERNSEC_FLOODTIME

GRKERNSEC_FLOODBURST

GRKERNSEC_*LOG

PAX_MEMORY_SANITIZE

CONFIG_PAX_MEMORY_STACKLEAK

CONFIG_PAX_MEMORY_UDEREF

CONFIG_PAX_USERCOPY
```

ricorda che gli eseguibili sono più sensibili a differenze nell'ottimizzazione (ed in generale è da co****ni avere parte -march=686 e parte -march=k8 per non dire dell'uso dei vari -O3 & C) e non dimenticare (come da post in cima a questo forum) che qualcosa con gcc è cambiata, quindi se usi -march=native o se ti sei basato su quello per le impostazioni forse devi correggere qualcosa o ricompilare;

una fastidosa pulce nel mio orecchio mi suggerisce che forse è arivata l'ora ora di metter mano a gradm però.  :Twisted Evil: 

Prova se CFLAGS="-fomt-frame-poinbter -g 0" aiuta e controlla di non aver disabilitato le ldflags.

Ripulisci il kernel dalle varie opzioni di debugging, tanto su hardened il debugging è una pia illusione.

Attenzione che le impostazioni per scheduler e preemption allocator e compagna cantando vanno riviste.

Sono cambiate alcune cose negli scheduler e, sempre su hardened, è necessario fare attenzione a non lasciare le impostazioni NUMA di default, ho già scritto qualche tempo fa (~ mese scorso) delle indicazioni di massima, cercale.

Per problemi con singoli applicativi dai uno sguardo a app-admin/verynice.

per il necessario tuning di apache ti arrangi...   :Embarassed: 

nb: 2.6 con i 3.x non ho ancora iniziato a giocare ma dovrebbe essere la stessa cosa.

----------

## theroot

Questo è parte del mio .config 

```
CONFIG_GRKERNSEC_FLOODTIME=10

CONFIG_GRKERNSEC_FLOODBURST=4

# CONFIG_GRKERNSEC_EXECLOG is not set

CONFIG_GRKERNSEC_RESLOG=y

# CONFIG_GRKERNSEC_CHROOT_EXECLOG is not set

CONFIG_GRKERNSEC_RWXMAP_LOG=y

CONFIG_PAX_MEMORY_SANITIZE=y

CONFIG_PAX_MEMORY_STACKLEAK non è presente nel mio .config

CONFIG_PAX_MEMORY_UDEREF=y

CONFIG_PAX_USERCOPY=y
```

concordo con te per il 'non' O3, per l'arch io ho messo athlon64

```
uname -a

Linux page 2.6.37-hardened-r7 #1 SMP Wed Apr 20 20:22:56 CEST 2011 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux
```

il mio make.conf:

```
CFLAGS="-march=athlon64 -O2 -pipe"

CXXFLAGS="${CFLAGS}"

CHOST="x86_64-pc-linux-gnu"

MAKEOPTS="-j3"

USE="mmx sse sse2 pic"
```

Per ora non ho attivato gradm, in realtà vorrei fare l'autolearning ma vedendo questi problemini ho aspettato un attimo (ho anche un probl con gkrellm ma ne discutiamo poi, per ora è l'ultimo dei miei pensieri).

 *djinnZ wrote:*   

> Sono cambiate alcune cose negli scheduler e, sempre su hardened, è necessario fare attenzione a non lasciare le impostazioni NUMA di default, ho già scritto qualche tempo fa (~ mese scorso) delle indicazioni di massima, cercale.

 

NUMA: vado a cercare, gulp, posso dirlo: non ho idea di cosa sia e quindi mi sa che avrò lasciato le impostazioni di default.

```
# CONFIG_NUMA is not set
```

Last edited by theroot on Wed Nov 16, 2011 5:34 pm; edited 3 times in total

----------

## djinnZ

Edita il tuo messaggio e rendilo leggibile. Se vuoi risposta.

 *theroot wrote:*   

> [censura]gradm[censura]NUMA[censura]

   :Shocked:   :Evil or Very Mad:  NUMA in senso lato... Cerca su come metter mano alle opzioni di ottimizzazione per i multicore. Anche se ne hai solo due.

grdadm un minimo lo devi usare.

Nel frattempo io vado ad impiccarmi.  :Laughing: 

----------

## ago

 *theroot wrote:*   

> 
> 
> ```
> 
> uname -a
> ...

 

Il .37 si porta dietro diverse vulnerabilità, dai un'aggiornatina  :Wink: 

 *theroot wrote:*   

> il mio make.conf:
> 
> ```
> 
> CFLAGS="-march=athlon64 -O2 -pipe"
> ...

 

controlla qui se è corretto.

In generale è bene che tu sappia che tutto il codice se compilato in modo da essere pic/pie rallenta a livello di prestazioni. Può darsi anche che queste flag diano fastidio al binario che da te ha questo problema, quindi prova a compilarlo con gcc vanilla e disabilita protezioni sulla memoria se necessario.

----------

## theroot

Avete ragione: mi ritiro in camera a studiare... gradm, NUMA, CFLAGS....

Nel mentre riavvio con 2.6.38-hardened-r6 che era già pronto e lasciato li  :Smile: 

Vi faccio sapere come ne sono uscito; avrò ancora bisogno di voi !!!

----------

## ago

 *theroot wrote:*   

> Avete ragione: mi ritiro in camera a studiare... gradm, NUMA, CFLAGS....
> 
> Nel mentre riavvio con 2.6.38-hardened-r6 che era già pronto e lasciato li 

 

2.6.39 o 3.0 è meglio  :Wink: 

----------

## djinnZ

 *ago wrote:*   

> Può darsi anche che queste flag diano fastidio al binario che da te ha questo problema, quindi prova a compilarlo con gcc vanilla e disabilita protezioni sulla memoria se necessario.

 personalmente sono più per la necessità di mettere a posto il kernel.

Logging eccessivo per cominciare ma anche le opzioni per il memory clean (sanitize, underef & C).

Quello che ipotizzo è che il kernel perde tempo a ripulire la memoria per un programma che viene avviato n volte tanti sono i file da processare.

 :Shocked:  sei riuscito a leggere quella sfilza di roba? io non ci ho provato neppure  :Laughing: 

@theroot: In generale se hai già un kernel più lento del normale e binari meno immediati nell'esecuzione ottimizzare al messimo detto kernel è necessario.

Il fame-pointer è per i sistemi multilib se sei in "puro 64 bit" non serve (è implicito).

A dire il vero il .37 io non sono mai riuscito a farlo andare  :Embarassed:  usa il .39 stabile (gli header sono del .39) e lascia perdere le altre versioni.

Se proprio vuoi fare esperimenti dedicati all'ultimo 3.x (instabile).

```
echo "sys-kernel/harded-sources ~amd64 >> /etc/portage/package.keywords

emerge -n =sys-kernel/hardened-soruces-2.6.39-r8

emerge -NDu hardened-sources
```

```
emerge --depclean
```

```
emerge -n =sys-kernel/hardened-soruces--3.0.4-r4

emerge -C =sys-kernel/hardened-soruces-2.6.39-r8
```

e via così  :Wink: 

per piacere edita il tuo post ... già riempio il forum con un cumulo di str****te per fare lo spiritos se poi ti metti a citarmi per esteso non la finiamo più...

----------

## mack1

Volevo aggiungere (andando un po' OT) che sul 3.0.4-hardened-r4 è stata aggiunta l'opzione:

```

CONFIG_GRKERNSEC_KERN_LOCKOUT:                                                                                                        

  │                                                                                                                                        

  │ If you say Y here, when a PaX alert is triggered due to suspicious                                                                     

  │ activity in the kernel (from KERNEXEC/UDEREF/USERCOPY)                                                                                 

  │ or an OOPs occurs due to bad memory accesses, instead of just                                                                          

  │ terminating the offending process (and potentially allowing                                                                            

  │ a subsequent exploit from the same user), we will take one of two                                                                      

  │ actions:                                                                                                                               

  │  If the user was root, we will panic the system                                                                                        

  │  If the user was non-root, we will log the attempt, terminate                                                                          

  │  all processes owned by the user, then prevent them from creating                                                                      

  │  any new processes until the system is restarted                                                                                       

  │ This deters repeated kernel exploitation/bruteforcing attempts                                                                         

  │ and is useful for later forensics. 

```

L'ho disabilitata dopo poco tempo proprio per l'eccessivo overhead.

----------

## ago

c'è anche nel 2.6

----------

## mack1

@ago è stata aggiunta (se non ho capito male  :Wink:  ) dopo questo (aprile 2011), quindi da poco, l'ho attivata solo nel 3.0.4-r4:

http://forums.grsecurity.net/viewtopic.php?f=7&t=2596

Io ho solo notato che il sistema con il 3.0.4-r4 e la suddetta opzione attiva tendeva ad avere performance peggiori... sarebbe interessante sapere da altri utilizzatori del profilo hardened se la cosa si manifesta anche sulle loro gentoo.

Ciao

----------

## ago

non ho provato con e senza su stesso kernel, ma visto che i kernel precedenti non l'avevano e i nuovi sì, non noto ugualmente differenza. Puoi anche includere il caso in cui il kernel nuovo sia più "veloce" per altre modifiche ma "rallentato" da quell'opzione e le prestazioni mi tornano sempre "pareggianti"

----------

## mack1

@ago tutto vero... poi tieni presente che è un vecchio p4 con risorse molto limitate, quindi può anche essere che l'impatto sia poco rilevabile su macchine più potenti.... ecco perchè chiedevo se altri avevano notato la cosa!

Ciao

----------

## ago

Io su un celeron 1.7Ghz monocore non ho notato nulla ad occhio.

----------

## mack1

E allora deve trattarsi di un problema specifico del mio hardware...  :Rolling Eyes: 

----------

## djinnZ

Del tuo software.

A me vhba schianta la macchina con le eccezioni di pax che provoca, a prescindere.

Ed in generale il kernel hardened non è mai andato d'accordo con i driver nvidia ed ati proprietari.

In generale il .39 mi pareva andare molto meglio rispetto al precedente (.34 o .36 non ricordo) tanto è vero che ho iniziato ad usarlo anche con le versioni instabili.

Considera che lo ho anche su un athlon vecchiotto e malandato.

Mi pare piuttosto che il 3.x sia diventato più piantagrane per alcune eccezion come KERN_LOCKOUT. Ma è quello che hanno sempre fatto per pax e grsec di versione in versione diventano più sensibili.

In  generale mi pare che non vada molto d'accordo con tutti i moduli e le strutture che interagiscono con il kernel fuse incluso. Quindi la ho esclusa direttamente.

il ¼ ... di centesimo ... di lira ...

----------

## mack1

@djinnZ thanks!

----------

