Il Kernel Linux

Pratiche di ricompilazione del kernel Linux. Moduli e patch. /proc filesystem

Hardening con Grsecurity e Kernel 2.4.29

L’obiettivo dell’articolo è quello di instradare il lettore nell’apportare una serie di modifiche da applicare ad un PC montante kernel linux 2.4.29 per innalzarne il livello di sicurezza tramite la patch grsecurity.
Ciò che andremo a fare è tecnicamente definito come “Kernel Hardening” che, volendo fornire una volgare traduzione italiana, stà a significare: “Rafforzamento del Kernel”.
Grsecurity permette, infatti, di irrobustire il kernel linux mediante complessi schemi logistici che vanno dal Role-Based Access Control (RBAC) al PID randomization passando per l’incrementazione delle restrizioni dei processi chrootati.
La corretta applicazione di questa patch consente di metterci al riparo da un eventuale attacco al sistema da parte di un malintenzionato.
Parlando di hardening si dà per scontato che il lettore sia a conoscenza di come compilare un kernel e che conosca sufficientemente la struttura di un sistema unix-based.

Grsecurity segue una strategia denominata “Detection, Prevention and Conteinment” che permette di “Determinare, prevenire e contenere” i danni che un malintenzionato può recare ad un sistema operativo GNU/Linux.

Detection: Attraverso i logs delle fork() non andate a buon fine, di tentativi d’accesso a risorse protette e l’esecuzione di qualunque software, grsecurity permette, attraverso sistemi di analisi dei logs, appunto, di “determinare” con estrema precisione ciò che avviene nel sistema.

Prevention: La stragrande maggioranza di falle di sistema è causata essenzialmente da errori di programmazione che si traducono generalmente col tempo in buffer overflow (stack/heap overflow). Grsecurity permette, attraverso PaX (pax.grsecurity.org), di evitare in qualche modo che questo possa avvenire attraverso una serie di “tattiche”:

1. Executable space protections:

che permette di prevenire l’iniezione di codice malevolo attraverso il bit NX dei processori (NX == Non-eXecutable). In processori che non hanno il bit NX Pax lo emula.

2. Address space layout randomization:

che permette di eliminare attacchi che cercano in qualche modo di eseguire codice già caricato in memoria e non contemplato dal programmatore attraverso la randomizzazione delle allocazioni di memoria dell’user space.

Contaimnent: A differenza della normale gestione dei processi del kernel vanilla (e comunque dei sistemi Unix-like) basata sulle operazioni di lettura, scrittura ed esecuzione in base al proprietario od al gruppo di appartenenza (sistema DAC, Discretionary Access Control), grsecurity implementa una versione ampliata e sofisticata di Access Control chiamata RBAC (Role-Based Access Control).
Attraverso, quindi, queste “strategie”, grsecurity, consente di rendere più sicuro il sistema.
Procediamo ora al prossimo step riguardante, finalmente, l’installazione della patch grsec su un kernel vanilla 2.4.29.

Innanzitutto colleghiamoci al sito http://www.kernel.org/pub/linux/kernel/v2.4/ e scarichiamo il tarball contentente i sorgenti del kernel 2.4.29.
Fatto ciò puntiamo il nostro browser su http://www.grsecurity.net, una breve lettura della home-page ci permetterà di individuare la sezione downloads: scarichiamo la patch avendo cura di selezionare quella per il ramo 2.4.x.
A questo punto abbiamo tutto l’occorrente per metterci al lavoro: nell’eventualità stessimo lavorando con il server X attivo, stoppiamolo ed entriamo in shell, questo ci permetterà di ultimare il tutto molto più velocemente in quanto non ci saranno sprechi di RAM.

Entrati in shell da superutente (root) copiamo l’archivio tar dei sorgenti del kernel in /usr/src:
# cp /path_dove_abbiamo_scaricato_i_sources/linux-2.4.29.tar.gz /usr/src

Ora dobbiamo estrarre i sorgenti dal tarball:
# cd /usr/src
# tar –zxvf linux-2.4.29.tar.gz

Estratti i sorgenti, copieremo la patch grsecurity in /usr/src:
# cp /path_dove_abbiamo_scaricato_grsec/grsecurity-XXX.patch /usr/src

