| View previous topic :: View next topic |
| Author |
Message |
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
 Posted: Fri Apr 08, 2011 11:41 am Post subject: |
 |
|
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.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est 
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
 |
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Fri Apr 08, 2011 6:33 pm Post subject: |
|
|
| 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  |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Mon Apr 11, 2011 11:06 am Post subject: |
|
|
appunto... 
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
theroot
n00b
Joined: 24 Dec 2010
Posts: 12
|
| Posted: Mon Apr 11, 2011 5:16 pm Post subject: |
|
|
| 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:
| Code: |
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. |
|
| Back to top |
|
|
theroot
n00b
Joined: 24 Dec 2010
Posts: 12
|
| Posted: Mon Apr 11, 2011 5:31 pm Post subject: |
|
|
| 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
| Code: | * 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"
| Code: |
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? |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Wed Apr 13, 2011 7:55 am Post subject: |
|
|
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...
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
theroot
n00b
Joined: 24 Dec 2010
Posts: 12
|
| Posted: Wed Apr 20, 2011 6:37 pm Post subject: |
|
|
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
| Code: | 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:
| Code: | 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.
| Code: | S = PAX_SEGMEXEC è la stessa cosa di RANDEXEC ???
E = PAX_EMUTRAMP == EMUTRAP ok |
|
|
| Back to top |
|
|
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Wed Apr 20, 2011 11:59 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
mack1
Guru
Joined: 18 Mar 2006
Posts: 315
|
|
| Back to top |
|
|
theroot
n00b
Joined: 24 Dec 2010
Posts: 12
|
| Posted: Wed Nov 16, 2011 1:24 pm Post subject: |
|
|
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? |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Wed Nov 16, 2011 2:03 pm Post subject: |
|
|
Il kernel hardened comporta un impatto negativo sulle prestazioni.
Quindi schiatta e non lamentarti.  Non solo hai voluto gentoo ma anche harded, se questo non è "causa del suo mal"...
Dai uno sguardo a | .config: | 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ò.
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... 
nb: 2.6 con i 3.x non ho ancora iniziato a giocare ma dovrebbe essere la stessa cosa.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist
Last edited by djinnZ on Wed Nov 16, 2011 2:29 pm; edited 1 time in total |
|
| Back to top |
|
|
theroot
n00b
Joined: 24 Dec 2010
Posts: 12
|
| Posted: Wed Nov 16, 2011 2:25 pm Post subject: |
|
|
Questo è parte del mio .config
| Code: | 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
| Code: | 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:
| Code: | 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.
| Code: | | # CONFIG_NUMA is not set |
Last edited by theroot on Wed Nov 16, 2011 5:34 pm; edited 3 times in total |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Wed Nov 16, 2011 2:35 pm Post subject: |
|
|
Edita il tuo messaggio e rendilo leggibile. Se vuoi risposta.
| theroot wrote: | | [censura]gradm[censura]NUMA[censura] |
 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. 
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Wed Nov 16, 2011 2:46 pm Post subject: |
|
|
| theroot wrote: | | Code: |
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 .37 si porta dietro diverse vulnerabilità, dai un'aggiornatina
| theroot wrote: | il mio make.conf:
| Code: |
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. |
|
| Back to top |
|
|
theroot
n00b
Joined: 24 Dec 2010
Posts: 12
|
| Posted: Wed Nov 16, 2011 3:15 pm Post subject: |
|
|
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 
Vi faccio sapere come ne sono uscito; avrò ancora bisogno di voi !!! |
|
| Back to top |
|
|
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Wed Nov 16, 2011 3:31 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Wed Nov 16, 2011 5:03 pm Post subject: |
|
|
| 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.
sei riuscito a leggere quella sfilza di roba? io non ci ho provato neppure
@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 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).
| per fare le cose per bene: | echo "sys-kernel/harded-sources ~amd64 >> /etc/portage/package.keywords
emerge -n =sys-kernel/hardened-soruces-2.6.39-r8
emerge -NDu hardened-sources |
| appena il .39 funziona: | | emerge --depclean |
| quando sarai passato al 3.x, esempio: 3.0.4-r4: | emerge -n =sys-kernel/hardened-soruces--3.0.4-r4
emerge -C =sys-kernel/hardened-soruces-2.6.39-r8 |
e via così
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ù...
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
mack1
Guru
Joined: 18 Mar 2006
Posts: 315
|
| Posted: Thu Nov 17, 2011 3:20 pm Post subject: |
|
|
Volevo aggiungere (andando un po' OT) che sul 3.0.4-hardened-r4 è stata aggiunta l'opzione:
| Code: |
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. |
|
| Back to top |
|
|
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Thu Nov 17, 2011 3:54 pm Post subject: |
|
|
| c'è anche nel 2.6 |
|
| Back to top |
|
|
mack1
Guru
Joined: 18 Mar 2006
Posts: 315
|
| Posted: Thu Nov 17, 2011 4:23 pm Post subject: |
|
|
@ago è stata aggiunta (se non ho capito male ) 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 |
|
| Back to top |
|
|
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Thu Nov 17, 2011 4:36 pm Post subject: |
|
|
| 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" |
|
| Back to top |
|
|
mack1
Guru
Joined: 18 Mar 2006
Posts: 315
|
| Posted: Thu Nov 17, 2011 4:45 pm Post subject: |
|
|
@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 |
|
| Back to top |
|
|
ago
Developer
Joined: 01 Mar 2008
Posts: 1527
Location: Milan, Italy
|
| Posted: Thu Nov 17, 2011 5:03 pm Post subject: |
|
|
| Io su un celeron 1.7Ghz monocore non ho notato nulla ad occhio. |
|
| Back to top |
|
|
mack1
Guru
Joined: 18 Mar 2006
Posts: 315
|
| Posted: Thu Nov 17, 2011 5:26 pm Post subject: |
|
|
E allora deve trattarsi di un problema specifico del mio hardware...  |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Fri Nov 18, 2011 2:24 pm Post subject: |
|
|
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 ...
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
|
Forum italiano (Italian)
