Re: LSM o patch per il kernel...

On 02 Dec 2002 11:05:06 +0100
Paolo Perego <p_perego@modiano.com> wrote:

>Stavo   pensando,  mentre   preparavo  una   cioccolata   calda  ieri
>pomeriggio, al problema della  redirezione delle system call che sarà
>impossibile  nei nuovi kernel ( > 2.5.41 ). Sicuramente affiancarci a
>LSM è la soluzione che appare  più immediata anche per le finalità di
>sicurezza che il progetto si pone.

Ci ho  pensato io a correggere  quell'impossibile...segnaliamo il typo
nel Changelog? ;)

>Mi domandavo però se non fosse il caso, rivendicando autonomia per il
>nostro  progetto,  di preparare  una  patch  per  il kernel  che,  se
>abilitato il supporto ad angel in fase di compilazione, introduca dei
>puntatori a  funzione alle nostre routine di  controllo.  Quando root
>insmod-erà  il  modulo  angel,   tali  hook  verranno  collegati  coi
>puntatori  a funzione  e tutto  funzionerà come  prima  senza bisogno
>della sys_call_table  perché saremo  "dentro" la system  call.  Idee,
>opinioni e critiche

Cominciamo  subito col  dire che,  per quanto  mi riguarda,  l'idea di
patchare il kernel mi è  spesso frullata nella testa e forse aspettavo
soltanto  che  qualcuno  tirasse  fuori quelle  paroline  magiche  per
esprimere il mio consenso.  :)

L'idea mi piace  per molti motivi e sicuramente su  tutti va citato il
fatto  che , per  quanto paradossale  possa sembrare  ciò che  sto per
dire, lavorare nel  kernel è più semplice che non  lavorare con un LKM
perchè ti evita una marea di sbattimenti (talvolta realmente inutili).
Però io sarei molto più estremo di Paolo nel design. Mi spiego meglio.

Vorrei portare  la mia esperienza  di questi giorni per  suggerire una
soluzione che tanto piace a coloro che mi pagano la pagnotta in questi
giorni.  Infatti,  per lavoro,  sto modificando il  TCP di Linux  e ho
deciso  di farlo  inserendo del  codice che,  se è  abilitato  il flag
CONFIG_XXX opportuno,  inserisce 'qualcosa  di diverso nel  flusso del
kernel' altrimenti non fa assolutamente  nulla.  Per intendersi  se la
prima funzione da  chiamare per fare il lavoro  sporco la chiamo foo()
inserisco qualcosa del tipo

#ifdef CONFIG_XXX 
static inline void foo(void) {
	__foo()
	return; 
} 
#else 
static inline void foo(void) {
	return; 
} 
#endif

con __foo() e  tutte le altre funzioni che  servono compilate soltanto
se è definito CONFIG_XXX.

Questo consente di  chiamare dal codice della syscall  foo() avendo la
certezza che se l'utente non ha abilitato il flag essa non farà nulla.
Personalmente  l'approccio  mi piace  per  un  motivo  e cioè  che  se
vogliamo  possiamo  introdurre  varie  opzioni  di  compilazione  (con
relativi  flags) abilitabili  col classico  'make  menuconfig'. Questo
consente  di  abilitare  o  meno  il  controllo  su  questa  o  quella
funzionalità direttamente  in fase di  compilazione e secondo  anche i
gusti/desideri/esigenze dell'utente.  Inoltre  ciò lascia aperta anche
la  possibilità, come  proposto  da Paolo,  di  definire delle  'porte
aperte'  verso il  kernel  sfruttabili  tramite LKM  anche  se, a  ben
pensarci, una soluzione monolitica  forse sarebbe più sicura...bah chi
vivrà vedrà! :)

PS  per Paolo  :In questo  periodo il  lavoro è  tanto.  Sto scrivendo
troppo  codice ogni giorno per  avere, quando  torno a  casa, anche la
voglia soltanto di accendere il pc. Appena mi libero un pò riprendiamo
quel discorso sulla execve....a proposito come procede?


Alla prossima,

Angelo Dell'Aera 'buffer' 
<buffer@users.sourceforge.net>

PGP information in e-mail header

PGP signature