Re: gruppi di default in debian jessie

2013-12-13 Per discussione Piviul

sa...@eng.it scrisse in data 12/12/2013 14:05:

Usare un editor e /etc/groups pareva poco figo...
l'ho sempre fatto andando a metter mano a /etc/group ma mi chiedevo: se 
esistono certi strumenti avrà un senso e sto cercando di usarli ed in 
effetti mi è stato utile:


sudo usermod -a -G dialout,cdrom,floppy,audio,video,plugdev,netdev

molto più comodo che aprire il file etc no?


Peraltro:

tenere root disabilitato e usare sudo con la configurazione di default
(ovvero con ALL=(ALL) ALL e la cache delle credenziali disabilitata) è
- opinione mia  e di  altri professionisti del  settore -  una cattiva
idea.

la cosa è molto, molto ma molto controversa e dibattuta.

Ciao e grazie

Piviul


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52aacc7a.7080...@riminilug.it



Re: gruppi di default in debian jessie

2013-12-13 Per discussione saint
Piviul writes:
  sudo usermod -a -G dialout,cdrom,floppy,audio,video,plugdev,netdev
  
  molto più comodo che aprire il file etc no?

Forse. L'è che ho imparato a  non aver bisogno di comandi speciali per
automatizzarmi la vita.
 
   Peraltro:
  
   tenere root disabilitato e usare sudo con la configurazione di default
   (ovvero con ALL=(ALL) ALL e la cache delle credenziali disabilitata) è
   - opinione mia  e di  altri professionisti del  settore -  una cattiva
   idea.
  la cosa è molto, molto ma molto controversa e dibattuta.

Lo so. Ma so pure che appena ci saranno in giro un numero sufficiente
di macchine Linux desktop da rendere la cosa remunerativa, qualcuno
scriverà un attacco _anche_ per questa caratteristica di sudo, a naso
all'interno di una di quelle azioni che puntano a colpire quante più
macchine possibili in modo da riuscire alla fin fine a colpire
quella/quelle che interessano in modo indiretto.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21162.54941.435551.110...@mail.eng.it



Re: gruppi di default in debian jessie

2013-12-13 Per discussione Piviul

sa...@eng.it scrisse in data 13/12/2013 10:42:

Lo so. Ma so pure che appena ci saranno in giro un numero sufficiente
di macchine Linux desktop da rendere la cosa remunerativa, qualcuno
scriverà un attacco _anche_ per questa caratteristica di sudo, a naso
all'interno di una di quelle azioni che puntano a colpire quante più
macchine possibili in modo da riuscire alla fin fine a colpire
quella/quelle che interessano in modo indiretto.
Sai che non ho capito perché dici che sudo è più pericoloso di un su -c? 
A me sembra che il problema principale sia che bisogna stare molto 
attenti ad eseguire programmi da root sia che essi siano eseguiti 
utilizzando sudo che utilizzando direttamente l'utente root.


IMHO invece è molto più pericoloso avere l'abitudine ad entrare come 
root per fare attività amministrative così come è molto più 
intrinsecamente insicuro un sistema di cui un potenziale cracker conosce 
già il nome utente dell'utente con i privilegi più elevati...


Piviul


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52aadf5d.3070...@riminilug.it



Re: gruppi di default in debian jessie

2013-12-13 Per discussione Gollum1
Il 13 dicembre 2013 11:20, Piviul piv...@riminilug.it ha scritto:
 Sai che non ho capito perché dici che sudo è più pericoloso di un su -c? A
 me sembra che il problema principale sia che bisogna stare molto attenti ad
 eseguire programmi da root sia che essi siano eseguiti utilizzando sudo che
 utilizzando direttamente l'utente root.

neppure io ho capito questa diatriba... sudo comunque funziona da
terminale, come su -c, come su ti chiede la password prima di eseguire
il comando, ed esegue solo quello... quindi la vedo un po' dura...
certo che se tu sei abituato a digitare la tua password ad ogni
richiesta, senza sapere che ha invocato il comando...

 IMHO invece è molto più pericoloso avere l'abitudine ad entrare come root
 per fare attività amministrative

