domenica 24 marzo 2013

Ridurre il consumo energetico di Ubuntu su HP Pavilion G6-1231sl - Installazione driver ATI Radeon HD 6470m

Inizio col dire che questo non è il solito post che descrive come installare i driver ATI su Ubuntu, no perché sia migliore o altro, ma semplicemente perché affronta un problema che non viene discusso molto: l'incompatibilità del kernel linux 3.5 coi driver ATI Catalyst (nel momento in cui sto scrivendo v13.1) per alcuni modelli di schede video. Questa incompatibilità si manifesta in vari modi; molto comune è il riavvio in Safe Graphics Mode, in cui non è possibile nemmeno muovere il puntatore del mouse per selezionare le varie opzioni. La risoluzione di questo problema porta ad un notevole aumento della durata della batteria, in quanto, finalmente, il modulo ibrido grafico viene gestito a dovere.

L'hardware interessato è quello nel titolo, ma non è detto che il metodo seguente non vada bene anche in altri casi simili. Vediamo subito come ovviare:

Guida in parole (breve):

  1. Installare il kernel 3.2.0-39
  2. Installare in driver Catalyst che trovate QUI, o comunque scaricate gli ultimi disponibili da QUI.
  3. Scompattare il file .run e, una volta dati i permessi di esecuzione, costruire i pacchetti per la vostra  distro.
  4. Installare i pacchetti appena creati (Se vi sono problemi assicurarsi di aver risolto tutte le dipendenze).
  5. Configuriamo Xorg affinchè utilizzi i driver appena installati.
  6. Riavviare.
Guida in comandi (con permessi di root):

apt-get install linux-image-3.2.0-39-generic linux-headers-3.2.0-39-generic linux-headers-3.2.0-39

Riavviare e selezionare da Grub il kernel appena installato. Download dei driver come detto sopra e posizioniamoci da terminale nella cartella dove li abbiamo salvati; se ad esempio è in HOME, allora:

cd /home/michele
unzip amd-driver-installer-catalyst-13.1-linux-x86.x86_64.zip
chmod +x amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run

Preciso che se la versione di Ubuntu non è la 12.04, "Ubuntu/precise" va sostituito col nome della versione di Ubuntu installata.

sh amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run --buildpkg Ubuntu/precise
dpkg -i fglrx*.deb

Per configurare Xorg diamo:
aticonfig --initial -f
reboot now

Dovremmo capire che tutto è andato bene innanzi tutto dal fatto che xserver si avvia correttamente, cioè riusciamo a vedere l'interfaccia grafica correttamente; possiamo inoltre controllare che i driver utilizzati siano quelli corretti digitando:

lshw -C video | grep driver

e dovremmo ottenere:

configuration: driver=fglrx_pci latency=0
configuration: driver=i915 latency=0

dove nel mio caso si nota la presenza di due schede grafiche (soluzione ibrida) la prima delle quali usa i driver fglrx, cioè quelli appena installati. Se non fosse così chiedete aiuto :P 
Ultima cosa, possiamo configurare la scheda grafica avviando il software AMD Catalyst Control Centre (anche da terminale con sudo amdcccle).



 


sabato 6 febbraio 2010

Imparare il linguaggio MIPS con l'Emulatore MARS

Sarò breve. MARS (MIPS Assembler and Runtime Simulator) è un validissimo strumento per fare pratica nella programmazione su architetture MIPS (e molto altro ancora!). Il sito del progetto è:

http://courses.missouristate.edu/KenVollmar/MARS/

Per utilizzarlo su Ubuntu (io lo sto usando sul 9.04) ho installato OpenJDK Java 6 Runtime

sudo apt-get install openjdk-6-jre

(non ricordo se necessita di altri pacchetti, ma è facile installare la Java Runtime...esistono varie guide).

Scaricate quindi dal sito ufficiale il file "Mars.jar" e avviatelo cliccando col tasto destro e cliccando su "Apri con OpenJDK Java 6 Runtime"....e si aprirà la seguente interfaccia.

In (4) abbiamo la barra dei menu e degli strumenti; in (1) possiamo selezionare due schede: "Edit" e "Execute"...inizialmente posizioniamoci su "Edit", dove scriveremo il nostro codice MIPS; in (2) avremmo i messaggi che l'assemblatore ci comunicherà; in (3) c'è una comoda interfaccia che ci fa vedere in tempo reale il contenuto di ogni registro.


Passiamo nella scheda "Execute" (5):


In (6) abbiamo i "Text segment" ovvero la traduzione del linguaggio da noi scritto (magari corredato da pseudoistruzioni) che viene tradotto in linguaggio assembler e poi macchina; in (8) vi è una finestra che ci da informazioni relative alle etichette utilizzate; in (7) vi la finestra "Data segment", che ci permette (selezionaldoli dal menu a tendina sottostante) di visualizzare il contenuto della memoria, dello stack, dell'heap, ecc...
Naturalmente questa è una descrizione del programma molto breve e poco specifica. Si rimanda all'Help e al sito ufficiale per una conoscenza appropriata di tutte le funzionalità di MARS.
Quello che mi interessava realizzare in questo articolo è un Tutorial di primo impatto (in perfetto stile di Linux Beginner).
Quello che vogliamo realizzare è una semplice procedura MIPS, che in C ha questa forma:













Questa è una semplice funzione C che implementa il prodotto scalare di due vettori puntati rispettivamente dai puntatori *a e *b di dimensione "dim". Alla variabile P, inizializzata a 0, tramite un ciclo for, viene addizionato iterativamente il prodotto delle componenti dei vettori, ottenendo così alla fine il prodotto scalare. Vediamo come ottenere lo stesso risultato in linguaggio MIPS (naturalmente la versione che segue è in alcune cose diversa da quella che produrrebbe un compilatore C, ma certamente risulta più scolastica):

la fuzione ha 3 parametri, quindi sappiamo che alla procedura verranno passati gli indirizzi di memoria di questi 3 parametri nei registri $a0, $a1, $a2. Per poter verificare il funzionamento corretto del nostro codice dobbiamo in qualche modo caricare la memoria con i valori che un eventuale main scritto in C scriverebbe in memoria prima della chiamata della funzione "prod_scal". Faremo questo andando in nella scheda "Edit" di (5) e scrivendo in fondo alla text box:

