linux user group brescia

From: Luca Giuzzi <giuzzi a dmf.bs.unicatt.it>
> Mah.. log a livello "atomico" e' fattibile, ma FORTEMENTE sconsigliato per
>  vari motivi:

 Aspetta... NON a livello "atomico" (debugger-like): ammazzerebbe il
sistema, credo.
 Diciamo che potrebbe riportare solo "le cose principali" tipo la partenza
dei vari task e chi li fa partire... al limite l'open/close esplicito di
file (non TUTTA la roba che il sistema apre per ogni task), altrimenti ci
vorrebbe una CPU aggiuntiva solo per il monitoraggio real-time (e in certi
sistemi effettivamente c'è).

>  1. dove vuoi installare il logger? A livello di kernel (syscalls), a
livello
>    di libc (funzioni) o a livello di shell (comandi)?

 Direi a livello di kernel, il più in basso possibile: dove DEVE passare
tutto (e NON bypassabile).
 Però mi sembra abbia poco senso riportare nell'ipotetico Master Log tutte
le syscalls effettuate (che immagino essere una per ogni operazione atomica
del sistema).

 La vedrei piuttosto così: con un loglevel=default vengono riportate solo le
"macro operazioni". Ma non "macro" come quelle che compaiono adesso in
messages: m'interessa poco sapere che Cron ha lavorato 5-6 volte e che tizio
o caio sono entrati nel sistema se non so COSA hano fatto, anche solo in
linea di massima: diciamo che questo potrebbe essere una specie di
loglevel=light.

 Agendo sul parametro (ipotetico) loglevel potrei (A) aumentare il dettaglio
degli eventi riportati nel Master Log per tutta l'attività del sistema (con
livelli light, normal, medium, heavy ed huge), ovviamente appesantendo il
tutto, o (B) aumentare la "sorveglianza" di un solo componente (ad es httpd)
lasciando il resto del sistema più scarico (in questo caso vedrei bene anche
l'introduzione di due ulteriori livelli di dettaglio: trace e debug).

 Essendo il sistema a tracciare se stesso (in un log append-only, come
dicevano anche altri) mi pare piuttosto improbabile, a meno di una
ricompilazione, riuscire a bypassare i controlli: non è come rinominare i
programmi o "pulire" un file di history.
 Se poi un'intruso arriva a ricompilarmi il kernel... beh... tanto vale che,
visto che c'è, si porti via l'intero PC, tastiera e monitor compresi.  ;-)))

>  2. quale e' l'overhead? mai provato a fare uno strace(1) di un
programmino
>    semplice come ls? Prova a guarda la quantita' di informazioni in
transito...

 Un momento: NON ho parlato di trace. Non sono un programmatore (anche se
qualcosa ho scritto) ma anche in un sistema con, mettiamo, una decina di
utenti (che per una macchina normale come la mia devono essere un discreto
carico) le operazioni esplicite (lancio/termine di programmi, open/close di
file e di ports e poco altro) non dovrebbero essere troppo onerose da
"riportare".
(btw: ho dato un'occhiata a strace: veramente interessante, anche se troppo
"atomica" per quel che intendevo io). :-)

 In fin dei conti NON sto parlando di tracciare in real-time il
funzionamento del clock di sistema: solo di accodare un record (timestamp +
user + action) in un "master log" testuale scrivibile solo dal kernel...
poche decine di byte per record per "azione esplicita" o per "evento" (ad
es. l'apertura di un port, NON il dump di ogni bit in transito) in modo da
avere un "indizio" da poter analizzare.

 Per quanto ne so io la trace è una cosa che si fa dopo: una volta
individuato il componente (programma, file, device) da mettere sotto esame.
Lì sì che si producono, di solito per brevi intervalli di tempo, moli
medio-grandi di dati (che non avrebbe alcun senso produrre abitualmente:
metti un sistema permanentemente sotto trace e lo massacri).

>    Un logger relativo la shell e' facilissimo da bypassare (vedi la
faccenda rsh
>    = restricted shell distribuita con sendmail... basta rinominare la bash
>    ls e si `sfugge' alla gabbia); un logger relativo la glibc soffre
comunque
>    degli stessi problemi di strace e non e' troppo indicativo. Il process
>    accounting potrebbe essere un po' piu' utile, ma non e' comunque
disegnato
>    per monitorare i comportamenti: solo il profilo d'uso del sistema.

 Nella mia ignoranza pensavo che, dato che è il kernel a far fare tutto
(quello che ha sempre "la palla in mano"), dovrebbe essere lui il componente
disegnato per scrivere nel log, con la "finezza" richiesta di volta in
volta, il comportamento del sistema... o è possibile aprire e chiudere un
file (o un port) senza farglielo sapere ?

>  3. quali sono i tuoi diritti sul sistema? essere l'amministratore non
vuol
>   dire che puoi leggere la posta di tutti i tuoi utenti o guardare
>   costantemente quello che fanno: non e' legale e NON VUOI farlo: la
>   responsabilita' sarebbe semplicemente troppa; e' buona cosa poter
indagare
>   se ci sono situazioni `sospette', ma anche in quel caso si deve stare
>   molto attenti.

 Infatti questo comportamento, oltre che illegale (e comunque oneroso in
termini di tempo), non sarebbe molto utile per sapere COSA viene fatto: mi
interessa di più sapere che un utente ha ricevuto tre volte un messaggio
piuttosto che sapere cosa c'era scritto nei tre messaggi: il primo esprime
un comportamento (il ricevere messaggi) il secondo è... spionaggio.  ;-)

 Ovviamente se poi necessito di andare più a fondo, una volta individuata la
componente che ritengo critica (sempre seguendo l'esempio: il transito di
messaggi), posso sempre andare a snasare direttamente (in /var/spool/mail
ecc.) oppure (ma si può ?) far partire una "buffer trace" su una risorsa di
sistema (un device, un file, un port, ecc.) ed analizzarne a posteriori
l'output, magari con un programma che filtra le informazioni.

>  Il /var/log/messages fornisce informazioni sullo stato del sistema e/o
>   su vari servizi attivati. wtmp/btmp memorizzano tutti i logins sulla
>   macchina: dati utili SIA per l'amministratore SIA per gli utenti...
>   e' bene controllare che nessuno si sia introdotto nottempo nel proprio
>   account. Per la sorveglianza si devono usare una selezione di metodi
>   diversi...

 Probabilmente qua e là si trovano tutte le informazioni di cui parlavo...
io chiedevo se è previsto (o fattibile) che le stesse vengano registrate in
modo organico in una specie di "master log" (ma forse mi sono abituato
troppo bene con MVS).  :-)

        Bye
        Sky