anche qui non sono completamente d'accordo... se sai quello che stai
facendo ed entri esclusivamente da terminale, grossi problemi non
dovrebbero esserci... naturalmente se sei sicuro dei comandi che vai
poi a lanciare, ma lo stesso pericolo lo avresti lanciandoli con un
bel su -c o sudo.

discorso diverso è se forzi il login con interfaccia grafica con root
come utente, nel qual caso è impossibile sapere che cosa parte e cosa
no... ed è in questo caso facile fare stronzate (ma noi non ci
mettiamo mai alla stregua di winzoz pre 7, vero?).

 così come è molto più intrinsecamente
 insicuro un sistema di cui un potenziale cracker conosce già il nome utente
 dell'utente con i privilegi più elevati...


certo... peccato che nell'uso desktop casalingo, la maggior parte
delle macchine hanno un unico utente, vuoi perché in famiglia più
persone usano lo stesso computer, vuoi perché è solo una persona ad
usare il computer... ma anche in ambito lavorativo, non è impensabile
(e forse è pure la norma), che un portatile linux autogestito, abbia
un solo utente, perché ne sei l'unico utente.

Byez
-- 
Gollum1
Tesoro, dov'é il mio teoro...


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cantvqs-gciy-tizdxcey7jhkfb23r9do26zeaykbzh5zp7u...@mail.gmail.com



Re: gruppi di default in debian jessie

2013-12-13 Per discussione Gian Uberto Lauri
Piviul writes:
  sa...@eng.it scrisse in data 13/12/2013 10:42:
   Lo so. Ma so pure che appena ci saranno in giro un numero sufficiente
   di macchine Linux desktop da rendere la cosa remunerativa, qualcuno
   scriverà un attacco _anche_ per questa caratteristica di sudo, a naso
   all'interno di una di quelle azioni che puntano a colpire quante più
   macchine possibili in modo da riuscire alla fin fine a colpire
   quella/quelle che interessano in modo indiretto.
  Sai che non ho capito perché dici che sudo è più pericoloso di un su -c? 

Perché di default sudo fa il caching delle credenziali: con la
configurazione di default, per alcuni minuti sudo non chiede
nuovamente l'autenticazione (su -c non lo fa mai).