.data
veta: .word 1,2,1,2
vetb: .word 1,2,3,4
dim: .word 4


Abbiamo indicato a MARS l'esistenza di 3 elementi : vettore a e vettore b di 4 elementi, dim un elemento pari a 4 (dimensione dei vettori).
Ora partendo da sopra possiamo cominciare a scrivere il programma:

.text
.gobl main

main: la $a0,veta
la $a1,vetb
la $a2,dim


Con queste istruzioni abbiamo inizializzato il main e con le istruzioni "la" abbiamo caricato i registri $a0, $a1, $a2 con gli indirizzi di memoria degli operandi passati alla funzione, quindi ora la memoria contiene i dati come se una funzione C gli avesse caricati in precedenza e possiamo verificare questo nella finestra "Data segment" (7). Possiamo ora scrivere il nostro programma. Non spiego come realizzarlo in dettaglio, ma mi limito a riportarne la soluzione funzionante da me realizzata:

.text
.globl main
main: la $a0,veta
la $a1,vetb
la $a2,dim

add $fp,$sp,$zero #pongo frame point pari allo stack point
addi $sp,$sp,-20 #faccio posto a una parola per mem il vecchio valore di $s0
sw $s0,16($sp) #backup di $s0
sw $s1,12($sp) #backup di $s1
sw $s2,8($sp) #backup di $s2
sw $s3,4($sp) #backup di $s3
sw $s4,0($sp) #backup di $s4

add $s0,$zero,$zero #s0=0, considero s0 come P
add $t0,$zero,$zero #t0=0, considero t0 come i
lw $s4,($a2) #$s4=a2 (s4 acquisisce il valore di dim)

L1: sll $t4,$t0,2 #t4= t0*4 (i=i*4) per considerare un'incremento di un intera parola

add $t2,$a0,$t4 #$t2=$a0(base)+$t4(shift) (=$a[i])
lw $s1,($t2) #$s1=a[i]

add $t2,$a1,$t4 #s2=a1+t0 (=b[i])
lw $s2,($t2) #$s2=b[i]

mult $s1,$s2 #Hi,Lo=$s1*$s2 (=a[i]*b[i])
mflo $s3

add $s0,$s0,$s3 #s0=s0+s3 (P=P+a[i]*b[i]

addi $t0,$t0,1 #t0=t0+1

slt $t1,$t0,$s4 #t1=1 se t0


Per poter controllare il corretto funzionamento del programma basta dare il comando di "assemble" con F3, se tutto va a buon fine in fase di assemblaggio (lo verifichiamo nella finestra (2)) possiamo scegliere se far girare il programma per intero con F5 o se controllare lo svolgimento di ogni singola istruzione con F7 (molto utile!). Detto questo, non resta che provare. Alla prossima!

martedì 28 ottobre 2008

REMOTEJOY Giochiamo con la PSP tramite lo schermo del PC con Ubuntu

IMPORTANTE!!!
La guida aveva degli errori. E' stata aggiornata e testata in data 16 novembre 2008. Ora funziona tutto bene.


Oggi parliamo ancora di una coppia che a me piace molto: PSP e Ubuntu. Infatti sembra che questi due si vogliano sempre più bene in quanto è spettacolare vedere come una PSP possa essere sfruttata al massimo grazie al S.O. che tanto amiamo. Oggi vi parlo di una cosa di cui ho scoperto l'esistenza quattro giorni fa e che ho risolto con un po' di difficoltà...Parlo di REMOTE JOY, ovvero un insieme di tools che ci permettono di trasferire le immagini di gioco sullo schermo del nostro PC. Non servirà più quindi comprarsi il cavo composite per collegare la PSP alla TV perchè l'utilizzo è analogo. Non dilunghiamoci troppo e partiamo con la guida all'installazione:

