Newsgroup: it.comp.sicurezza.varie
Titolo: Securing RH linux

Ciao all! =)
Sto divorando 'Securing-Optimizing-RH-Linux-1_2.pdf' pubblicato da poco
su packetstorm.
L'autore accenna a delle patches al kernel di Openwall Project
(
http://www.openwall.com/linux/).
.. tese ad aumentarne la sicurezza.
Le conoscete, cosa ne pensate?
-- 
GHERdO, AMiGA Supporter Since 1988
	happy linux user
"Guarda Sophia, guarda la vita che vola via..."	

Le conoscete, cosa ne pensate?
alcune sono effettivamente utili su server di produzione, che non
abbiano un omino alla consolle 24/h [quindi la stragrande maggioranza]
vediamole in breve:
 Non-executable user stack area
--------------------------------
questa serve per bloccare i piu' banali e comuni exploit basati su
overflow di variabili automatiche sullo stack. senza voler spiegare cosa
siano (articolo di Aleph1 su Phrack48), basti dire che la maggior parte
degli exploit locali e remoti che si trovano in giro NON funzioneranno
piu' applicata questa patch. anche se ci sono modi per bypassarla :) e
altri tipi di overflow possibili.
 Restricted links in /tmp
--------------------------
/tmp e' scrivibile da tutti. cosa succede quindi con tutti quegli exploit
che permettono di abusare dei link su sistemi unix per modificare i permessi,
cancellare file, e copiarne, seguendo i link che il programma bacato ci
permette di creare o sovrascrivere [nel caso frequente che file temporanei
siano scritti in /tmp] ? con questa patch ci pariamo un po' il sederino
 Restricted FIFOs in /tmp
--------------------------
non spiego qui cosa siano i FIFO. basti sapere che molti demoni o programmi
ne creano in /tmp per poter permettere lo scambio dei dati tra processi
differenti. ora, se /tmp e' scrivibile da tutti ed il FIFO non e' protetto
adeguatamente dai permessi, cosa succede se scrivo dentro al FIFO inviando
dati ad un processo, per FINTO conto di un altro ? come si suol dire,
it's a nonono :)
 Restricted /proc
------------------
all'inizio di UNIX, procfs era un concetto. non una implmentazione. con
Linux procfs ha raggiunto gli onori della cronaca. procfs permette FACILMENTE
e velocemente di far funzionare, tra gli altri, programmi come ps, top, w
e netstat. ora, se /proc e' ristretto solo a root, gli utenti normali NON
potranno sapere cosa succeda sul sistema. Chi c'e' si, con utmp, ma non cosa
faccia, ad esempio. Ne quali siano i processi o i socket attivi. Non puo'
sapere quali moduli siano installati, quali siano le statistiche del sistema
e delle interfacce di rete, o quali siano i file aperti da socket e processi.
oddio, li basta ricompilare lsof perche' usi /dev/kmem e non procfs, ma
l'accesso a kmem non dovrebbe cmq far parte dei diritti degli utenti normali.
 Special handling of fd 0, 1, and 2
------------------------------------
questi sono i famosi stdin, stdout e stderr del C. e questo possibile
problema di sicurezza e' affascinante :). se un programma SUIDATO chiama
una open() con uno o tutti quei 3 descrittori chiusi, saranno di nuovo
disponibili agli occhi delle librerie linkate, ma per il file aperto dal
programma. vecchi problemi sono stati i descrittori lasciati 'aperti' nei
confronti di kmem ad esempio. ora invece non si potra' usare chiamate di
sistema PRIMA che 0, 1 e 2 siano stati aperti cmq; se non usati saranno
linkati a /dev/null.
 Enforce RLIMIT_NPROC on execve(2)
-----------------------------------
ci sono limiti al numero di processi attivabili da ogni UID. Ma cosa
succede se un programma cambia UID durante il suo svolgimento e poi forka
altri processi ? superera' il limite :). quello che fa questa patch e'
checkare il numero per ogni chiamata di sistema execve(). Questo patchera'
contro processi che chiamino fork() per creare nuovi processi figli prima
di aver cambiato UID.
 Destroy shared memory segments not in use
-------------------------------------------
un altro limite e' quello della memoria consumata. ma aree di memoria
condivisa, in quanto tale, NON sono collegate ad alcun processo particolare
e possono quindi far superare il limite suddetto. quindi, i segmenti non
in uso, verranno distrutti cmq, anche senza richiesta esplicita di chi
li ha creati (e che ogni tanto se li dimentica in giro). Questa patch e'
forse la piu' problematica per le applicazioni. Infatti chiude anche
segmenti creati ma non ancora usati all'uscita della funzione che nel suo
contesto ha dato loro vita.
 Privileged IP aliases (Linux 2.0 only)
----------------------------------------
questo e' interessante. crea un insieme di indirizzi alias [quali quelli
che possiamo dare a eth0:x per intenderci] privilegiati, passando il numero
massimo da 1024 a 2048, cosicche' i primi saranno a disposizione del solo
root per il binding di socket.
So che puo' non esser chiarissimo a tutti, ma questo e' il modo terra terra
e NON squisitamente tecnico, per definire patch che cmq, lavorano nel KERNEL
e sono quindi, quanto meno, un po' in la' :)
La maggior parte di queste patch apparve per 2.0.x da idee di vari autori,
presentate insieme da Daemon9 nell'articolo su Phrack "Hardening the Linux
Kernel" ... altre patch a mio avviso dovrebbero disporre di idee proprie dei
securelevel di BSD, ma ormai siamo al 2.4 e si puo' sperare che le Linux
Capabilities siano ormai in porto.
ciao
invy

vediamole in breve:
Mito, articolo salvato! :) grazie della risposta esauriente =)