La cache delle credenziali non è di per se negativa, meglio usare 3
sudo verso programmi binari che far eseguire tutto uno script con l'id
0:0 (parlo dell'id utente), sarebbe meglio avere un'opzione per dire
da qui tieni le credenziali in cache e oltre a quella già presente
annulla la cache delle credenziali in modo da controllare il campo
di esistenza della transazione.

A questo aggiungi che la configurazione  di default di Debian e Ubuntu
prevede che il primo utente creato compaia in /etc/sudoers come primo
ALL=(ALL) ALL, in  pratica fa diventare sudo una copia  di su che non
richiede di conoscere la password di root.

Terzo punto (non tecnico): la gente tende ad usare il proprio account
con meno consapevolezza per la sicurezza rispetto ad un account
amministrativo anche quando si fa delle pare nel momento in cui usa
un account amministrativo.

  A me sembra che il problema principale sia che bisogna stare molto 
  attenti ad eseguire programmi da root sia che essi siano eseguiti 
  utilizzando sudo che utilizzando direttamente l'utente root.

Ottima cosa che tu abbia la consapevolezza di ciò.

Ma ci hai mai pensato che è il tuo il più usato account amministrativo
e che quindi lo devi difendere con tenacia pari a quella che usi per
proteggere l'account di root? Tu si probabilmente, ma appartieni ad
una minoranza illuminata.

Se invece usi il tuo account con liberalità cominciano a presentarsi
problemi potenziali.

Beninteso,  sarebbe  questa la  forza  di  GNU/Linux contro  i  virus,
permettere ad un  utente di essere compromesso  senza compromettere il
sistema.

Ma il primo utente creato può usare sudo con qualsiasi comando.
E le sue credenziali rimangono valide per un certo periodo di tempo.

Supponiamo adesso che ci sia una base sufficientemente ampia di utenti
Ubuntu/Debian/Fedora (hanno tutte lo stesso comportamento con sudo) da
rendere economicamente profittevole fare un piccolo cavallo di troia
che si metta in attesa del momento in cui vede che la cache delle
credenziali sia attiva per poi iniettare codice malevolo sfruttando
sudo e la configurazione 'utente ALL=(ALL)ALL'.

Abbiamo un sistema che permette col tempo di crearsi una base di
macchine compromesse utili per vari scopi, dalle attività con reddito
immediato (le botnet) a cose un po' più fetenti e di ampio respiro.

Che so, infettare abbastanza macchine via rete, dispositivi rimovibili
come le pennette USB e, perché no, il device audio (ci sono già
malaware che usano gli ultrasuoni per comunicare a breve raggio)
colpendo indiscriminatamente tutte le macchine possibili fintanto che
se ne trova una con le caratteristiche che la fanno riconoscere come
bersaglio principale.

Fantascienza? Utopia? Paranoia? No. Attacco già avvenuto ai danni
dell'Iran, dove sono riusciti a metter fuori uso molte centrifughe per
la raffinazione dei materiali radioattivi con un programma chiamato
stuxnet.

Ergo, visto che i creatori di malaware comunque sono bravi, almeno non
facciamogli trovare la pappa pronta ma facciamoli sudare quanto più
possibile.

  IMHO invece è molto più pericoloso avere l'abitudine ad entrare come 
  root per fare attività amministrative così come è molto più 
  intrinsecamente insicuro un sistema di cui un potenziale cracker conosce 
  già il nome utente dell'utente con i privilegi più elevati...

Falsa   credenza.   C'era  chi   cambiava   il   nome  degli   account
amministrativi sentendosi  più sicuro.  Costa molto di  più indovinare
una password che aggirarla, e se  riesco a sniffare la password riesco
pure a sniffare l'username per cui viene usata...

In compenso, controllare che grep 0:0 /etc/passwd dia un solo
risultato non è così paranoico :)

Per la cronaca: non sono un esperto di sicurezza o un black hat,
ho ritenuto più utile fare altre cose coi computer. 

Ma una ventina di  anni fa ho avuto la mia dose  di divertimento ed ho
imparato a pensare male...

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian

Warning: 

Re: gruppi di default in debian jessie

2013-12-13 Per discussione Gollum1
Il 13 dicembre 2013 09:59, Piviul piv...@riminilug.it ha scritto:
 sa...@eng.it scrisse in data 12/12/2013 14:05:

 Usare un editor e /etc/groups pareva poco figo...

 l'ho sempre fatto andando a metter mano a /etc/group ma mi chiedevo: se
 esistono certi strumenti avrà un senso e sto cercando di usarli ed in
 effetti mi è stato utile:

 sudo usermod -a -G dialout,cdrom,floppy,audio,video,plugdev,netdev

 molto più comodo che aprire il file etc no?


perché... il  molto più semplice e sicuro:

sudo adduser utente gruppo

pare male?


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cantvqs8i0j1+zzwvvookovqcfotdphbcftsafyjcaz_gbx3...@mail.gmail.com



Re: gruppi di default in debian jessie

2013-12-13 Per discussione Piviul

Gian Uberto Lauri scrisse in data 13/12/2013 11:54:

Perché di default sudo fa il caching delle credenziali: con la
configurazione di default, per alcuni minuti sudo non chiede
nuovamente l'autenticazione (su -c non lo fa mai).
sai che ho letto la tua mail 2 o 3 volte ma non sono riuscito a capire 
dove sia il problema di sudo? Ho capito che riguarda la cache ma poi...



