Newsgroup: it.comp.os.linux.iniziare
Titolo: Vale ancora la pena ricompilare il kernel?

Salve,
 
in una S.p.a. bella grossa con due sedi all'estero mi capito di 
relazionarmi anni addietro con il responsabile CED il quale mi disse che 
per mettere in piedi il server ftp (che l'utente finale utilizzava dal 
web con un'applicazione Java sviluppata dal programmatore interno) aveva 
ricompilato il kernel di una distro Linux (non ricordo quale!) lasciando 
praticamente solo quanto necessario per far girare quel servizio!
 
Secondo voi oggi varrebbe la pena tutto questo per il concetto per il 
quale quello che non c'è non si può "rompere", come si diceva delle auto 
di un tempo, e nel caso specifico quello che non c'è non si può 
hackerare oppure sono solo paranoie?
 
Saluti.
^Bart

 hackerare oppure sono solo paranoie?
 
Se uno sa quello che fa, se uno ha necessita` di
ridurre il tutto al minimo, sia per ragioni di
prestazioni, che di sicurezza, allora puo` essere
una valida soluzione.
 
Fermo restando che si dovrebbe ricompilare anche
altro, probabilmente.
 
bye,
 
-- 
 
piergiorgio

 oppure sono solo paranoie?
 
Credo generalmente che non valga la pena. Dico una
banalità ma per quanto l'architettura sia un
quasi-capolavoro, ci possono essere fonti di instabilità
"lontane" e imprevedibili su altre parti del sistema. Non
per niente se ricordo bene, Debian viene aggiornato con
molta cautela.
 
Poi come dice Piergiorgio, se c'è motivo e il rapporto
costi / benefici lo rende necessario è ovvio che si fa.
 
-- 
"Dovrebbe smettere di praticare auto erotismo."
"Diamine, dottore, perché mai?"
"Perché le sto parlando."
 

 hackerare oppure sono solo paranoie?
 
  I casi in cui è utile ricompialre il kernel sono pochi per un uso
desktop e generalmente i benefici non valgono il lavoro necessario,
soprattutto considerati i frequenti aggiornamenti del kernel e quindi le
numerose compilazioni che si devono fare.
 
  I casi in cui si deve farlo sono quegli usi di nicchia per i quali non
c'è un kernel ottimale già pronto in qualche distribuzione utilizzabile,
e questo è il caso sopratutto dei dispositivi embedded e IoT oppure
nuove piattaforme non ancora pienamente supportate o per le quali non ci
sono distribuzioni che abbiano immagini di installazione già pronte,
tipo i sistemi RISC-V.
 
  In generale la regola aurea è questa: se ti stai chiedendo se ti serve
un kernel personalizzato allora la risposta è no, perché non hai in
mente niente di preciso che manchi nei kernel che hai già a
disposizione.  Se sai che i kernel delle distribuzioni che usi mancano
di qualcosa che ti obbliga a compilare un kernel personalizzato allora
la domanda è futile.
 
 
  Ciao,
 
 
Alessandro
 

 la domanda è futile.
 
Il problema non e` cosa manchi, ma cosa ci sia di troppo.
 
E` una regola generale di _sicurezza_ evitare SW o feature
che non servono, perche` aprono la porta a potenziali bug.
Bug che a loro volto possono essere sfruttati per attacchi.
 
Quindi, se non c'e` non si rompe vale ancora, anche per
moduli o driver che, in apparenza, non sono in uso.
 
Un drive bluetooth puo` crashare anche se non c'e` nessun
dispositivo BT collegato.
 
Un driver USB potrebbe essere caricato in maniera fraudolenta
e, sempre per qualche bug, aprire la porta ad un attacco che
fornisce i permessi, non di root, ma del kernel.
 
bye,
 
-- 
 
piergiorgio

 fornisce i permessi, non di root, ma del kernel.
 
  Ad esempio?  Volessi un kernel semza supporto per l'USB basta mettere
i driver perl'USB in blacklist.
 
  Non ho mai saputo di qualche utente/amministratore di sistema che
abbia salvato un suo sistema da una vulnerabilità del kernel Linux
grazie al fatto di averne compilato uno personalizzato.  Potrebbe essere
successo, certo, ma secondo me non vale lo sforzo e il tempo necessario,
che potrebbero essere usati per rendere il sistema molto più sicuro
imparando e utilizzando strumenti di protezione userland più sofisticati
come Apparmor, SELinux o sistemi di Intrusion Detection, che loro si
bloccano la grossissima fetta delle vulnerabilità di un sistema GNU/Linux.
 
 
Alessandro
 
 

 bloccano la grossissima fetta delle vulnerabilità di un sistema GNU/Linux.
 
Il problema non sono le vulnerabilita`
note, ma quelle non (ancora) note.
 
Tu metti un modulo, ammesso che sia un
modulo, perche` lo stack USB non lo e`,
in blacklist e poi viene fuori che con
un certo comando il kernel tenta di
caricare il modulo e crasha completamente.
 
Era meglio se il modulo non c'era...
 
Non sopravvalutare la sicurezza di un
sistema, perche` i buchi si scoprono
dopo, non prima.
 
bye,
 
-- 
 
piergiorgio

 bye,
 
Saluti!
^Bart
 

 Alessandro
 
Saluti.
^Bart
 

 che hai deciso consciamente di togliere di mezzo giusto?
 
Io credo che qualora via sia un upgrade del
kernel (della distribuzione) o non questo non
venga eseguito, cioe` rimane il vecchio kernel
auto-compilato, oppure venga aggiunto il nuovo
e grub (o chi per lui) parte con quello nuovo.
 
In altri termini, io credo che si debba sempre,
se uno ha deciso di prendere quella strada,
ricompilare ad ogni aggiornamento.
 
Sono, pero`, diversi anni che non ricompilo il
kernel per conto mio, per cui non saprei se vi
sono altri meccanismi disponibili oggigiorno.
 
Bisognerebbe fare una prova, magari con una
macchina virtuale non dovrebbe essere troppo
oneroso.
 
bye,
 
-- 
 
piergiorgio

 bye,
 
Saluti!
^Bart
 

 Era meglio se il modulo non c'era...
 
  Che ci sia o no è indifferente, se non è usato.
  E per essere sicuri che non sia usato: blacklist.
 
  E se lavori in ambiente enterprise: il kernel è vietato ricompilarlo
da se, perché sostituire quello della distribuzione fa decadere
l'assistenza e la garanzia della distribuzione.
 
 
Alessandro
 
 
 

 l'assistenza e la garanzia della distribuzione.
 
Infatti, inizialmente ho scritto "se uno sa quello che fa".
 
D'altro canto, non esiste alcuna distribuzione
che _garantisca_ qualcosa, quindi non cambia molto.
 
bye,
 
-- 
 
piergiorgio

 che _garantisca_ qualcosa, quindi non cambia molto.
 
  Ovviamente si, il fatto che tu ignori che esistano non le rende
inesistenti.  La prima è ovviamente la Red Hat, che garantisce la
sicurezza e l'uptime delle sue installazioni Enterprise con SLA a suo
carico nel caso in cui un sistema non risponda ai parametri garantiti
dal contratto. E questo fanno tutte le distribuzioni per lo stesso
mercato, SuSE e Ubuntu.  Per qeusto le licenze per queste installazioni
costano così tanto.
 
 
 
Alessandro