Ed infine applicheremo la stessa:
# patch –p0
Address Space Protection —>
Role Based Access Control Options —>
Filesystem Protections —>
Kernel Auditing —>
Executable Protections —>
Network Protections —>
Sysctl support —>
Logging options —>
Non essendo intenzione dell’autore blindare un sistema paranoicamente ci limiteremo ad apportare modifiche sufficienti a garantirci un discreto livello di sicurezza in ambito desktop.
Quello che faremo è: randomizzare i PID, restringere la struttura per la coda dati FIFO, restringere dmesg, impedire il mount in ambiente chrootato, loggare processi al di fuori del chroot nonché indivuare e bloccare exploits che possono fornire privilegi elevati ad un utente.
In PaX Control non selezioniamo nulla ed in MAC system integration impostiamo none.
Per quanto riguarda Address Space Protection selezioniamo solo Deter exploit bruteforcing e, se vogliamo, Disable privileged I/O (in questo modo solo il superutente potrà spegnere e riavviare il PC).
In Role Based Access Control Options selezioniamo Hide kernel processes, per il resto lasciamo invariato o, qualora volessimo, cambiamo il numero di tentativi massimo di password errata.
Arrivati a Filesystem Protections selezioniamo FIFO restrictions.
In Kernel Auditing selezioniamo Exec logging, Signal logging, Fork failure logging.
Per Executable Protections la scelta sarà Dmesg(8) restriction e Randomized PIDs.
Lasciamo completamente invariati Network Protections, Sysctl support e Logging options: la configurazione di Grsecurity è finita, diamo un faticato exit, completiamo la configurazione generale del kernel, un altro exit, alla domanda “Do you wish to save your new kernel configuration?” rispondiamo “Yes” e… compiliamo !

Per prima cosa prepariamo le dipendenze:
# make dep

Rimuoviamo i file temporanei:
# make clean

Prepariamoci una tazza di caffè e creiamo l’immagine del kernel (ci vorrà del tempo):
# make –j5 bzImage

Creata l’immagine del kernel penseremo ai moduli (anche qui ci vorrà del tempo):
# make –j5 modules

Compilati i moduli del kernel dovremo installarli:
# make modules_install

A questo punto la compilazione è finalmente finita, ecco le ultime cose da fare: spostiamo la System map creata in /boot:
# mv System.map /boot/System.map-2.4.29grsec

stesso discorso per il .config:
# mv .config /boot/config-2.4.29grsec

e ora il kernel:
# mv /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.4.29grsec

Siamo arrivati al final step: la configurazione di Lilo:
# pico /etc/lilo.conf

Al file lilo.conf aggiungeremo in basso a tutto:
image = /boot/vmlinuz-2.4.29grsec
root = /dev/Partizione_ROOT
label = Linux_grsec
read-only

Accertiamoci che tutto sia apposto con lilo –v e diamo il consueto lilo:
# lilo –v
# lilo
Linux added*
Linux_grsec added

Diamo un bel reboot e godiamoci il nostro nuovo kernel “blindato”.

Cos’e’ linux-gate.so.1 ?

Storia della sysenter e del kernel 2.6

Quando usi “ldd” per verificare le dipendenze di un’eseguibile, in una distro recente noti una dipendenza da una fantomatica libreria chiamata linux-gate.so.xxx.

Esempio:

$ ldd /bin/sh
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/libdl.so.2 (0xb7fb2000)
libc.so.6 => /lib/libc.so.6 (0xb7e7c000)
/lib/ld-linux.so.2 (0xb7fba000)

Provate a cercare quel file. Su tutto il filesystem e non lo troverete!

Ma come e’ possibile avere una dipendenza da una libreria che non esiste?

Quella e’ un DSO, un oggetto sherato dal kernel ad un indirizzo fisso.

Non ci credete allora provate..
con

$ cat /proc/self/maps
— snip —
7e88000-b7e89000 rwxp b7e88000 00:00 0
b7e89000-b7fb8000 r-xp 00000000 08:03 8856588 /lib/libc-2.3.5.so
b7fb8000-b7fb9000 r-xp 0012e000 08:03 8856588 /lib/libc-2.3.5.so
b7fb9000-b7fbc000 rwxp 0012f000 08:03 8856588 /lib/libc-2.3.5.so
b7fbc000-b7fbe000 rwxp b7fbc000 00:00 0
b7fc2000-b7fd9000 r-xp 00000000 08:03 8856915 /lib/ld-2.3.5.so
b7fd9000-b7fdb000 rwxp 00016000 08:03 8856915 /lib/ld-2.3.5.so
bfac3000-bfad9000 rw-p bfac3000 00:00 0 [stack]
ffffe000-fffff000 —p 00000000 00:00 0 [vdso]
— snip —

L’ultima riga identifica un virtualDSO, e’ il linux-gate!!

Verifichiamo che nello spazio di indirizzamento a 32 bit per ogni processo esso e’ dislocato come indicato sopra tra ffffe000-fffff000, cioe’ se considerate che ogni pagina e grande 4KB, 4096 bytes, che corrisponde alla penultima pagina.

