Kali Linux su Virtual Box

Sebbene sia un fanatico di VMWare, e consideri Virtual Box nettamente inferiore, oggi mi sono voluto cimentare con Kali su Virtual Box perchè ho sentito che la configurazione di rete di VB non funziona proprio bene e che è perfino impossibile installare le Guest Additions che consentono di gestire la grafica e la cplipboard in modo efficace.

Tutto bene, tutto tranquillo, dal download all’installazione di Kali, che ho eseguito dalla ISO delle versione 2016.2 per x64.

Dalla documentazione di Kali l’installazione delle Guest Additions è molto semplice: collega il CD ROM da menù, apri il CD ed esegui il file di setup:

sh /media/cdrom/VBoxLinuxAdditions.run

Peccato che di suo l’installazione fallisca miseramente:

Ora leggendo il file di log dell’installazione si viene rimandati alla lettura del file /var/log/vboxadd-install.log che dice questo:

Per installare i sorgenti del kernel si può provare con il modulo dkms, ma viene restituito un errore che dice in sostanza che il programma apt non trova il modulo.

Proviamo allora a installare direttamente le header del kernel; per farlo basta ottenere la versione del kernel e lanciare il comando:

apt-get install linux-headers-(versione)

Anche qui nulla di fatto.

Sorge un dubbio… ma quali sono i repository che lui interroga? Questo lo vediamo leggendo il contenuto del file /etc/apt/sources.list:

Il problema è qui: non ci sono repository validi per apt, quindi di fatto non si può installare/aggiornare un bel niente di questa installazione!!!!

Con pazienza si edita il file /etc/apt/sources.list aggiungendo le seguenti due righe:

deb http://http.kali.org/kali kali-rolling main contrib non-free
deb-src http://http.kali.org/kali kali-rolling main contrib non-free

che dicono a questa installazione di linux che per ogni installazione o update lì deve andare a guardare (fonte documentazione kali: http://docs.kali.org/general-use/kali-linux-sources-list-repositories).

Fatto questo è necessario eseguire i due comandi:

apt-get clean && apt-get update

Dopo un po’ di letture da internet il database dei paccetti APT è nuovamente popolato con lo scaricabile:

A questo punto possiamo eseguire il comando di installazione del modulo dkms:

apt-get install -y dkms

Installa un fottio di cose e, tra le tante, ANCHE GLI HEADER incriminati!!!

Tutto ok, vero? Abbiamo gli header e possiamo installare… no no no, nulla di più sbagliato, perché lui, il zozzone, ha installato gli header della versione corrente di kali (4.8.0), non di quella contenuta nella ISO (4.6.0), guardate:

Quindi?

Primo: ipotizzo che l’installazione della VM non possa prescindere dallo scaricarla da internet al momento; immagino che kernel, pacchetti e ISO (che io avevo già da qualche settimana…) siano allineate con continuità e chi non ha voglia/necessità di scaricare i 2,9GB della ISO deve farsi tutta la trafila seguente.

Secondo: aggiorniamo integralmente il nostro kernel linux alla versione 4.8.0 o, comunque, a quella offerta “real time” dai repository APT aggiornati di Kali.

Eseguiamo quindi l’aggiornamento di tutto, proprio tutto:

apt-get upgrade

Qui lui dirà che devono essere aggiornati tipo 1.230 pacchetti e ve li elenca anche; è assolutamente necessario leggerli tutti dal primo all’ultimo e sapere per filo e per segno a cosa servono (scherzo…), fidiamoci, rispondiamo di sì e aspettiamo con pazienza che abbia finito (da me ci ha messo 20 minuti circa per scaricare 955MB di pacchetti); durante l’installazione dei pacchetti, dopo che avrà prima scaricato tutto dalla rete, sicuramente ci saranno domanda cui dovremo rispondere in modo interattivo.

La prima è la notifica degli aggiornamenti APT, è un’informativa, basta premere “q” per uscire.

La seconda avvisa che verranno aggiornati dei servizi di sistema che sono in esecuzione e che dovrebbero essere riavviati, si o no è indifferente, meglio sì ma tanto poi alla fine riavvieremo la VM per cui…

Questo upgrade forzato, di solito, non fa proprio “benissimo” perchè se ne infischia di dipendenze tra pacchetti, check di versioni ecc., per cui dopo è fortemente consigliabile spendere ancora un po’ di tempo eseguendo anche:

apt-get dist-upgrade

Questo controllerà dipendenze e versioni, scaricherà altri 650MB circa e toccherà circa 450 pacchetti (330 da aggiornare, 126 che ha tolto prima e che ora reinstalla… il furbo!). Dopo che lui ha scaricato e aggiornato il mondo con queste due istruzioni (è un po’ come fare un aggiornamento di windows dalla 8.1 alla 10 on line, solo che qui sicuramente alla fine funziona, con windows sicuramente non funziona niente o funziona solo quello che non vi serve) ci sarà pronto per l’uso un kernel 4.8 nuovo di zecca che non sarà però on line fino al prossimo riavvio!

Anche qui chiederà un po’ di conferme…

Mentre lui fa questo vi faccio vedere la differenza tra le due modalità di upgrade:

• upgrade: upgrade is used to install the newest versions of all packages currently installed on the system from the sources enumerated in /etc/apt/sources.list. Packages currently installed with new versions available are retrieved and upgraded; under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed. New versions of currently installed packages that cannot be upgraded without changing the install status of another package will be left at their current version. An update must be performed first so that apt-get knows that new versions of packages are available.
• dist-upgrade: dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages; apt-get has a “smart” conflict resolution system, and it will attempt to upgrade the most important packages at the expense of less important ones if necessary. So, dist-upgrade command may remove some packages. The /etc/apt/sources.list file contains a list of locations from which to retrieve desired package files. See also apt_preferences(5) for a mechanism for overriding the general settings for individual packages.

Interessante, vero?

Comunque… alla fine del giro sarà necessario riavviare il nostro linux Kali per avere in linea il nuovo kernel 4.8.

shutdown -r now

dopo il riavvio osserviamo infatti:

C’è il nuovo kernel 4.8.0 compilato prima che si è aggiunto al 4.6.0 di prima installazione.

Il kernel attualmente caricato al boot è il 4.8.0.

Ora possiamo riprovare l’installazione delle Guest Additions, con:

cd /media/cdrom
sh ./VBoxLinuxAdditions.run

A questo punto andrà a buon fine dal momento che trova tutto “allineato e coperto”:

Ultimo riavvio e basta settare dalle preferenze della VM il copia/incolla bidirezionale, le cartelle condivise, ecc.

Considerazione della sera: ma non era meglio scaricarsi all’inizio la VM di Kali già pronta per VirtualBox invece di partire dalla ISO? Certamente sì, ma vuoi mettere adesso la soddisfazione di avere tutto aggiornato e una Kali 2016.3.0 invece della 2016.2.0?

Giorgio