La cache delle credenziali non è di per se negativa, meglio usare 3
sudo verso programmi binari che far eseguire tutto uno script con l'id
0:0 (parlo dell'id utente), sarebbe meglio avere un'opzione per dire
da qui tieni le credenziali in cache e oltre a quella già presente
annulla la cache delle credenziali in modo da controllare il campo
di esistenza della transazione.

A questo aggiungi che la configurazione  di default di Debian e Ubuntu
prevede che il primo utente creato compaia in /etc/sudoers come primo
ALL=(ALL) ALL, in  pratica fa diventare sudo una copia  di su che non
richiede di conoscere la password di root.
secondo la tua visione direi che è peggio di così: ogni volta che crei 
un account di tipo amministrativo viene inserito nel gruppo sudo (per 
debian, admin per ubuntu) che ha appunto i privilegi di cui parli. 
Questo per dire che non solo il primo account ma ogni account di tipo 
amministrativo ha quei privilegi.



[...]
fare un piccolo cavallo di troia
che si metta in attesa del momento in cui vede che la cache delle
credenziali sia attiva per poi iniettare codice malevolo sfruttando
sudo e la configurazione 'utente ALL=(ALL)ALL'.
parli di gksudo o di sudo? AFAIK la cache delle credenziali di sudo può 
essere utilizzata soltanto dal terminale dalla quale viene usata... 
direi che è molto difficile per il cavallo di troia diventare figlio del 
terminale in cui hai inserito il comando sudo... per quanto riguarda 
gksudo invece mi sembra che non abbia affatto cache delle credenziali o 
mi sbaglio?


Ancora non mi hai convinto ma se insiti forse... ;)

Piviul


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52aaf3e4.8020...@riminilug.it



Re: gruppi di default in debian jessie

2013-12-13 Per discussione Gian Uberto Lauri
Piviul writes:
  Gian Uberto Lauri scrisse in data 13/12/2013 11:54:
   Perché di default sudo fa il caching delle credenziali: con la
   configurazione di default, per alcuni minuti sudo non chiede
   nuovamente l'autenticazione (su -c non lo fa mai).
  sai che ho letto la tua mail 2 o 3 volte ma non sono riuscito a capire 
  dove sia il problema di sudo? Ho capito che riguarda la cache ma poi...
   [...]

Provo ad indicartelo con una scala temporale con un esempio rozzo
senza ipotizzare come una cosa viene fatta.

1 - l'attaccante riesce a far eseguire il cavallo di troia.

2 - il cavallo di troia piazza l'imboscata

3 - L'imboscata si pone in attesa, diciamo che riesce a prendere il
controllo dello stdin e stdout della shell, ma non si mette a fare
logging (per non creare tracce della sua presenza). Fa passare
tutto l'input dell'utente e si preoccupa di non fare vedere
all'utente quello che non deve vedere.

4 - periodicamente prova a lanciare - ad esempio - sudo ls e a
vedere se ottiene una richiesta di prompt, nel qual caso manda un
carattere di terminazione al sudo che ha lanciato e nasconde
l'output all'utente; se invece si ha un risultato positivo grazie
al fatto che l'utente ha usato sudo e le credenziali sono in
cache, allora può dare il via all'invasione avendo la
possibilità di agire con l'id 0:0 .

Questo non è un attacco in grado di dare risultati immediati. Richiede
molta pazienza ed un numero sufficientemente elevato di vittime (per
ottenere in parallelo quello che è lungo ottenere in serie).

Esattamente come stuxnet. Avendo a disposizione l'immensa base di
untenti di sistemi Windows hanno lanciato l'attacco. Questo ha
cominciato a diffondersi a destra ed a sinistra (usando exploit
acquistati al mercato nero - a qanto pare) fintanto che un giorno,
passando chissà quante macchine e chiavette USB, una copia di stuxnet
-delle migliaia e migliaia attive - ha raggiunto una macchina
bersaglio e ha fatto il suo dovere.

   fare un piccolo cavallo di troia
   che si metta in attesa del momento in cui vede che la cache delle
   credenziali sia attiva per poi iniettare codice malevolo sfruttando
   sudo e la configurazione 'utente ALL=(ALL)ALL'.
  AFAIK la cache delle credenziali di sudo può 
  essere utilizzata soltanto dal terminale dalla quale viene usata... 
  direi che è molto difficile per il cavallo di troia diventare figlio del 
  terminale in cui hai inserito il comando sudo