Visto che in ogni processo esso e’ dislocato allo stesso indirizzo virtuale, e’ facile con ‘dd’ sbatterlo su un file e capire cosa e’!

$ dd if=/proc/self/mem of=linux-gate.mydso bs=4096 skip=1048574 count=1
1+0 records in
1+0 records out

(PS. ragionate sul preche’ di 1048574 )

ora che l’ho estratto potrei fare un ‘file’ per vedere cosa e’:

$ file -b linux-gate.mydso
ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped

oppure un objdump:

$ objdump -T linux-gate.mydso

da quest’ultimo comando noto che vi sono due simboli che rappresentano entry point per system-call (chiamate di sistema, quindi al kernel, si passa da userspace a kernel space): “rt_sigreturn/sigreturn”

Ma veniamo al dunque, a cosa serve tutto questo marchingegno?

Inizialmente le systemcall avvenivano per esempio in DOS sollevando attraverso l’interrupt int 0x21 o sotto linux e svariati Unix attraverso l’interrupt int 0x80;

Ci si accorse che sollevare un’interrupt per ogni syscall era comunque oneroso. Intel si accorse del problema e ha introdotto due nuove funzioni del microprocessore chiamate “sysenter e sysexit”. Comode e veloci per fare una system-call e uscirne senza sollevare interrupt.

Questa funzione implementata fu implementata sui pentium III per la prima volta e apparve nei kernel linux verso la fine del 2002 durante lo sviluppo del kernel 2.5.

Non ci credere, ora proviamo a fare:

$ objdump -d –start-address=0xffffe400 –stop-address=0xffffe414 linux-gate.mydso

linux-gate.mydso: file format elf32-i386

Disassembly of section .text:

ffffe400 :
ffffe400: 51 push %ecx
ffffe401: 52 push %edx
ffffe402: 55 push %ebp
ffffe403: 89 e5 mov %esp,%ebp
ffffe405: 0f 34 sysenter
ffffe407: 90 nop
ffffe408: 90 nop
ffffe409: 90 nop
ffffe40a: 90 nop
ffffe40b: 90 nop
ffffe40c: 90 nop
ffffe40d: 90 nop
ffffe40e: eb f3 jmp ffffe403
ffffe410: 5d pop %ebp
ffffe411: 5a pop %edx
ffffe412: 59 pop %ecx
ffffe413: c3 ret

eccola la’
ffffe405: 0f 34 sysenter

La modalita’ preferita di invocare una system call viene determinata dal kernel a tempo di boot. Evidentemente la mia macchina usa la sysenter. Su una macchina piu’ vecchia che non la implementa a livello di microprocessore potresti trovare la piu’ lenta “int 0x80” al suo posto.

Nei kernel 2.4 non era utilizzata tale funzione per fare le syscall. Percio’ tale dipendenza di un eseguibile da una fantomatica libreria linux-gate e’ visibile solo se sta girando un kernel 2.6.

Microsoft inizio’ ad usare la sysenter nel suo kernel a partire da WindowsXP.

Neuromancer

La prima versione del documento e’ stata postata da me sul forum del Ticino Linux User Group (Lugano) ed e’ consultabile: http://www.tilug.ch/forum/viewtopic.php?t=266

Configurare, compilare ed installare un kernel 2.4.X funzionante in 10 passi

Ho eseguito la prova su Linux Red Hat 9. Tutti i passi che elencherò sono stati personalmente testati. Sono passato dal kernel 2.4.20-8 in dotazione con il CD di installazione di Red Hat 9, al kernel 2.4.26. I seguenti passi descriveranno pertanto la configurazione, la compilazione e l’installazione di quest’ultimo, ma sono validi per qualsiasi kernel 2.4.X (dove “X” sta ad indicare il numero del kernel che siete intenzionati ad usare). Non è il modo migliore in assoluto, ma è SICURO, dato che andrete ad usare una configurazione del kernel già valida per il vostro PC. Eseguite senza timore le seguenti operazioni entrando con i diritti di root.
Questa guida è rivolta ai beginner di linux e non agli utilizzatori esperti.
Ogni commento è ben accetto.

1. Scaricate il file linux-2.4.26.tar.bz2 (o quello 2.4.X di vostro gradimento) da ftp://ftp.kernel.org/pub/linux/kernel/v2.4.X

2. Mettere il file in /usr/src/
Adesso scompattate il file scaricato con il seguente comando:
# cd /usr/src/
# tar jxvf linux-2.4.26.tar.bz2
# cd linux-2.4.26