Cosa ci serve?
(i requisiti non sono assoluti....potrebbe funzionare anche con altri tipi di firmware o con un'altra versione di ubuntu)
  • Ubuntu 8.04.1
  • PSP Slim&Lite con Custom Firmware 3.90 m33
  • software (ci pensiamo dopo!)
FASE 1

Creiamo una cartella nella nostra Home (esempio "pspdev");

cd /home/*nome_utente
mkdir pspdev


Spostiamoci nel suo interno:

cd pspdev

Installiamo subversion

sudo apt-get install subversion

scarichiamo da SVN il software "psptoolchain"

svn co svn://svn.ps2dev.org/psp/trunk/psptoolchain

spostiamoci nella cartella "psptoolchain"

cd psptoolchain

Ora mandiamo dei comandi in sequenza (dopo l'ultimo comando bisogna aspettare molto...io ho aspettato 1 ora e mezza...quindi potete uscire e al vostro ritorno "sarà tutto finito!")

sudo apt-get install build-essential autoconf automake bison flex \
libncurses5-dev libreadline-dev libusb-dev texinfo libgmp3-dev libmpfr-dev libsdl1.2-dev

gedit ~/.bashrc


Si apre un file. Alla fine di questo file aggingiamo le seguenti righe:
## Add these lines to the end of the file.
export PSPDEV="/usr/local/pspdev"
export PSPSDK="$PSPDEV/psp/sdk"
export PATH="$PATH:$PSPDEV/bin:$PSPSDK/bin"

Salviamo e chiudiamo il file e mandiamo i seguenti comandi:
source ~/.bashrc

e dopo compiliamo psptoolchain (e prepariamoci ad aspettare molto)
sudo ./toolchain-sudo.sh

FASE 2

ritorniamo nella directory pspdev:

cd /home/*nome_utente/pspdev

scarichiamo via SVN "psplink"

svn checkout svn://svn.ps2dev.org/psp/trunk/psplinkusb

entriamo della cartella "psplinkusb"

cd psplinkusb
make -f Makefile.oe release

Ci sarà una cartella chiamate release_oe oltre che altre nuove cartelle.
Ora accendiamo la PSP e colleghiamola normalmente via USB.
Creiamo due nuove cartelle in nella directory PSP/GAME150 chiamate psplink e %psplink
e ora copiamo un file in quest'ultima (digito il comando seguente però attenti che i percorsi delle directory siano corrette):

cp /home/*nome_utente/pspdev/psplinkusb/release_oe/psplink/EBOOT.PBP /media/disk/PSP/GAME150/%psplink

Ora copiamo tutti i file presenti in release_oe/psplink in PSP/GAME150/psplink (per il comando vale sempre lo stesso discorso della correttezza dei percorsi)

cp /home/*nome_utente/pspdev/psplinkusb/release_oe/psplink/* /media/disk/PSP/GAME150/psplink

Compiliamo remotejoy:

cd /home/*nome_utente/pspdev/psplinkusb/tools/remotejoy
make

Nella directory principale della PSP creiamo una cartella di nome joy
copiamo il file tools/remotejoy/remotejoy.psx nella dir joy appena creata

cp /home/*nome_utente/pspdev/psplinkusb/tools/remotejoy/remotejoy.prx /media/disk/joy

Tutte le seguenti istruzioni sono riferite a cartelle contenute in /home/*nome_utente/pspdev/psplinkusb

nella cartella pspsh dare un make
nella cartella usbhostfs_pc dare un make
nella cartella /tools/remotejoy/pcsdl dare un make
nella cartella usbhostfs_pc digitare sudo ./mod.sh

FASE 3

Facciamo riconoscere la nostra "periferica video" PSP a Ubuntu
Apriamo un terminale (chiamiamolo T1), spostiamoci nella cartella usbhostfs_pc e digitiamo

./usbhostfs_pc

Smontiamo la PSP (non vogliamo più che sia riconosciuta come una periferica di archiviazione dati) e sempre col cavo usb collegato dal menu giochi avviamo PSPLink
Se tutto è andato bene, in T1 apparirà Connected to Device e la PSP rimarrà ferma su uno schermo nero con una scritta bianca in alto.
In un altro terminale (T2) spostiamoci nella cartella pspsh e digitiamo

./pspsh

questo ci ha permesso di aprire una shell per inviare comandi alla psp (dovremmo avere un risultato del tipo host0> o simile). Se vogliamo possiamo anche vedere i comandi di questa shell digitando "help"

Finalmente apriamo la finestra in cui vedremo le immagini di gioco.
in un terzo terminale (T3) spostiamoci nella cartella tools/remotejoy/pcsdl e digitiamo

./remotejoy -d -c

Apparirà una finestra completamente nera...ciò significa che tutti i programmi stanno lavorando ma ancora non c'è connessione diretta. Provvediamo subito.
IMPORTANTE!!!
I comandi che seguono hanno avuto un comportamento diverso su due PSP diverse, soprattutto il secondo che in una diceva che il plugin non veniva caricato e nell'altra si....ma non preoccupatevi...alla fine ha funzionato con entrambe. Quindi spostiamoci in T2 (il terminale che comanda la PSP) e digitiamo:
reset vsh (se la PSP si riavvia totalmente ripetere tutta la FASE 3 e saltate solo questa istruzione)
ldstart flash0:/vsh/module/vshmain.prx
ldstart ms0:/joy/remotejoy.prx
Capiremo che tutto sta andando per il verso giusto se dopo l'ultima istruzione sulla schermata nera che abbiamo aperto col T3 apparirà la stessa scritta che vi è sullo schermo della PSP.

FASE 4
Da qui si possono prendere 2 strade diverse...vi dico però quello che l'autore di questi tool ha indicato e poi vi do un idea su come ho fatto io.
1° Metodo
(solo se non c'è già) creare nella directory principale della PSP una cartella di nome seplugins
(solo se non ci sono già) creiamo due file di testo vsh.txt e game.txt.
Aprire vsh.txt e game.txt e copiare all'interno quanto segue

ms0:/seplugins/usbhostfs.prx
ms0:/seplugins/psplink.prx
ms0:/seplugins/psplink_user.prx
ms0:/seplugins/remotejoy.prx


Ora dobbiamo copiare i plugin nella nostra PSP. Lo possiamo fare copiando i seguenti file nella cartella seplugins che abbiamo creato prima nella directory principale della PSP.
usbhostfs.prx è in /home/*nome_utente/pspdev/psplinkusb/usbhostfs/
psplink.prx è in /home/*nome_utente/pspdev/psplinkusb/psplink/
psplink_user.prx è in /home/*nome_utente/pspdev/psplinkusb/psplink_user/
remotejoy.prx è in /home/*nome_utente/pspdev/psplinkusb/tools/remotejoy/

Smontiamo la nostra PSP e spegniamola tendendo il pulsante di spegnimento sollevato fino allo spegnimento vero e proprio. Riaccendiamola tenendo premuto il tasto R (della PSP!) e nel menu che compare andiamo nella sezione "Plugins" e abilitiamo i plugins

psplink.prx
remotejoy.prx


Torniamo indietro e premiamo esci...la PSP si riaccenderà.
Sul computer riapriamo il terminale T1 e T3 come fatto nella FASE 3 e riapparirà lo schermo nero....Avviate il vostro gioco preferito e, se è stato eseguito tutto in modo corretto, godetevi il vostro gioco a schermo intero sul notebook.
A proposito....per abilitare lo schermo intero premere F8.

2° metodo
Io invece di mettere tutti questi plugin a mano utilizzo il Coustom Firmware Extender (è facile reperirlo su internet) che contiene già i plugin per il remotejoy. Per attivarli e disattivarli basta utilizzare delle combinazioni di tasti. Questo anche per altre funzioni (cambio di frequenza CPU, luminosità dello schermo, ecc...). Inizialmente io utilizzavo il 1° metodo...ma avevo dei problemucci. Con questa soluzione ho risolto.

Se avete problemi, volete maggiori informazioni o qualche istruzione non è chiara non esitate a postare...Ciao uagliò!

Si ringrazia moltissimo l'autore del software Tyranid di PS2dev.org.



giovedì 14 agosto 2008

Virus, adware, spyware, trojan.....il miglior ANTIVIRUS è Gnu/Linux: definizioni, trattazioni, comportamenti, luoghi comuni

  • Perché non serve (quasi mai) un antivirus su GNU/Linux
Molti si chiedono se serva, o meno un antivirus su GNU/Linux. Voglio spiegare bene la questione, anche perché in rete si trovano notizie discordanti e spesso fasulle. I produttori di antivirus è già da qualche anno che predicano la nascita di virus su GNU/Linux, ma non se ne sono visti. E i motivi sono tecnici e cercherò di spiegarli. Prima di tutto, una definizione dei diversi tipi di virus, o meglio di “malware”.

  • Virus: un virus è un programma malevolo che usa un altro programma come veicolo di diffusione e replicazione, esattamente come fanno i virus biologici che usano le cellule per riprodursi. Un virus ha quindi bisogno di un altro programma da infettare.
  • Trojan: un trojan (cavallo di Troia) è un programma che fa credere all’utente di essere utile, mascherandosi da qualcos’altro. Ad esempio alcuni trojan appaiono inizialmente come dei codec per la riproduzione di contenuti multimediali.
  • Worm: un worm (verme) è un programma malevolo che può riprodursi senza bisogno di farsi veicolare da un altro programma.
  • Toolkit/Rootkit: un toolkit può essere malevolo o no. Con lo stesso termine infatti si indicano sia programmi utili (come le librerie GTK) sia programmi malevoli. In questo secondo caso ci si riferisce a librerie che vanno a sostituirsi o affiancarsi a quelle di sistema o di programmi per procurare danni, nascondendosi in modo da sfuggire all’attenzione dell’utente. Quando un toolkit coinvolge il kernel del sistema operativo (ad esempio come finto driver), si parla di rootkit. Di norma l’uso di questo malware è quello di installare una backdoor (”porta sul retro”) attraverso cui l’attaccante può entrare nel sistema colpito e prelevarne i dati o addirittura prenderne il controllo.
  • Wabbit: è un programma malevolo che non usa i servizi di rete o altri file o programmi per riprodursi. Un esempio è la fork bomb.
  • Altri tipi di malware: altri tipi di malware si distinguono più per lo scopo che per le modalità di azione e diffusione, di solito riconducibili alle categoria precedenti. Tra questi ricordiamo gli spyware (codice spia), gli adware (pubblicità indesiderate che compaiono sul desktop) e i keylogger, programmi che registrano l’attività dell’utente soprattutto al fine di scoprire le password e i numeri di carta di credito digitati. Inoltre la diffusione di formati di file che possono contenere codice anche se non sono programmi veri e propri (ad esempio i formati documenti che possono contenere macro o le pagine web che possono contenere javascript) ha portato alla nascita di macrovirus.
Bene, ma come agisce un malware?
Non è sufficiente che il malware entri a contatto con il sistema (ad esempio attraverso uno scambio di file, una e-mail o la visualizzazione di una pagina web), ma è necessario che entri in esecuzione. Difatti gli antivirus mettono i file infetti in “quarantena”, ossia in una cartella controllata dove non possono più agire. Quando il malware entra in contatto con il sistema deve presentarsi uno dei seguenti casi affinché esso possa entrare in esecuzione:
  • una azione volontaria dell’utente mette in esecuzione il malware: questo è il caso dei trojan e di molti worm;
  • il malware entra in esecuzione anche in mancanza di una azione volontaria: in tal caso è stata sfruttata una vulnerabilità.
Una vulnerabilità è una falla di un programma che produce un comportamento non previsto dal programmatore o considerato (a torto) non pericoloso. Ed ora, ecco perché un antivirus è quasi sempre inutile.

  • I permessi
I sistemi operativi di tipo Unix hanno una rigida e complessa gestione dei permessi. Ogni utente, e quindi ogni programmi eseguito da tale utente, può fare con un file solo ciò che è consentito in base ai permessi che egli possiede. Si consulti la guida del comando sudo per approfondire la logica dei permessi. Questo implica alcune conseguenze:
  • i programmi utente sono separati da quelli di amministrazione;
  • I programmi utente possono agire solo sulla home di quell’utente, non sui file di amministratore né su quelli di altri utenti;
  • i programmi per essere eseguiti devono avere lo speciale attributo di eseguibili.
In base a ciò, un malware che agisce a livello utente non può creare danni al sistema, ma può al limite cancellare o infettare solo i file appartenenti a quel determinato utente. Di norma nessun sistema di tipo Unix installa i programmi (neppure i programmi utente) nella directory home dell’utente. Ciò, unito alla suddetta gestione dei permessi, mette al riparo il sistema dall’infezione da parte dei tradizionali virus che non trovano eseguibili a cui “attaccarsi”. I worm non possono agire perché per farlo devono avere i permessi di esecuzione. I rootkit non possono installarsi autonomamente in quanto caricare un modulo/driver nel kernel richiede i permessi di amministrazione. Ciò a meno di vulnerabilità del sistema. Infatti una vulnerabilità grave può permettere al malware di superare tali restrizioni e acquisire i permessi di amministratore. Ciò è già accaduto per i sistemi di tipo Unix. Il primo worm della storia è nato proprio per Unix sfruttando una vulnerabilità.

  • Essere open source
Un software open source, e quindi GNU/Linux, ha la caratteristica di avere il codice sorgente liberamente consultabile e modificabile. Questo pparentemente potrebbe rendere meno sicuro il sistema. In teoria, se tutti conoscono il codice sorgente, chiunque può scoprirne le vulnerabilità e quindi sfruttarle con fini fraudolenti. Nella pratica, però, si realizza l’esatto opposto: proprio perché tutti possono scoprire facilmente le vulnerabilità, esse possono venire tempestivamente corrette. Molte vulnerabilità vengono infatti corrette ancora prima che possano essere sfruttate a danno del sistema. Navigare sul Web con un browser open source è più sicuro che navigare con uno proprietario e usare una suite per l’ufficio open source è più sicuro che usarne una proprietaria.

  • Rafforziamo i permessi
Sono stati adottati vari meccanismi preventivi per rafforzare la sicurezza del sistema come:
  • l’uso di chiavi di autenticazione per il software e i repository che assicurano la provenienza originale e sicura degli stessi;
  • la necessità, quando si esegue un programma nella directory corrente, di anteporre il suo percorso ./ in modo tale che un programma che abbia lo stesso nome di un comando comunemente usato, non possa essere per sbaglio eseguito al posto di tale comando (questa semplice precauzione ha stroncato la diffusione di worm come ls);
  • ulteriori rafforzamenti del meccanismo dei permessi come SELinux (sviluppato dalle forze armate statunitensi) e AppArmor (sviluppato da Novell e presente in Ubuntu): tali sistemi creano i cosiddetti “contesti”: ad esempio una pagina html creata nella home dell’utente, anche se trasferita nella directory di Apache /var/www non funzionerà in quanto nata in un contesto differente; un programma presente nella directory utente non verrà eseguito se trasferito in una directory di sistema come /usr/bin/.

  • Unix e il malware
Per comprendere quanto i sistemi Unix siano sicuri è utile consultare alcune fonti:
  • la pagina di uno dei programmi più noti, apprezzati e premiati nella lotta al malware chkrootkit. Questa elenca solo una decina di malware (sia rootkit che worm) in oltre 10 anni di sviluppo del programma. Alcuni di questi sono worm ormai desueti come il citato ls, altri sono rootkit solo per alcuni sistemi Unix che quindi non coinvolgono gli altri sistemi della stessa famiglia (ad esempio un malware per Solaris non può agire su GNU/Linux o *BSD), altri ancora si riferiscono a determinate versioni del kernel di tali sistemi (infatti una volta corretta la vulnerabilità il malware è diventato innocuo). Sfogliando il changelog del programma si nota che i malware aggiunti annualmente per i sistemi Unix supportati dal programma sono dell’ordine di qualche unità;
  • la pagina sui virus per Linux nella documentazione internazionale di Ubuntu, nella quale si illustrano i pochi malware conosciuti per Linux, la maggior parte dei quali nei fatti risulta innocua (perché, per esempio, necessità dei permessi di amministratore). Nella realtà il concetto di virus è praticamente sconosciuto nei sistemi di tipo Unix essendo i pochi finora scoperti non in grado di diffondersi efficacemente, perché necessiterebbero di entrare fraudolentemente in possesso dei permessi di amministratore. Nella prossima puntata vedremo le eccezioni, ovvero quando è utile avere un antivirus.

  • Quando serve un antivirus su GNU/Linux
Abbiamo visto perché su GNU/Linux (ma lo stesso discorso potrebbe farsi per *bsd e altri sistemi di tipo Unix) un antivirus è sostanzialmente inutile. Riassumendo: su GNU/Linux non esistono virus e il restante malware è facilmente prevenibile (dedicherò la prossima “puntata” proprio a questo aspetto). Tuttavia vi sono situazioni particolari in cui l’uso di un antivirus
è necessario o, almeno, consigliabile, considerando sempre che gli antivirus per GNU/Linux sono in realtà antivirus contro il malware di Windows. Esaminiamole.

  • Il proprio sistema è un server di posta a cui si collegano client Windows. Ad esempio perché siete un provider. Be’, in questo caso vorreste che i vostri clienti stiano al riparo da brutte sorprese e i vostri clienti sono sicuramente anche tanti utenti Windows. Cosa c’è di meglio di un antivirus open source, quindi utilizzabile gratuitamente anche in ambito professionale e azendale? La soluzione in tal caso è ClamAV. ClamAV è tarato proprio per questo lavoro e lo fa egregiamente.
  • Condividete e scambiate file con utenti Windows e volete essere talmente ortesi da non procurare infezioni a tali utenti. Cerchiamo di essere buoni vicini, ma non è strettamente necessario avere un antivirus, in realtà. L’alternativa è utilizzare formati di scambio dati che non possano trasportare malware o che abbiano un rischio ridotto, come ad esempio .odf (formato di OpenOffice), .rtf e .txt per i testi;
  • Avete un dual-boot sul sistema ma non un antivirus su Windows (siete matti?) oppure l’antivirus è scaduto (Norton $$$) o troppo datato (il crack non ha funzionato...) oppure dovete usare un antivirus per ripulire la partizione dove risiede Windows senza avviarlo; in ogni caso è preferibile aggiornare l’antivirus di Windows; o eliminare Windows stesso.
  • Usate in modo spropositato Wine e programmi per Windows. Wine può infatti eseguire alcuni virus che possono potenzialmente danneggiare lo stesso Wine e la directory dell’utente. Be’, se dev’essere il più possibile compatibile, vi beccate anche i virus.
  • Virus e GNU/Linux: prendiamo un po’ di precauzioni intelligenti
Abbiamo visto perché su GNU/Linux non ci sono virus. E abbiamo visto i casi particolari in cui, comunque, può essere utile installare un antivirus. Ricordo la definizione di virus: un programma che si attacca ad un altro programma per riprodursi. Si può fare qualcosa del genere su GNU/Linux o in generale su un
sistema di tipo Unix. Sì, certo. Il problema è che muore lì. Senza permessi il virus non va da nessuna parte e rimane confinato. Fine della riproduzione.
Però non ci sono solo i virus...
Vero. Ad esempio ci sono anche i trojan. I trojan sono programmi che fanno finta di essere utili ma in realtà sono malevoli. Contro i trojan c’è poco da fare, anche se qualcosa si può fare: ad esempio i meccanismi di rafforzamento dei permessi che abbiamo già visto possono limitare l’azione di molti tipi di malware. Ma la vera difesa contro di essi, almeno nell’ambito desktop, non è un antivirus, né SELinux o Apparmor. La vera difesa è l’intelligenza dell’utente. Proviamo a vedere cosa possiamo fare per eliminare pressoché ogni tipo di problema, prendendo alcune semplici precauzioni.
La gran parte di esse consiste semplicemente nell’usare il sistema operativo come dovrebbe essere usato. Niente di più. Nessuno sforzo particolare, nessun programma che ruba cicli di clock preziosi per poter finire prima il ripping del DVD che stiamo trasferendo sul pc, nessun “terrore” ogni volta che succede qualcosa di strano.
Ecco una lista di buoni comportamenti:
  • Non installate programmi né date permessi di esecuzione ad un file né eseguitelo tramite il comando sh se non siete è certi della sua provenienza e affidabilità
Un giorno potrebbe capitarci un bel file .deb da installare, allegato ad una e-mail. Agli utenti Windows capita spesso, molti famosi malware erano dei file .exe che promettevano chissà cosa. La gente ha incominciato piano piano a capire che non è bene fidarsi. Noi utenti GNU/Linux ancora non abbiamo queste “fortune” ma pensateci: l’eeepc usa XandrOS, una distribuzione derivata da Debian. I .deb di XandrOS di solito funzionano anche su Debian, Ubuntu e altre distro simili. Un click e qualcuno può fregarci. - “Oddio, vado a prendere ClamAV!” - Fermo lì. Basta non clickare sulla prima cosa che capita, no? E’ più facile.
  • Preferite i repository che possiedono una chiave di autenticazione GPG
Avete presente quando aggiungete un repository e poi compare un errore tipo: W: Errore GPG: http://packages.medibuntu.org hardy Release: Le seguenti firme non sono state verificate perché la chiave pubblica non è disponibile
Ecco, questo accade perché medibuntu è autenticato da una chiave GPG (GNU Privacy Guard) che assicura all’utente che non ci stiamo sbagliando e che non siamo vittime di qualche scherzo dei server DNS del nostro provider. Il repository è autentico. Dobbiamo però aggiungere la chiave al sistema per permettere la verifica e così l’errore sparisce.
Una piccola seccatura, certo, ma un bel vantaggio in termini di sicurezza.
  • Se disponibile, controllate che l’md5sum corrisponda a quello dichiarato sul sito del programma o file che avete scaricato
Molte volte sul sito da cui scarichiamo programmi o immagini ISO vediamo un codice indicato con MD5. Si tratta di un numero che identifica il file senza possibilità di errore (o meglio con una possibilità di errore così bassa da essere insignificante). Per sapere l’MD5 del file, una volta scaricato, basta dare il comando: md5sum nome_del_file

Confrontiamolo con quello sul sito e così saremo sicuri al 100% che si tratta dell’originale.
  • Navigate preferibilmente con un browser open source aggiornato all’ultima versione disponibile, usate preferibilmente programmi open source e nativi per il sistema (per non dover usare Wine), anch’essi aggiornati
E qui qualcuno storcerà il naso: “Ma io uso Opera”. E’ un ottimo browser, seppure non migliore di Firefox (farò un confronto oggettivo fra i due appena posso). Ma è proprietario. E’ difficile sapere cosa effettivamente fa Opera. Certo ci sono metodi per scoprire se manda dei dati a qualcuno che non dovrebbe conoscerli, ma qui il problema è un altro: la sicurezza. Firefox è uno dei browser più usati al mondo, ha alle spalle una grande fondazione finanziata da Google, e soprattutto il suo codice può essere letto da chiunque. Questo significa che è facile scoprire un problema di sicurezza e difatti accade relativamente spesso. Ma tra la scoperta e la correzione passa pochissimo tempo perché essendo Open Source chiunque può apportare la correzione. Se quelli della Mozilla Foundation dormono (ma non succede) possono pensarci i programmatori della
distribuzione GNU/Linux che usiamo. E spesso accade davvero così per programmi meno famosi di Firefox. Ecco quindi che un brouwser Open è più sicuro di uno proprietario e in generale qualsiasi programma Open Source è più sicuro che uno proprietario. Un buon motivo per usare OpenOffice al posto di MS Office anche su Windows.
  • Usate formati di dati sicuri
Evitate il più possibile i .doc e similari. Meglio .odt o al massimo .rtf, se dovete mantenere la compatibilità con MS Office.
  • Evitate di usare Internet Explorer con Wine tramite Ie4Linux a meno che non sia assolutamente necessario per verificare il funzionamento di vostre pagine web; in tal caso comunque preferite la visualizzazione di pagine locali, oppure usate il servizio IE NetRender
Navigare con Internet Explorer è come mandare un messaggio al mondo con su scritto: “Ehi ragazzi, sono qui, prendetemi!”
Non fatelo. Se quella c*** di pagina non vi viene visualizzata bene con Firefox, beh, non apritela e basta. Chi non sa fare siti web a norma non merita che voi gli facciate aumentare il contatore delle visite. Anzi mandategli una e-mail:
“Ehi ciccio, il tuo sito non funziona con Firefox! Lo sai che è un programma che è stato scaricato da 8 milioni di persone in un solo giorno? Che aspetti ad aggiornarti?”
E se per caso parliamo della vostra banca, il mio consiglio è uno solo: cambiate banca. C’è poco da fidarsi. Se non hanno saputo fare bene l’impaginazione, figuratevi il resto.
  • Non eseguite mai Wine come utente root: in tal caso lascereste all’eventuale malware accesso alle directory di sistema
Dal punto di vista della sicurezza, Wine equivale a mettere Erode Antipa a guardia di un asilo nido. No, dai, sto esagerando. Ma è meglio tenerlo confinato al suo posto. L’ideale sarebbe usarlo con un utente secondario invece che con il nostro account principale.
  • seguite sempre gli aggiornamenti di sicurezza del sistema operativo: in Ubuntu è possibile accettarli in maniera predefinita tramite il gestore aggiornamenti; questa è la principale precauzione che mette al riparo dai malware: Ubuntu e Debian hanno infatti una gestione molto efficiente dei problemi di sicurezza
Un click e dormiamo sonni tranquilli.
  • Non usare distribuzioni per le quali sia scaduto il supporto di sicurezza
E’ giunta l’ora di mandare in pensione la nostra amata Debian Potato.
  • Usate cautela quando si è in possesso dei permessi di amministratore (tramite sudo, su, gksudo o kdesu), evitando di eseguire programmi di cui non si conosce l’affidabilità
  • Non entrate nel sistema come root
E possibilmente non attivate affatto l’utente root; nel caso sia necessario, evitate comunque di navigare sul web, di scaricare posta e di usare programmi che interagiscono con la rete. Anche se è comunque difficile essere colpiti da malware in queste circostanze, se tutti non applicassero tale precauzione si renderebbe più facile il compito ai cracker aprendo loro le difese del sistema.
  • Non siate paranoici
Chi viene da sistemi Windows è abituato a blindare tutto e avere paura; è portato adattribuire qualsiasi malfunzionamento a qualche ignoto virus; ma GNU/Linux non è Windows: take it easy.

ATTENZIONE! Questi consigli vanno presi come tali. Non è necessario affrettarsi a installare l’ultima versione disponibile di Firefox dal sito di Mozilla: se contiene correzioni di sicurezza significative, verrà segnalata tra gli aggiornamenti della distribuzione in breve tempo. Ripeto: take it easy.
  • Virus e GNU/Linux: demoliamo i falsi miti
Molti produttori di antivirus sostengono che la crescente diffusione di GNU/Linux accrescerà l’insicurezza del sistema, portando alla nascita di malware e in particolare di virus. Ad esempio ecco un allarmante proclama di Trend Micro e McAfee:

http://punto-informatico.it/p.aspx? i=106309

Leggere bene la data dell’articolo: giovedì 06 dicembre 2001. Sono passati 7 anni e mezzo, un’eternità nell’era dell’informatica, ma di virus non se ne sono visti.
Andiamo più sul recente. Il noto produttore di antivirus Kaspersky rilascia un piccolo studio sul malware e GNU/Linux nel 2006, riferito al 2005, in cui sostiene l’aumento esponenziale del malware per questo sistema.
Lo studio - se così si può chiamare - è in realtà un articolo in cui si tratta genericamente di malware, includendo un po’ di tutto. Ma i media parlano sempre e comunque di virus. Peraltro la fonte dello “studio” è la stessa Kaspersky e i dati sono aggregati (non sono distinti worm, trojan, eccetera). Insomma, considerando la fonte, ci si sarebbe aspettati un po’ di più. Ma il
bello viene quando si clicca sulle descrizioni di tali presunti “virus”.
Ad un certo punto il rapporto cita un virus per GNU/Linux: Virus.Linux.Rst.
Ora clicckiamo sul link di tale “virus” e leggiamo:

There is no attempt in the viral code to exploit any Linux vulnerabilities in order to obtain higher access when the virus is run on a normal user account.

Tradotto:

Non c’è tentativo da parte del virus di sfruttare una qualsiasi vulnerabilità di Linux per ottenere l’accesso ad un livello più alto (livello amministratore, ndr) quando il virus è eseguito su un normale account utente.

Insomma, un virus che non prova neppure a scavalcare le protezione del sistema per andare ad infettare i file binari che appartengono all’amministratore. Insomma un virus che non può diffondersi, a patto di usare le normali procedure che ho spiegato in precedenza (da questo punto di vista Ubuntu ha fatto una scelta molto azzeccata, in quanto l’utente root non è attivo e quindi non viene mai usato). Ma voglio fare l’avvocato del diavolo. Come dicevo in un post precedente, la diffusione di massa di un sistema GNU/Linux come Xandros (preinstallato sugli eeepc) potrebbe indurre alcuni a inviare dei file .deb che, se installati dall’utente inconsapevole, potrebbero diffondersi, forse facilmente. Il rischio trojan, insomma, è in agguato, anche se per ora è solo teorico. Ma non è necessario un antivirus, quanto la nostra intelligenza, come spiegato in questo post.
Riguardo i veri virus, invece, è bene demolire qualche luogo comune:

“I virus su Linux non ci sono perché è poco diffuso”

  • Non è vero che GNU/Linux non è diffuso: questo sistema è contenuto praticamente in tutti i router e altri dispositivi di rete e pilota circa la metà dei server Internet: un virus per GNU/Linux che fosse davvero efficace potrebbe potenzialmente bloccare l’intero mondo industrializzato;
  • GNU/Linux o sistemi Linux embedded sono largamente usati anche al di là del settore server: telefonini (alcuni modelli Nokia, i prossimi cellulari basati di Android di Google, il Neo1979 e il Freerunner, etc.), mediacenter molto diffusi (Dreambox, TiVo), persino automobili, ed è molto più diffuso sui desktop di quanto comunemente si pensi; il rilascio di driver per GNU/Linux da parte dei principali produttori di hardware (si pensi ad Intel, Nvidia, Ati, Hp, Samsung, Dell, etc.) ne è la conferma;
  • un altro sistema di tipo Unix ha già una diffusione larghissima sui desktop: Mac Os X; nonostante ciò il malware su tale sistema in sostanza è quasi inesistente e alcuni annunci clamorosi del passato si sono rivelati eccessivi se non falsi;

“Linux non ha i virus perché è ancora agli inizi”

  • GNU/Linux è un clone di Unix. Unix esiste da quasi 40 anni; in tale lunghissima storia è rimasto il sistema più sicuro, anche se sporadicamente sono comparsi alcuni programmi malevoli che, sfruttando delle vulnerabilità, hanno potuto attaccare certi sistemi. Ma GNU/Linux ha un’arma in più rispetto a Unix (già molto sicuro di per sé): GNU/Linux è software libero/open source e questo significa che le vulnerabilità vengono tappate a tempi di record, impedendo sul nascere la diffusione del malware; anzi, nella grande maggioranza dei casi le vulnerabilità vengono scoperte ancora prima che qualcuno possa sfuttarle.
  • molti programmi open source sono multipiattaforma (come Firefox e Apache) e sono diffusissimi su sistemi chiusi, ma hanno già dimostrato i vantaggi in termini di sicurezza rispetto alle controparti proprietarie, pur non essendo immuni da vulnerabilità.

“Linux non ha i virus perché gli hacker sono a favore di Linux”

Questa è una delle balle più grandi, ma qualcuno ogni tanto la tira fuori. GNU/Linux è già uno dei bersagli preferiti da cracker (non hacker: gli hacker sono normali programmatori, non pirati informatici) proprio perché è molto diffuso; non c’è quindi bisogno di aspettare per verificare la sicurezza di tale sistema.


Siamo giunti alla fine di questa chiacchierata riguardo ai virus e a GNU/Linux. A conclusione possiamo dire che GNU/Linux è un sistema sicuro per l’ambito desktop, al riparo da virus e malware, a patto che chi lo usa prenda poche e facili cautele.


Tratto da un lavoro di Guido Iodice, http://guiodic.wordpress.com, distribuito sotto licenza Creative Commons

venerdì 8 agosto 2008

UBUNTU....Linux Beginner....DISCUTIAMONE...

Apro questo post per chiunque volesse darmi consigli o suggerimenti o idee o........ecc su qualunque argomento voleste trattare (naturalmente non divaghiamo troppo)....Vediamo cosa si può fare! ;-)

giovedì 7 agosto 2008

Sony PSP e Linux??? Con QPSPManager tutto è più facile!


Oggi vi voglio segnalare un ottimo software per Sony PSP che ci permette di
  • organizzare file
  • convertire e trasferire video
  • backup dei salvataggi
  • installazione e backup delle .iso
  • installazione e backup degli homebrew
e tutto naturalmente Open Source!!! Sto parlando di QPSPManager, reperebile a questo indirizzo:

http://qpspmanager.sourceforge.net/

Il software si presenta con un interfaccia molto semplice:

Inseriamo:
  • In PSP location la directory dove viene montata la PSP (e a tal proposito consiglio di seguire la mia precedente guida per creare un punto di mount statico)
  • In Backup location la directory del vostro HD dove volete fare i backup dei dati salvati nella vostra PSP.
Salviamo le opzioni tramite il pulsante "SALVA" in basso a destra e colleghiamo la PSP al notro PC....e tutto sarà più semplice e veloce.
Importante caratteristica di QPSPManager è la possibilità di convertire direttamente i video in formato .mp4 per la PSP...basta infatti entrare nella sezione Video (dai pulsanti di sinistra), anggiungere il video che si vuole convertire nella finestra in basso e cliccare sul simbolo "PLAY". Il video verrà convertito e lo potrete comodamente trasferire sulla PSP dalla schermata di sopra (sempre nella sezione Video).
Vediamo come installare QPSPManger:
per prima cosa scaricate il file compresso dal link. Poi lo scompattate magari cliccandoci 2 volte sopra e selezionando "estrai qui". Se vi è più comodo spostate la cartella appena estratta in un altra cartella tipo /home/utente/Software e spostiamoci da terminale al suo interno con il comando:

cd /home/*utente/Software/qpspmanager-2.0.2

Installate le librerie di sviluppo delle Qt4, necessarie per la compilazione:

sudo apt-get install libqt4-dev

e a questo punto compilate:

qmake-qt4

make

Il comando make install non va, almeno per il momento...ma non c'è problema! L'eseguibile si troverà nella cartella /home/*utente/Software/qpspmanager-2.0.2/bin (quella che avete estratto all'inizio). Possiamo creare un collegamento cliccando col tasto destro e selezionando "crea collegamento", per poi copiarlo sulla Scrivania ad esempio.

Spero che questo software vi sia utile.....ciao uagliò!!!

Definiamo il Mount-Point di una periferica di archiviazione con file system VFAT


Avendo una PSP slim & lite, che sulla mia UbuntuBox viene gestita dall'ottimo software QPSPManager, per gestire salvataggi, convertire video, trasferire file...ecc, ho avuto l'esigenza di dover dare alla mia PSP un mount-point statico, e non che variasse di volta in volta (tipo /media/disk......./media/disk-1.......). Prima ho tentato di modificare il mount-point cliccando col tasto destro sull'icona del dispositivo e modificando le impostazioni di mount dalla scheda "Volume" delle Proprietà....ma questo NON FATELO, perchè non vi permetterà più di montare la periferica....infatti vi darà un errore del tipo:

Impossibile montare il volume
Dettagli: mount_point cannot contain the following characters: newline, G_DIR_SEPARATOR (usually /)

Se incappate in questo errore...risolverlo è semplice:
Da terminale date:

gconf-editor

e andate nella scheda System --> Storage --> Volume ed eliminate le chiavi relative alla periferica che non viene montata.

Vediamo ora come invece modificare permanentemente un mount-point:
Installiamo prima di tutto un insieme di tool utili:

sudo apt-get install mtools

Poi con il comando

sudo fdisk -l

verifichiamo il nome del device, es /dev/sdc1
Controlliamo che il device non ha nessuna label con il comando:

sudo mlabel -i /dev/sdc1 -s ::

Se non vi è etichetta a quel device ci verrà riproposto:

Volume has no label

Diamo allora il comando

sudo mlabel -i /dev/sdc1 ::MioDisco

per etichettare il device con il nome "MioDisco".

A questo punto dobbiamo dare i permessi per poter scrivere e cancellare i file:

sudo chown -R *utente:*gruppo /media/MioDisco

dove al posto di *utente e *gruppo inseriamo rispettivamente il nome utente e del gruppo, che nel caso si sia amministratori coincidono.
Possiamo però impostare i permessi in modo più flessibile, assegnando ad un determinato gruppo la possibilità di modificare i file del nuovo disco. Il gruppo è plugdev, a cui appartengono gli utenti abilitati al montaggio di dischi rimovibili. Diamo questi comandi:

Assegnamo la directory dove montiamo il disco al gruppo plugdev:

sudo chgrp plugdev /media/MioDisco

Impostiamo i permessi di scrittura al gruppo:

sudo chmod g+w /media/MioDisco

Imponiamo che solo i proprietari dei file possono cancellarli d
al dispositivo. (Tutti possono scrivere ma l'utente A non può cancellare un file creato dall'utente B).

sudo chmod +t /media/MioDisco

Ora, se ricolleghiamo la periferica, verrà montata in una cartella con sempre lo stesso nome e, come nel mio caso, non dovremmo modificare ogni volta le impostazioni di eventuali programmi che usano il dispositivo. Ciao uagliò!