Le tue informazioni non sono errate e scrivere l'attaccante in modo
corretto non è facile. Per questo ho parlato di una larga fascia di
utenti: questi sono attacchi che richiedono risorse per essere
sviluppati e devono quindi generare un ritorno economico che puoi
ottenere solo se hai una grande quantità di bersagli.

Peraltro un paio di ideuzze le ho. Tutto starebbe a saperle confezionare
bene: quando ancora gli ATT 3B2 erano una macchina abbastanza recente
un mio amico riuscì ad ottenere una shell setuid col mio user
semplicemente facendomi credere di aver trovato quello che cercavo.

Spero di essere riuscito a spiegarmi meglio.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21163.2381.646174.36...@mail.eng.it



Re: gruppi di default in debian jessie

2013-12-13 Per discussione Federico Di Gregorio
On 13/12/2013 14:19, Gian Uberto Lauri wrote:
 Piviul writes:
   Gian Uberto Lauri scrisse in data 13/12/2013 11:54:
Perché di default sudo fa il caching delle credenziali: con la
configurazione di default, per alcuni minuti sudo non chiede
nuovamente l'autenticazione (su -c non lo fa mai).
   sai che ho letto la tua mail 2 o 3 volte ma non sono riuscito a capire 
   dove sia il problema di sudo? Ho capito che riguarda la cache ma poi...
[...]
 
 Provo ad indicartelo con una scala temporale con un esempio rozzo
 senza ipotizzare come una cosa viene fatta.
 
 1 - l'attaccante riesce a far eseguire il cavallo di troia.
[snip]

Il problema non è tanto sudo quanto il fatto di convincere un utente con
permessi amministrativi ad eseguire il cavallo di troia come se fosse un
comando normale. Il tuo esempio funziona anche con su (invece di sudo)
con la semplice differenza che il cavallo di troia aspetta il comando
su, falsifica il prompt, ti ruba la password, e via...

Questo è il motivo per cui se si accede al sistema con un utente sudato
o che farà su in una shell bisogna sempre:

1) NON avere . in PATH
2) Avere in PATH solo directory che non possano venire scritte dal mondo
3) In qualsiasi caso, prima di fare ./ciccia/puccia/salva_il_mondo
controllare con molta attenzione che quel comando salvi DAVVERO il mondo
e non faccia altro.

federico

-- 
Federico Di Gregorio federico.digrego...@dndg.it
Di Nunzio  Di Gregorio srl   http://dndg.it
 E tu usa il prefisso corretto Re: non R:, questa è una ML seria.
-- cosmos, su debian-italian


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ab2e16.5080...@dndg.it



OT - cerco CPU

2013-12-13 Per discussione Felix

Un saluto a tutti,

Come da oggetto sono alla ricerca di una CPU usata (purchè non 
sfiancata da overclock) tipo Intel q6600 o q9550


Devono assolutamente supportare questa istruzione: Intel ® 
Virtualization Technology (VT-x) ‡
e se possibile anche quest'altra: Intel® Virtualization Technology for 
Directed I/O (VT-d) ‡


Ovviamente potete tranquillamente contattarmi in privato

Felice

--
decette 'o pappece vicin'a noce... ramm'o tiempo, ca te spertoso...


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ab3b06.2020...@infinito.it



Re: gruppi di default in debian jessie

2013-12-13 Per discussione Gian Uberto Lauri
Federico Di Gregorio writes:

  Il problema non è tanto sudo quanto il fatto di convincere un utente con
  permessi amministrativi ad eseguire il cavallo di troia come se fosse un
  comando normale.

Non è così difficile come credi tu.

  Il tuo esempio funziona anche con su (invece di sudo)
  con la semplice differenza che il cavallo di troia aspetta il comando
  su, falsifica il prompt, ti ruba la password, e via...

Vero, ma con sudo è stateless e non interferisce con i comandi
dell'utente, ne aggiunge qualcuno in più. Ed era un esempio del menga.
Mi aspetto qualcosa di più raffinato dal vero attacco.

  Questo è il motivo per cui se si accede al sistema con un utente
  sudato