3. Digitate:
# make xconfig
(o “# make menuconfig” senza virgolette).

4. Dopo qualche istante vi apparirà una schermata che vi permetterà di configurare il vostro kernel. Se siete esperti non starete usando sicuramente questa guida, perciò do per buono che siate alle primissime armi con linux. Dato che la maggior parte delle voci che compariranno risulteranno per voi assolutamente incomprensibili, NON modificatele, ma semplicemente cercate il pulsante LOAD AN ALTERNATE CONFIGURATION FILE (se state usando xconfig, altrimenti se state usando menuconfig, scendete in basso con la freccia sino ad arrivare sulla scritta testé riportata). Adesso vi comparirà una label in cui selezionare una configurazione di kernel esistente. Questo passaggio è assolutamente sicuro, dato che voi caricherete la vostra attuale configurazione. Scrivete nella label:
/boot/config-2.4.20-8
Quindi caricatela (load). (La 2.4.20-8 è quella di default per Red Hat 9, ognuno dovrebbe andare a vedere qual è la sua nella directory /boot/ e troverete sicuramente un file di configurazione dal nome molto simile – se non uguale – a config-2.4.20-8).
N.B.: se state usando xconfig dovete cercare la vostra directory /boot/ con gli appositi tasti della finestra che vi comparirà, altrimenti dovrete digitare /boot/ nella label più in alto della finestra di selezione e scegliere config-2.4.20-8. Se invece state usando menuconfig, allora dovrete posizionare il mouse nella label di scelta, ciccare col tasto sinistro del mouse, cancellare la scritta che compare e scrivere /boot/config-2.4.20-8. Mi raccomando: NON usate i tastini numerici (quelli alla destra della vostra tastiera), perché con molta probabilità non riuscirete a scrivere alcunché.

5. Tra le varie voci di configurazione comparirà di sicuro File System. Cliccate su questa (se state usando xconfig, con menuconfig basta posizionarvi sopra con la freccia e premere invio per accedere ad una sotto-area di selezione). Assicuratevi che sia selezionata la voce ext3 journaling. Se è selezionata allora è tutto a posto, altrimenti selezionatela (cliccate su “y” per xconfig, portatevici sopra con la freccia e premete il tasto “y” con menuconfig). Adesso fate EXIT &SAVE.

6. Digitate (come richiesto dal messaggio che comparirà sulla vostra shell):
# make dep

7. Se NON si sono verificati messaggi di errore (e SOLO in questo caso), procedete e digitate dalla solita shell:
# make clean && make bzImage
Se si è verificato qualche errore forse avete toccato/selezionato qualche tasto di troppo. Non vi allarmate: riprendete dal punto 4 e rincominciate la procedura.

8. A questo punto, quasi sicuramente vi sarà comparso un messaggio del tipo:
The kernel is too big to standalone…
Non preoccupatevi, significa che il vostro kernel ha dimensioni tali da non entrare in un dischetto floppy. Adesso dovete digitare i seguenti comandi:
# make modules
Se il precedente comando non ha dato luogo ad errori, una volta terminata l’elaborazione da parte del PC (di solito la fase di creazione dei moduli dura diversi minuti, potete approfittarne per telefonare ai vostri amici o prendere un po’ d’aria) digitate anche quanto segue:
# make modules_install

9. A questo punto avete quasi finito: restano solo poche e semplici operazioni.

# cp /usr/src/linux2.4.26/arch/i386/boot/bzImage /boot/bzImage
se avete un i386
# mkinitrd /boot/initrd-2.4.26.img 2.4.26
N.B.: tra …bzImage e /boot/… della prima riga di comando c’è uno spazio, così come tra …/initrd-2.4.26.img e 2.4.26

10. Adesso resta solo da configurare il boot loader in modo che alla partenza venga caricato il vostro nuovo kernel. In questo tutorial darò per buono che stiate usando Lilo.
# cd /etc/
# vi lilo.conf
Adesso sarete nel programma vi che serve per leggere e modificare i file. Non è intuitivo da usare, ma eseguite le seguenti istruzioni alla lettera e non avrete problemi. In ogni caso, se avete combinato chissà quale confusione, premete il tasto ESC, quindi la sequenza “:q!” ma senza virgolette. In questo modo uscirete forzatamente dal file senza alterarlo.
All’interno del file muovetevi con le frecce. Posizionatevi sull’ultima lettera dell’ultima riga e premete il tasto “a”: adesso siete in modalità inserimento, come apparirà scritto in basso a sinistra sulla vostra shell. Lasciate una riga vuota (premendo invio) e quindi ricopiate quanto segue (se avete Red Hat 9 e state installando il kernel 2.4.26):

image=/boot/bzImage
label=Red-Hat-2.4.26
initrd=/boot/initrd-2.4.26.img
read-only

Quindi premete ESC e poi digitate a sequenza “:wq” sempre senza virgolette.
# lilo
Se non ci sono messaggi di errore proseguite, altrimenti riprendete dal comando # vi lilo.conf e ripetete le operazioni con maggior attenzione: avrete con molta probabilità commesso qualche errore di battitura.

— Fine procedura —

Con tale procedura non viene minimamente intaccato il vecchio che state usando: in caso di malfunzionamenti del nuovo kernel, potrete continuare ad usare quello vecchio, senza perdere i dati e dover reinstallare tutto da capo. Adesso non vi resta che riavviare il vostro PC. Vi dovrebbe comparire una schermata in cui poter scegliere con quale kernel far partire il vostro sistema operativo. Se avevate installato in precedenza il kernel 2.4.20-8 vi comparirà la scritta linux come prima scelta e poi la scritta Red Hat 2 4 26 come seconda scelta. Se non avete modificato i parametri di default, dovreste avere 10 secondi per scegliere quale delle due usare (linux sarà quella selezionata di default). Ovviamente selezionate la seconda (Red Hat 2 4 26) per testare se tutto è andato a buon fine. Qualora dopo qualche secondo vi comparisse una scritta del tipo kernel panic non preoccupatevi: probabilmente avete combinato qualche pasticcio. Riavviate il vostro PC e selezionate il vecchio kernel (linux) e riguardate le operazioni che avete eseguito per capire dove avete sbagliato.

Buon lavoro e buona sperimentazione col vostro nuovo kernel! 🙂

Albe

P.S.: ricordate che con linux l’unico modo per imparare è provare, provare, provare…

uname

Come raccogliere informazioni sul sistema operativo e sull’hardware usati.

Ottenere informazioni sul sistema.

Il comando uname permette di ottenere informazioni relative al proprio ambiente.
La sintassi è la seguente: uname [opzioni]

-a, –all: visualizza tutte le informazioni sul sistema (di seguito elencate);
-s, –kernel-name: visualizza il nome del kernel;
-n, –nodename: visualizza l’hostname di rete;
-r, –kernel-release: visualizza la release del kernel;
-v, –kernel-version: visualizza la versione del kernel;
-m, –machine: visualizza tipo di hardware della macchina;
-p, –processor: visualizza il tipo di processore;
-i, –hardware-platform: visualizza la piattaforma hardware;
-o, –operating-system: visualizza il sistema operativo;
–help: visualizza l’help in linea ed esce;
–version: visualizza la versione ed esce;

Esempi:
[homer@Apollo13 ~]$ uname -r
2.6.9-1.667
La versione del kernel è la 2.6.9
[homer@Apollo13 ~]$ uname -p
athlon
Il processore del sistema è Athlon

cat /proc/cpuinfo

Visualizza le informazioni riguardanti i processori presenti sul sistema.

homer@enigma:~$ cat /proc/cpuinfo
processor : 0
Numero del o dei processori partendo dall’identificativo 0
vendor_id : GenuineIntel
Marca processore
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
Dati sul modello della cpu
cpu MHz : 600.030
Frequenza processore
cache size : 256 KB
Dimensioni della memoria cache
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
Controllo relativo a bug noti
fpu : yes
fpu_exception : yes
Caretteristiche relative al calcolo in floating point
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
Caratteristiche del processore
bogomips : 1196.03

Nota: qualora sulla macchina siano montati processori Intel che supportano la tecnologia Hyper-Threading per ogni CPU fisica vengono visualizzate due CPU logiche. Su una macchina con due processori ne vengono quindi visualizzati 4.

cat /proc/loadavg

Visualizza il carico medio del sistema. Fornisce i dati al comando uptime.

homer@Joker:~$ cat /proc/loadavg
0.08 0.02 0.01 2/56 1601
Visualizza rispetivamente il carico medio del sistema negli ultimi 1, 5, 15 minuti, il numero dei processi in escuzione/il numero dei processi totali, l’ultimo ID di processo assegnato dal sistema

cat /proc/mounts

Visualizza le partizioni attualmente montate sul sistema.

homer@Joker:~$ cat /proc/mounts
/dev/root / ext3 rw 0 0
/dev/hda1 /scambio ext3 rw 0 0
/dev/hdb2 /disco2 ext3 rw 0 0
none /dev/pts devpts rw 0 0
none /proc proc rw 0 0
I dati sono visualizzati in modo simile a mtab. I valori visualizzati rappresentano nell’ordine: la device, il mount point, il tipo di file system, le opzioni di mount, la modalità di backup, e di check

cat /proc/swaps

Visiualizza le partizioni di swap presenti sul sitema, le dimensioni, la quantia di spazio utilizzato, e la priorità di utilizzo.

homer@enigma:~$ cat /proc/swaps
Filename Type Size Used Priority
/dev/hda5 partition 289128 664 -1

cat /proc/modules

Visualizza i moduli attualmente caricati dal sistema.

homer@enigma:~$ cat /proc/modules
uhci 24444 0 (unused)
usbcore 59308 1 [uhci]
snd-ens1371 11364 0 (unused)
gameport 1420 0 [snd-ens1371]
snd-pcm 56072 0 [snd-ens1371]
snd-timer 13604 0 [snd-pcm]
snd-page-alloc 6328 0 [snd-pcm]
snd-rawmidi 12740 0 [snd-ens1371]
snd-seq-device 3888 0 [snd-rawmidi]
snd-ac97-codec 49500 0 [snd-ens1371]
snd 30852 0 [snd-ens1371 snd-pcm snd-timer snd-rawmidi snd-seq-device snd-ac97-codec]
soundcore 3396 2 [snd]
8139too 14376 1
mii 2272 0 [8139too]
crc32 2880 0 [8139too]
ide-scsi 9328 0
agpgart 43940 0 (unused)
Le informazioni visualizzate sono rispettivamente: il nome del modulo, la dimensione in byte, se il modulo è in memoria, l’eventuale dipendenza da un altro modulo tra parentesi quadre, se è in uso, e la modalità con la quale può essere scaricato dalla memoria, oppure se non è utilizzato tra parentesi tonde

cat /proc/version

Visualizza la versione del kernel in uso, data di compilazione, e compilatore utilizzato.

homer@enigma:~$ cat /proc/version
Linux version 2.4.26 (root@tree) (gcc version 3.3.4) #6 Mon Jun 14 19:07:27 PDT 2004

cat /proc/filesystems

Visualizza l’elenco dei file system supportati dal kernel in uso sul sistema.

homer@enigma:~$ cat /proc/filesystems
nodev rootfs
nodev bdev
nodev proc
nodev sockfs
nodev tmpfs
nodev shm
nodev pipefs
ext3
ext2
nodev ramfs
umsdos
msdos
vfat
iso9660
nodev nfs
reiserfs
nodev devpts
nodev usbdevfs
nodev usbfs
Viene indicato rispettivamente il tipo di dispositivo, a caratteri (nodev) o a blocchi e il nome del filesystem

finger @kernel.org

Con un semplice comando da shell è possibile conoscere le ultime relase del kernel.

$finger @kernel.org
oppure sbizzarriamoci filtrando le informazioni interessate
$finger @kernel.org | grep “stable version”
The latest stable version of the Linux kernel is: 2.6.7

Kernel Fun

Il kernel Linux.
Un improbabile coagulo di codice multiforme.
Scritto da centinaia di hacker sparsi per i quattro angoli del globo e coordinati da un finlandese che non parla nemmeno il finlandese.
Realizzato per il gusto di farlo, senza lucro, in barba al dio denaro.
Passando notti insommi, smanettando su improbabile hardware e arcani algoritmi.
Decine, centinaia, migliaia di righe di codice, innumerevoi patch, implacabili sessioni di gcc, esteso uso di vi.

Un simile uragano di keystrokes distribuiti non poteva non contenere sprazzi di humour informatico, gocce di spirito cyperpunk, estratti di conoscenza ilare superiore.
Su KernelTrap c’è un articolo che parla di kernel humour, con relativo codazzo di comments in una escalation di umorismo da smanettone.
Del genere che quando ridi non sai se preoccuparti o esserne contento.

E’ tutto in inglese, ovviamente, ma questo non dovrebbe essere un problema.

Compilare un kernel linux

La compilazione del kernel è un passaggio importante per molti sistemi Linux.
Oltre ai vantaggi di performance che derivano dalla customizzazzione del kernel si possono evitare possibili problemi di sicurezza legati a features che non sono indispensabili per l’erogazione del servizio oppure al semplice funzionamento di un device particolare.
Di fatto, seppur non indispensabile, è sempre raccomandabile la ricompilazione di un kernel su un server destinato ad andare in produzione ed essere accessibile via Internet.

I passaggi per la compilazione di un kernel sono relativamente semplici e schematici:
Download e scompattazione dei sorgenti; configurazione; compilazione; installazione del kernel.

– DOWNLOAD DEI SORGENTI O DELLE PATCH
Il sito ufficiale per il kernel linux è http://www.kernel.org, dove si ha la possibilità di scaricare i sorgenti del kernel nelle sue varie versioni. Si può scaricare l’intero file dei sorgenti con documentazione che si presenta come un tar.gz o tar.bz2 di 20-30 Mbyte, oppure scaricare solo le patch, di dimensioni molto minori, che, di versione in versione, contengono solo le differenze nei sorgenti.

– SCOMPATTARE IL TARBALL SCARICATO
La directory in cui scompattarlo è /usr/src. E’ necessario avere l’ambiente di compilazione in /usr/src/linux, per cui si usa, generalmente, creare un link simbolico di nome /usr/src/linux che punta alla directory che contiene effettivamente i sorgenti del kernel (es: ln -s /usr/src/linux-2.4.18 /usr/src/linux). Cambiando il puntamento del symlink /urc/src/linux è possibile passare velocemente a compilare kernel di diverse versioni.

– APPLICAZIONE DELLE EVENTUALI PATCH
In questo caso verrà applicata la patch 2.4.19 per patchare il kernel 2.4.18
[root@dido linux]# cat ../patch-2.4.19 | patch -p1
patching file COPYING
patching file CREDITS
patching file Documentation/Changes
patching file Documentation/Configure.help
[…]

– PULIZIA DEI SORGENTI
E’ un operazione richiesta ogni volta che si compilano dei sorgenti precedentementa già compilati.
[root@dido linux]# make clean
make[1]: Entering directory `/usr/src/linux-2.4.17/arch/i386/boot’
rm -f tools/build
rm -f setup bootsect zImage compressed/vmlinux.out
[…]
rm -f procfs_example.sgml
make[1]: Leaving directory `/usr/src/linux-2.4.17/Documentation/DocBook’

– CONFIGURAZIONE DEL NUOVO KERNEL
Ci sono diverse interfacce per configurare il kernel. Il comando più utilizzato è make menuconfig, ma se si ha una macchina con X attivato si ha la possibilità di utilizzare un frontend grafico con il comando make xconfig, altrimenti si ha la possibilità di utilizzare un comando make config per utilizzare un front-end del tutto testuale.

[root@dido linux] make menuconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts/lxdialog all
make[1]: Entering directory `/usr/src/linux-2.4.17/scripts/lxdialog’
make[1]: Leaving directory `/usr/src/linux-2.4.17/scripts/lxdialog’
/bin/sh scripts/Menuconfig arch/i386/config.in
Using defaults found in .config
Preparing scripts: functions, parsing………………………………………………………………done.

[root@dido linux] make xconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts kconfig.tk
make[1]: Entering directory `/usr/src/linux-2.4.17/scripts’
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkparse.o tkparse.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkcond.o tkcond.c
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -c -o tkgen.o tkgen.c
gcc -o tkparse tkparse.o tkcond.o tkgen.o
cat header.tk >> ./kconfig.tk
./tkparse > kconfig.tk
echo “set defaults “arch/i386/defconfig”” >> kconfig.tk
echo “set ARCH “i386″” >> kconfig.tk
cat tail.tk >> kconfig.tk
chmod 755 kconfig.tk
make[1]: Leaving directory `/usr/src/linux-2.4.17/scripts’
wish -f scripts/kconfig.tk

[root@dido linux]# make config
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
/bin/sh scripts/Configure arch/i386/config.in
#
# Using defaults found in .config
#
*
* Code maturity level options
*
Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?]
[…]

