[Hack] Crash & Co. (era: rimando a martedi 23/04 o no?)

[A&P]

> > bene, prg. 3 cerca di indirizzare una area di memoria di prg.2 con
> > un puntatore fasullo perche' sa che verso la fine di prg. 2 ci sono
> > dei dati che a lui interessano, magari ci va anche a scrivere
>
> "puntatore fasullo"=?
>
fasullo nel senso che non indirizza la "propria area di memoria" ma quella
accanto...


> > qualcosa... come avviene? se non si considerano buchi di programma
> > si deve considerare quella parte di librerie "shared" e cioe'
> > condivise che fanno funzionare ad es. il kde e le sue applicazioni,
> > lo gnome e le sue applicazioni (leggi qtlib o gtklib...) queste
> > stanno da qualche parte in ram e se il proprietario del processo
> > server XFree e' lo stesso del proprietario del processo del
> > programma "figlio" quest'ultimo puo' accedere in lettura e perche'
> > no? in scrittura sulla area di memoria "condivisa".
>
> Intendi gli applicativi che girano sopra kde o gnome... cioe': se
> lancio kmail questa usa delle librerie condivise con... tutto il
> resto di kde e queste librerie vengono (precedentemente) caricate in
> RAM... quindi:
>
> server XFree e' un processo (padre); un programma che gira sopra X e'
> un processo (figlio) e tutti e due hanno come proprietario l'utente
> che li ha lanciati... Opossum lancia X con "startx", poi lancia un
> programma qualunque su X e la situazione che si viene a creare e'
> quella che hai descritto te... giusto? Non ho capito pero' come ci
> s'infirza un virus...
>
quanto stai obiettando mi sembra giusto, ma ancora non ho parlato dei suid e
sgid... diciamo che se un "utente normale" e' abilitato a lanciare un
"server" come X questi non e' detto che "giri" con i privilegi
dell'utente... potrebbe girare con i privilegi di root per esempio, dipende
da come e' stato configurato il programma per la sua compilazione, ok?

> > dirai tu, ma il
> > meccanismo di protezione della area di processo dove sta? c'e',
> > dico io appunto sul processo, ma sulla area di memoria condivisa
> > avrei dei dubbi... ecco li' mi fermo io perche' non ne so di
> > piu'... quando detti l'esame di sistemi operativi non esistevano i
> > meccanismi implementati oggi dalle ultime versioni di kernel...
>
> Sinceramente non ero arrivato a pensare al meccanismo di
> protezione... anche perche' non ho ben chiaro il meccanismo di
> attacco e, volendo o nolendo, per concepire una difesa bisogna
> concepire un attacco.
>
per "protezione della area di processo" intendo qui protezione della memoria
del processo stesso e cioe' lo spazio di indirizzamento permesso a quel
processo, e cioe' la memoria allocata a run-time e la memoria allocata
staticamente.

> [...]
>
> > ogni processo e' figlio ed eventualmente padre di di altri processi
> > normalmente e tutti lavorano in "time slice" ovviamente, e' per
> > questo che il kernel di solito non si blocca se si blocca una
> > applicazione... sia essa un comando "ls" o XFree...
>
> Scusa ma per me gli "ovviamente" non sono cosi' frequenti. Quando
> parli di "time slice" stai dicendo che ogni processo si mette in coda
> per avere la sua fettina di tempo (di utilizzo del processore)?
>
si e' cosi', ma scusami tu...

> > > E quando parlo di processi mi riferisco a processi attivi e
> > > demoni o esiste altro?
> >
> > i processi in quanto tali sono residenti in memoria (ram o
> > swappata) e il loro stato cambia continuamente da Run a Wait a
> > Swapped ecc... i processi non sono altro che "istanze" di programmi
> > ok?
>
> ok la prima parte; cosa significa "i processi non sono altro che
> 'istanze' di programmi". Istanza e' una domanda fatta a
> "qualcuno/qualcosa" che esige, per sua stessa natura, una risposta.
>
istanza di programma e' la copia "attiva" in RAM del programma detto anche
processo in esecuzione con tutto cio' che questo comporta, vuol dire che
potrei avere infinite istanze in RAM dello stesso programma memorizzato su
disco...

> [...]
>
> > > Come dire o hai sbagliato indirizzo o vuoi mettere troppa roba
> > > all'indirizzo giusto...
> >
> > no, semplicemente che o hai esaurito lo spazio a tua disposizione
> > oppure dove tu vuoi scrivere NON ci puoi scrivere perche' c'e' già
> > scritto da qualcun altro!!!
>
> Nel primo caso si tratterebbe di baco? E nel secondo si potrebbe
> trattare anche di un virus?
>
potrebbe trattarsi di baco in quanto il processo non sa gestire l'evento
"manca spazio in RAM per l'esecuzione", nel secondo potrebbe trattarsi di un
baco o di un virus...

> [...]
>
> > <invito>
> > allora ti aspettiamo e magari ne parliamo, porto un po' di
> > documentazione ok? dimmi quando c6...
> > </invito>
>
> ... la lezione di ieri sera e' stata interessantissima (secondo me),
> purtroppo il sottoscritto e' arrivato anco un po' in ritardo.... ma
> la documentazione non me l'hai fatta vede' per punizione?
>
l'ho portata ma non te l'ho fatta vede' perche':
1) il tempo e' tiranno
2) non ne ho avuta l'occasione

> > grazie per l'occasione di ripasso...
>
> Grazie a te per questa lista (e per la pazienza).
>
> ciao
> Gianni
>
spero di essere abbastanza chiaro, altrimenti ditilo...
ciao
Alx