L'utente sudato rischia la scossa, il sudore è una soluzione salina...

:)

  2) Avere in PATH solo directory che non possano venire scritte dal
  mondo

Meno se ne hanno e meglio è.

  3) In qualsiasi caso, prima di fare ./ciccia/puccia/salva_il_mondo
  controllare con molta attenzione che quel comando salvi DAVVERO il mondo
  e non faccia altro.

Quanti hanno le competenze per farlo?

Come ho  detto, questi  sono attacchi che  non credo  sarà conveniente
fare  fintanto che  non  ci  sarà una  massa  critica  di utenti  poco
preparati.

E comunque può capitare anche a quelli preparati di venire aggirati.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21163.16434.222490.153...@mail.eng.it



Re: gruppi di default in debian jessie

2013-12-13 Per discussione Davide Prina

On 13/12/2013 11:54, Gian Uberto Lauri wrote:

Che so, infettare abbastanza macchine via rete, dispositivi rimovibili
come le pennette USB e, perché no, il device audio (ci sono già
malaware che usano gli ultrasuoni per comunicare a breve raggio)
colpendo indiscriminatamente tutte le macchine possibili fintanto che
se ne trova una con le caratteristiche che la fanno riconoscere come
bersaglio principale.


dico qualcosa solo su questo punto.

Il virus che usava lo speaker per infettare qualsiasi macchina con 
qualsiasi sistema operativo era una bufala.


A livello teorico (mi sembra che sia stato dimostrato dopo l'uscita 
della bufala) è possibile far comunicare due PC tramite speaker e usando 
suoni esterni alla fascia udibile da un essere umano, ma:

1) il PC, oltre che lo speaker deve essere dotato di microfono
2) entrambi i PC devono avere microfono e speaker acceso e attivo
3) il microfono deve essere configurato correttamente per non tagliare 
o introdurre rumori che rendano impossibile interpretare il messaggio 
spedito... e deve essere in grado di ascoltare le frequenze emesse
4) nella stanza non ci deve essere un rumore che si sovrappone alla 
frequenza usata

5) i PC non devono essere troppo lontani
6) i due PC devono essere preventivamente infettati dall'ipotetico virus 
che poi usa tale mezzo di comunicazione


bastano queste considerazioni che ho scritto di getto per far capire che 
la probabilità di successo tende a zero.


Anche perché se è vero il punto 6 perché dovrebbe l'attaccante sprecare 
così tante risorse e prendersi così tanti rischi per far comunicare due 
PC che ha già conquistato?
Se il punto 6 non è vero, allora la trasmissione del messaggio non può 
avvenire.


Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Client di posta: http://www.mozilla.org/products/thunderbird
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ab6b5f.2050...@gmail.com



cerco auto

2013-12-13 Per discussione ritiroautogratis
SALvE, hai necessità di liberarti di auto o furgone inutilizzati? Non esitare a 
chiamarmi,ritiro con passaggio immediato a mio carico.Chiedere di Antonio 
cell.324-7474742



[RFR] po-debconf://nsd/it.po

2013-12-13 Per discussione Beatrice Torracca
Ciao a tutti,

questo scade il 27 dicembre. sono solo 3 messaggi.

grazie in anticipo per le revisioni,

beatrice


# Italian translation of nsd debconf messages.
# Copyright (C) 2013, nsd package copyright holder
# This file is distributed under the same license as the nsd package.
# Beatrice Torracca beatri...@libero.it, 2013.
msgid 
msgstr 
Project-Id-Version: nsd\n
Report-Msgid-Bugs-To: n...@packages.debian.org\n
POT-Creation-Date: 2013-12-13 06:20+0100\n
PO-Revision-Date: 2013-12-13 18:44+0200\n
Last-Translator: Beatrice Torracca beatri...@libero.it\n
Language-Team: Italian debian-l10n-italian@lists.debian.org\n
Language: it\n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
Content-Transfer-Encoding: 8bit\n
Plural-Forms: nplurals=2; plural=(n != 1);\n
X-Generator: Virtaal 0.7.1\n