Dopo aver configurato le singole componenti del kernel da attivare (è la fase più importante, in quanto una errata scelta può portare al blocco del sistema al reboot o al mancato supporto di alcuni device della propria macchina) si ha la possibilità di salvare la propria configurazione su un file alternativo, altrimenti quando si esce dal menu di configurazione verrà chiesto di salvare la configurazione in .config, file di default per la compilazione del kernel.

– MODIFICA DEL MAKEFILE – Solo se si usa make install per l’installazione automatica del kernel
Per semplificare le operazioni dell’installazione dell’immagine del kernel è sufficiente scommentare la seguente riga nel makefile, per ritrovarsi la copia dell’immagine e dei file relativi indispensabili al boot nel PATH configurato (abbinato al comando make install):
# INSTALL_PATH specifies where to place the updated kernel and system map
# images. Uncomment if you want to place them anywhere other than root.
export INSTALL_PATH=/boot
Se questa operazione non viene fatta i file compilati del nuovo kernel dovranno essere spostati a mano, secondo le indicazioni sotto riportate.
E’ possibile inoltre aggiungere una EXTRAVERSION che permette di identificare compilazioni dello stesso kernel ma con configurazioni diverse.
EXTRAVERSION =-SARUMAN

– COMPILAZIONE DEI SORGENTI
Eseguire in sequenza i seguenti comandi:
make dep Crea le dipendenze per la compilazione dei sorgenti
make clean Esegue un clean
make bzImage Crea l’immagine del kernel che verra’ caricata al boot
make modules Compila i moduli
make modules_install Copia i moduli in /lib/modules/$KERNEL_VERSION