#. Type: note
#. Description
#: ../templates:2001
msgid Configuration directory for NSD changed
msgstr La directory di configurazione di NSD è cambiata

#. Type: note
#. Description
#: ../templates:2001
msgid 
NSD 4 has changed the configuration directory from /etc/nsd3 to /etc/nsd.
msgstr 
NSD 4 ha cambiato la directory di configurazione da /etc/nsd3 a /etc/nsd.

#. Type: note
#. Description
#: ../templates:2001
msgid 
The old configuration file (/etc/nsd3/nsd.conf) will be moved to /etc/nsd/
nsd.conf. However, other configuration files in /etc/nsd3 will not be moved, 
so you need to check and move your configuration snippets and zone files 
yourself.
msgstr 
Il vecchio file di configurazione (/etc/nsd3/nsd.conf) verrà spostato in 
/etc/nsd/nsd.conf. Tuttavia, altri file di configurazione in /etc/nsd3 non 
verranno spostati, perciò è necessario controllare e spostare a mano i 
propri frammenti di configurazione e file delle zone.


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-l10n-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-l10n-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131213175059.gd3...@aebea.it.invalid



Pagine web da aggiornare

2013-12-13 Per discussione Debian WWW translation watch
Buongiorno,
questo messaggio automatico è inviato in quanto sei responsabile
della traduzione in italiano di alcune pagine del sito web Debian.
Hai richiesto di inviare le seguenti informazioni:
  summary: settimanale
  logs: mai
  diff: mai
  tdiff: mai
  file: mai

Puoi cambiare:
  - la frequenza dei messaggi (mai, quotidiana, settimanale,
mensile) ;
  - le informazioni che vuoi ricevere:
* il riassunto dei file da aggiornare
* i messaggi del log tra la versione aggiornata e l'ultima tradotta
* le differenza tra la versione aggiornata e l'ultima tradotta
* i file completi da aggiornare
  - il tuo indirizzo di posta elettronica

Per qualsiasi domanda su questo messaggio, invia un email alla
lista debian-l10n-italian@lists.debian.org
NeedToUpdate italian/events/admin.wml from revision 1.7 to revision 1.11 
(maintainer Daniele Cortesi)
NeedToUpdate italian/events/checklist.wml from revision 1.19 to revision 1.20 
(maintainer Daniele Cortesi)
NeedToUpdate italian/misc/laptops/index.wml from revision 1.13 to revision 1.14 
(maintainer Emanuele Rocca)


Pagine web da aggiornare

2013-12-13 Per discussione Debian WWW translation watch
Buongiorno,
questo messaggio automatico è inviato in quanto sei responsabile
della traduzione in italiano di alcune pagine del sito web Debian.
Hai richiesto di inviare le seguenti informazioni:
  summary: settimanale
  logs: mai
  diff: mai
  tdiff: mai
  file: mai

Puoi cambiare:
  - la frequenza dei messaggi (mai, quotidiana, settimanale,
mensile) ;
  - le informazioni che vuoi ricevere:
* il riassunto dei file da aggiornare
* i messaggi del log tra la versione aggiornata e l'ultima tradotta
* le differenza tra la versione aggiornata e l'ultima tradotta
* i file completi da aggiornare
  - il tuo indirizzo di posta elettronica

Per qualsiasi domanda su questo messaggio, invia un email alla
lista debian-l10n-italian@lists.debian.org
NeedToUpdate italian/Bugs/index.wml from revision 1.79 to revision 1.84 
(maintainer Giuseppe Sacco) [out of date by 5 revisions]


[BTS#732078] po-debconf://neutron/it.po

2013-12-13 Per discussione Beatrice Torracca
Ciao,

ho inviato questa oggi.

grazie,

beatrice


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-l10n-italian-requ...@lists.debian.org con oggetto unsubscribe. Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-l10n-italian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131213195336.ga4...@aebea.it.invalid