– INSTALLAZIONE DEL NUOVO KERNEL
Eseguite tutte le operazioni per la compilazione si deve installare l’immagine del kernel, si hanno due alternative:
Manuale
All’interno della directory, /usr/src/linux/arch/$arch/boot/ si avrà l’immagine del kernel (Il file bzImage) la quale dovrà essere copiata manualmente in /boot possibilmente con un nuovo nome per evitare sovrascrizioni nelle prossime compilazioni.
Dove $arch corrisponde al nome dell’architettura del sistema per cui e’ stato compilato il kernel:
neo@eva:~$ls -l /usr/src/linux/arch/
total 72
drwxr-xr-x 7 root root 4096 2004-02-23 11:13 alpha
drwxr-xr-x 21 root root 4096 2004-02-23 11:13 arm
drwxr-xr-x 7 root root 4096 2004-02-23 11:13 cris
drwxr-xr-x 7 root root 4096 2004-02-23 11:13 i386
drwxr-xr-x 14 root root 4096 2004-02-23 11:13 ia64
drwxr-xr-x 20 root root 4096 2004-02-23 11:13 m68k
drwxr-xr-x 34 root root 4096 2004-02-23 11:13 mips
drwxr-xr-x 6 root root 4096 2004-02-23 11:13 mips64
drwxr-xr-x 8 root root 4096 2004-02-23 11:13 parisc
drwxr-xr-x 13 root root 4096 2004-02-23 11:13 ppc
drwxr-xr-x 8 root root 4096 2004-02-23 11:13 ppc64
drwxr-xr-x 7 root root 4096 2004-02-23 11:13 s390
drwxr-xr-x 6 root root 4096 2004-02-23 11:13 s390x
drwxr-xr-x 8 root root 4096 2004-02-23 11:13 sh
drwxr-xr-x 9 root root 4096 2004-02-23 11:14 sh64
drwxr-xr-x 8 root root 4096 2004-02-23 11:14 sparc
drwxr-xr-x 9 root root 4096 2004-02-23 11:14 sparc64
drwxr-xr-x 9 root root 4096 2004-02-23 11:14 x86_64
Automatica
Tramite il comando make install, si ha la possibilità di spostare in modo automatico i file nella directory /boot:
make install Copia l’immagine del kernel nella posizione precedentemente definita nell’INSTALL_PATH

– CONFIGURAZIONE DEL BOOT LOADER
Configurare il boot loader inserendo la possibilità di eseguire il boot con il nuovo kernel.
Ricordarsi sempre di mantenere un’immagine di un kernel funzionante con la relativa entry nel boot loader come backup per evitare spiacevoli inconvenienti (può capitare di compilare un kernel senza il supporto di driver necessari, che si blocca al boot, per cui è sempre necessario aver la possibilità di bootare con il vecchio, funzionante, kernel).

– REBOOT

Le meraviglie del /proc filesystem

Il /proc filesystem è uno dei concetti di Unix più potenti e affascinanti.
In questa directory, che i programmi trattano e vedono come una qualsiasi directory, sono contenuti file e directory che danno in tempo reale informazioni sul sistema.
Di fatto questi file non sono scritti su nessun supporto di memorizzazione e sono espressione diretta del kernel.
Le informazioni che possono trovarsi in /proc sono molte, interessanti e a volte incomprensibili. Di fatto alcuni comuni comandi shell non fanno altro che visualizzare in modo “human readable” info presenti in determinati file in /proc.

Vediamo alcune delle sue parti più interessanti (e accessibili per noi comuni mortali):
/proc/#PID/… – Visualizza per ogni processo in memoria (identificato dal suo PID) molte informazioni utili.
/proc/cpuinfo – Informazioni sulla CPU
/proc/ide/…/ – Informazioni sui dispositivi IDE
/proc/interrupts – Gli IRQ del sistema
/proc/iomem – La memoria I/O
/proc/kcore – Il dump completo della memoria
/proc/modules – I moduli del kernel
/proc/partitions – TUTTE le partizioni degli HD
/proc/pci – I dispositivi PCI
/proc/self – Link simbolico al PID del processo stesso con cui si accede a /proc/self :-!
/proc/version – La versione del kernel
/proc/net/arp – La arp table
/proc/net/dev – I byte trasferiti sui device di rete
/proc/sys/net/ipv4/ – Directory fondamentale con molte informazioni sullo stack tcp/ip. Su alcuni file è possibile cambiare valore per modificare il comportamento del kernel. Per esempio: echo 1 > /proc/sys/net/ipv4/ip_forward abilita il forwarding dei pacchetti sulla macchina (necessario se opera come firewall o gateway di una rete).

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

 
%d blogger hanno fatto clic su Mi Piace per questo: