Firmware fog per Dreambox

Transcript

1 Firmware fog per Dreambox e altro Autore: fog (alias fog@infosat sui forums di Tutti i diritti riservati. Per qualsiasi ridistribuzione o uso del contenuto del presente documento inviare una richiesta a mk0134@mclink.it. Responsabilità: L'autore declina ogni responsabilità per qualsiasi danno imputabile ad inesattezze o errori contenuti nella presente guida o nel software (firmware) per Dreambox distribuito insieme alla presente. Questa è più o meno la formula di rito che resta comunque valida. Nella sostanza, ho realizzato questo lavoro per hobby e scopi personali e lo rendo pubblico solo perché penso che forse possa essere di spunto o di aiuto per altri che come me condividono la passione per il ricevitore Dreambox ed il software che lo fa funzionare, molto è inoltre lasciato alle vostre capacità e naturalmente, buon senso.

2

3 Indice Generale 1 Introduzione A chi non è Rivolta Questa Immagine A chi è Rivolta Questa Immagine? Linee Guida Considerazioni Generali sulla Sicurezza Livello di Sicurezza Presente nel Firmware Tipo d'uso Previsto Cosa c è Sotto al Cofano Cambiamenti al Software Standard Kernel Linux Enigma Scripts di Init Utenti, Gruppi Preimpostati e Passwords Software Busybox Shadow Passwords Software di Rete Avviato da inetd Server Telnet Server FTP Vsftpd Software di Rete Standalone Avviato da Enigma Software Samba Interfaccia Web di Enigma Principale Software Extra Contenuto nell'immagine Software Sudo Editor Nano Libreria OpenSSL Software OpenSSH (Portable) Software Stunnel Software TCP Wrappers Libreria Berkeley DB Software Netatalk Suggerimenti...37 iii

4 3.1 Dove Installare l Immagine Appena Installata Immagine Creazione di Directories e Installazione di files Installazione di Plug-ins, Settings e Skins di Enigma Installazioni in Aree Protette Installazione di Emulatori CA (Emus) Creazione di Nuovi Utenti e Gruppi Creazione delle Home Directories Esempio di Creazione di Un utente Possibili Evoluzioni...43 iv

5 1 Introduzione Questo firmware, espressamente realizzato per il Dreambox 7000, nasce inizialmente per gioco e per sperimentare e mettere un po sotto torchio su Mac OS X il cross developement kit del Dreambox. Recentemente sono infatti riuscito, con opportune modifiche a diversi files di configurazione ed ai patches di Linux distribuiti con il CVS, a far funzionare il CDK anche sotto Mac OS X. Ho già postato tempo fa su le modifiche e le istruzioni relative alla compilazione su Mac OS X. Dopo i primi tentativi, hanno preso forma quelli che poi sarebbero diventati gli obiettivi principali di questa realizzazione e tra loro correlati: 1) Fornire un'immagine software che, nella sua configurazione di default fosse sufficientemente sicura se paragonata agli standard, presi ad esempio, ai quali ci hanno da tempo abituato le diverse distribuzioni Linux, Unix e non ultimo Mac OS X. 2) Riesaminare il software di rete normalmente fornito con il Dreambox (in primo luogo i servers FTP e Samba) in modo da fornire per esso una configurazione di default che tenesse in considerazione gli obiettivi definiti al punto 1 ed al tempo stesso ne sfruttasse meglio le potenzialità. 3) Aggiungere i servizi di rete offerti dal pacchetto Netatalk, in particolare il server AFP (Apple Filing Protocol) configurato in modo da offrire i propri servizi sia attraverso TCP/IP che attraverso il protocollo Appletalk (il protocollo di rete legacy di Apple e che consente il browsing dei servers di rete AFP sui computer clients). AFP è ancora il metodo di condivisione più usato su Mac OS X e spero che la scelta di includere Netatalk in questa immagine possa fare contenti gli utenti Mac. Il protocollo Appletalk su Mac OS X è stato affiancato dal più recente Rendezvous/Bonjour che offre servizi simili su TCP/IP per quanto riguarda il browsing dei servizi di rete. Sulle versioni più recenti di Mac OS X Appletalk può essere usato solo per le funzioni di browsing dei servers di rete (la connessione al server e il trasferimento dei files avviene sempre mediante connessioni TCP/IP), sulle versioni precedenti dell'os del Mac, Appletalk può (in alcuni casi deve, come nella versioni di Mac OS precedenti la 8) anche essere impiegato come protocollo di trasporto (anche se le prestazioni sono nettamente inferiori a quelle ottenibili via TCP/IP). Le ultime osservazioni solo per sottolineare che potrete connettervi al vostro Dreambox anche con computer Mac vecchi di una quindicina d'anni e anche più. Fatta questa premessa è opportuno sottolineare a chi può interessare questo firmware, anche per non generare false aspettative. 5

6 1.1 A chi non è Rivolta Questa Immagine È doveroso evidenziare da subito che se siete alla ricerca dell'ultimo grido in fatto di miglioramenti dell'interfaccia grafica di Enigma e relativi pugins lasciate perdere e non provate neppure ad installare questa immagine perché ne rimarrete delusi. Detto in altri termini niente nuovi plugins, emu, skins, superpannelli di controllo od altre modifiche ad hoc al software Enigma scaricabile dal CVS. Le motivazioni di questo fatto sono principalmente due e tra loro correlate. La prima è che sto muovendo i primi passi nella programmazione per il Dreambox ed al momento non ho assolutamente intenzione né la possibilità di competere con chi da anni ha accumulato una notevole esperienza nella programmazione di Enigma ed è stato capace di fornire miglioramenti al software (nella forma di plugins o di modifiche al software principale) senza i quali la passione per il Dreambox si sarebbe spenta da tempo in molti di noi visto che le speranze iniziali riposte nella casa madre sono state, nel corso degli anni, in gran parte disattese. La seconda ragione è che, se anche avessi tempi e mezzi per fare una rivoluzione, probabilmente le prime attenzioni si rivolgerebbero in ogni caso alla costruzione di una base più solida e sicura del software installato. 1.2 A chi è Rivolta Questa Immagine? Le osservazioni precedenti rispondono già in parte a questa domanda. Chiunque si sia già posto il problema di come rendere più sicuro il Dreambox potrà trovare utile avere a disposizione questo firmware sia come spunto per 'fortificare' quello a lui preferito, attraverso la lettura dei vari files di configurazione e scripts di init in essa contenuti sia come immagine base di partenza, installata su pen USB o Hard disc da arricchire con i plugins indispensabili (e purtroppo in essa mancanti) e quelli preferiti. Non nascondo che entrambi gli approcci presentano dei limiti oggettivi e/o delle difficoltà anche legate alle capacità e alle conoscenze della singola persona. Nel primo caso può non essere sufficiente la semplice copiatura dei files binari e di configurazione nelle posizioni corrispondenti dell'immagine preferita. Il CDK infatti, per salvare spazio, al momento di creazione dell'immagine finale, installa le librerie eliminando tutti i 'simboli' e le funzioni non usate dai vari binaries installati. Ad esempio copiare semplicemente sudo o afpd e relativa libreria libatalk.so potrebbe non funzionare in quanto tali software potrebbero avere bisogno di funzioni presenti in altre librerie (libc.so ad esempio) che sull'immagine scelta come base d'installazione potrebbero essere non presenti. La soluzione migliore, in questo caso, è forse quella di copiare in blocco il software di questa immagine in una directory dedicata su pen USB o Hard disc, modificare gli scripts di init (prendendo come riferimento quelli presenti nella mia immagine) impostando la variabile d'ambiente LD_LIBRARY_PATH in modo opportuno, rigenerare i links necessari ai vari files di configurazione, al 6

7 file passwd e shadow nelle directories originali /etc e /var/etc, ecc. ecc. ecc. Insomma, una soluzione per utenti esperti e disposti a perdere un po' di tempo. Nel secondo caso (personalizzazione di questa immagine) i limiti sono imposti dal modo stesso in cui il software Enigma si è evoluto (o non evoluto?) nel corso del tempo. Se anche da un lato offre discrete possibilità di personalizzazione ed addizione di nuove funzionalità (skins e plugins) la struttura principale risulta poco modulare e strutturata. A tale proposito e solo a titolo di esempio basti pensare al fatto che il percorso per le registrazioni è codificato direttamente all'interno del codice (che mi ricordi esiste appena una direttiva #define nei sorgenti c++) oppure al fatto che la rete venga configurata in un paio di punti all'interno del codice (nei quali viene avviato anche Samba se impostato nelle preferenze dall utente) ed anche in questo caso i nomi dei comandi sono addirittura hard coded. Che dire poi della scelta di avviare Samba con Enigma e lasciare i servers FTP e Telnet alla configurazione manuale di inetd? Quello che voglio dire è che manca totalmente in Enigma una visione coerente di come gestire la rete e i relativi software e meno che mai Enigma offre un modello e facilities per il programmatore che voglia aggiungere nuove funzionalità. Tutto questo è, secondo il mio parere responsabilità della casa madre che poco ha investito nel corso degli anni nel software, che in fondo è il vestito che rende il suo prodotto un prodotto di successo. Tutto questo ha costretto i diversi sviluppatori indipendenti di software per Dreambox, che via via si sono susseguiti lasciando tracce più o meno profonde, a reinventare continuamente la ruota per implementare particolari funzionalità che fossero in accordo con la loro particolare visione di cosa doveva fare il Dreambox. Una responsabilità dell'attuale situazione di stallo però l'abbiamo anche noi (utenti e sviluppatori/assemblatori indipendenti) che, invece di unire le forze abbiamo incitato una sorta di 'gara all'immagine più bella e più stabile'. La situazione attuale è sotto gli occhi di tutti, i limiti fisici (grandezza RAM e FLASH) del Dreambox sono stati da tempo raggiunti e l'assemblaggio di un un immagine spesso si limita alla scelta di quale software includere o meno. Niente o quasi, per continuare con gli esempi, è stato fatto per facilitare il programmatore o anche l'utente esperto per la realizzazione in un modo standard di pacchetti software da installare su hard disc o dispositivi di memoria USB. É evidente che da utente Mac ho il palato esigente, tuttavia non pretendo l'esistenza sul Dreambox di Frameworks od un livello di astrazione paragonabili a quelli di questo sistema operativo, ma tra il 'nulla' e la 'quasi' perfezione ed anche considerando le potenzialità effettive della macchina Dreambox (non paragonabili a quelle dei PC più recenti) qualcosa deve pur esserci. Fine della lunga divagazione, scusate dello sfogo, ma alcuni di questi pensieri mi pesano da diverso tempo. 7

8 1.3 Linee Guida In questa sezione desidero soffermarmi più da vicino sulle considerazioni che mi hanno guidato nella realizzazione di questa immagine che, come detto precedentemente, ha lo scopo di rendere il nostro Dreambox un po più sicuro. Scusate se alcune divagazioni possono sembrare sproporzionate all'argomento trattato, anché perché sicuramente lo sono. Ci siamo spesso incontrati sui forum di (sul quale questa immagine per il Dreambox dovrebbe essere resa disponibile) parlando degli argomenti più disparati e forse questa è un'occasione per conoscerci meglio. Le persone con cui ho avuto l'onore di scambiare opinioni sui vari threads probabilmente mi conoscono già come un gran chiaccherone e non voglio smentirmi. Di solito osservo ma quando parto a scrivere è difficile fermarmi Considerazioni Generali sulla Sicurezza Il computer più sicuro è quello che rimane sempre spento e forse neanche quello perché può sempre arrivare la Banda Bassotti. Già questa premessa fa intuire che l'arte di assemblare hardware e software sicuro e configurare quest'ultimo in modo da garantire una sicurezza accettabile, non è di quelle facili. Il tema della sicurezza coinvolge inoltre aspetti tecnici e teorici che richiedono conoscenze molto specialistiche, basti solo pensare alle conoscenze matematiche richieste che stanno dietro alle ricerche avanzate sulla crittografia, sulla quale sono basati buona parte dei metodi di protezione usati dai vari software. La crittografia, tuttavia, non esaurisce in alcun modo il tema della sicurezza che, anche se riferita al solo settore dei computer, risulta piuttosto dall'intreccio complicato di diverse discipline. Con riferimento ai computer, ma credo che l'affermazione valga anche in senso più generale, la sicurezza è allo stesso tempo un bersaglio in movimento ed una entità di grandezza non misurabile in senso assoluto. In movimento perché anche partendo da una condizione di sicurezza giudicata inizialmente accettabile non è detto che questa rimanga tale, senza ulteriori e continui sforzi di miglioramento e di monitoraggio. Di grandezza non misurabile in senso assoluto perché, ovviamente, il grado di sicurezza giudicato accettabile è sempre il risultato di compromessi e varia in funzione del tipo di servizi che si vuole offrire, della sensibilità dei dati presenti e non ultimo, in un mondo collegato da reti di tutti i tipi, della possibilità che ha il nostro sistema (computer) d'interagire con altri, potendo, nei fatti, alterare lo stato di sicurezza di questi ultimi (l'esempio più lampante è dato dai virus anche se esistono esempi molto più sottili). Un'aspetto della sicurezza, che in alcuni casi diventa paradossale, è che questa è più facile da implementare in una serie di casi estremi e a due a due opposti e che dal punto di vista concettuale corrispondono a situazioni del tipo 'o tutto o nulla'. Ad esempio è molto più facile raggiungere una sicurezza accetta- 8

9 bile nei due casi limite: 1) Un computer la cui unica funzione sia quella di offrire un servizio al mondo intero (ad esempio un server FTP con accesso anonimo). 2) Un computer usato per memorizzare dati sensibili ma che non debba fornire alcun servizio al mondo esterno. Naturalmente, negli esempi riportati, ho fatto l'ipotesi che il software impiegato fosse ideale, cioè privo di bugs o crepe nella sua implementazione. La situazione reale è ben diversa, con frequenza sempre maggiore, infatti, assistiamo al rilascio di aggiornamenti software il cui solo scopo è quello di tappare falle o riparare a bugs che si ripercuotono sulla sicurezza stessa. Ancora un argomento a favore della sicurezza vista come bersaglio mobile e in continua evoluzione. Per tornare al discorso principale: sono sempre le situazioni di mezzo che presentano le maggiori difficoltà, e tutte le situazioni reali sono situazioni di mezzo. Potrei continuare con diversi altri esempi ma credo sia sufficiente. Ho espresso il concetto solo per evidenziare che i concetti di 'indipendenza' / 'disomogeneità' (che si possono riassumere con il termine di ortogonalità termine sempre più in voga per esprimere tali concetti e che non a caso hanno una forte similitudine con il concetto di otrogonalità in matematica) intesi come sussistenza d'indipendenza tra determinati fattori o scarsa sovrapposizione tra determinate funzioni, giocano un ruolo importante sia per quanto riguarda l'analisi dello stato di sicurezza di un determinato sistema sia per quanto riguarda l'implementazione di un determinato livello di sicurezza in casi concreti. Non poteva essere altrimenti, visto che in ogni situazione reale complessa ci comportiamo più o meno nello stesso modo: cerchiamo di scomporla o rappresentarla nel minor numero di aspetti indipendenti. Il concetto di ortogonalità, espresso in questi termini, può sembrare banale, ma sono sempre le cose banali che nascondono i significati più profondi. Qualcuno potrà anche obiettare che esiste anche l'intuito, che tutto coglie in un solo pensiero, ma un genio senza un esercito di raziocinanti costretti a usare principi d'indipendenza per scomporre, inquadrare, classificare una teoria, un'equazione probabilmente rimarrebbe un genio incompreso. Pur restando ai piani alti, è bene tornare al tema della sicurezza, vedo infatti già del fumo bianco salire dalle parti basse di qualche lettore. Come detto, il concetto di ortogonalità, per quanto riguarda la sicurezza, è un valido aiuto sia nell'analisi di un sistema esistente che nella pianificazione di uno da costruire. Questo ultimo aspetto è quello che ci riguarda più da vicino e costituisce un criterio essenziale per: 1) Pianificare i servizi che desideriamo implementare sul nostro sistema classificandoli secondo un criterio di ortogonalità. 2) Per ognuno dei servizi stabiliti al punto precedente, stabilire il grado di si- 9

10 curezza necessario per ognuno di essi e quindi individuare gli strumenti necessari per raggiungere tale grado di sicurezza. Per quanto riguarda il punto 1, è importante sottolineare che, quanti più servizi tra loro indipendenti/disomogenei (ortogonali) intendiamo implementare, tanto più difficile e delicata sarà la fase descritta al punto 2. A tale proposito basti pensare che a nessuno verrebbe in mente (almeno spero di no!) di implementare un servizio di home-banking su una macchina che contemporaneamente offre un servizio di libero accesso attraverso qualche protocollo di condivisione. Per quanto riguarda il punto 2 è invece importante sottolineare che quanto maggiore è l indipendenza (ortogonalità) tra i vari strumenti individuati per raggiungere il grado di sicurezza desiderato, tanto più facile sarà mantenere tale livello di sicurezza nel corso del tempo o incrementare il livello di sicurezza qualora ce ne fosse bisogno. A tale proposito, non a caso ho parlato di sistema e non di macchina o computer in quanto un fattore, che aumenta notevolmente l indipendenza tra i vari sistemi usati per raggiungere il livello di sicurezza desiderato, è proprio quello di implementare tali strumenti su macchine o computer differenti da quella che offre i servizi. Un'esempio per tutti di tale fatto sono i routers e i firewalls. È per considerazioni generali di questo tipo che un po' storco il naso quando, tra le funzionalità elencate in un nuovo firmware per Dreambox, vedo quelle di firewall (e magari anche di router! Per non parlare poi delle immagini che offrono Open VPN tra il software installato!). E questo anche senza considerare che un firewall/router sul Dreambox: 1) È come mettere il carro davanti ai buoi se prima non si è posto rimedio agli aspetti di 'base' della sicurezza come ho cercato di fare realizzando questa immagine. 2) Può costituire un sovraccarico notevole per una macchina destinata ad uno scopo totalmente diverso. 3) Può generare false aspettative nell'utente, che potrebbe arrivare a pensare di affidare ad esso compiti delicati per i quali non è assolutamente adeguato, e concentrare in esso funzionalità di sicurezza non solo per i servizi residenti sul Dreambox ma anche per l'intera rete domestica, trasformandolo nell'anello più debole e fragile dell'intera catena (e con questo torniamo al discorso sull'ortogonalità). Meglio scendere di piano, perché il fumo che vedo ora è diventato nero! Questa lunga introduzione mi serve infatti per dire due cose: 1) Con questa immagine il Dreambox non diventa Fort Knox; 2) La configurazione dei vari software presenti nell'immagine è stata fatta pensando ad un uso privato e personale degli stessi. 10

11 Questi due aspetti sono esaminati nelle due sezioni seguenti Livello di Sicurezza Presente nel Firmware A questa domanda, posta in termini così generali (i titoli di una sezione hanno le loro esigenze), non so proprio come rispondere, a meno di non continuare con altre pagine di dissertazioni, che a questo punto sarebbero fuori luogo, anche per me. In termini molto più semplici è forse meglio riassumere quello che ho cercato di fare con questa realizzazione al fine di garantire un livello di sicurezza accettabile. D'accordo, ma cosa vuol dire accettabile? Accettabile vuol dire introdurre una serie di strumenti universalmente riconosciuti come idoonei per fornire una sicurezza accettabile per le situazioni d'uso previste per la nostra macchina. Sembra il cane che si morde la coda o il classico dilemma dell'uovo e della gallina ed in un certo senso è proprio così. Forse è meglio passare direttamente all'esemplificazione. Molti di noi, almeno quelli abituati ad usare un sistema Linux o UNIX, hanno dimestichezza con i tools fondamentali ed i criteri impiegati per ottenere la sicurezza di base in una macchina multiutente basata su UNIX o ad esso ispirata. Tools quali sudo, l'impostazione data dal meccanismo delle Shadow Passwords, la disabilitazione dell'utente root, sono tutte cose che probabilmente conosciamo e che sui sistemi basati su UNIX sono presenti o impiegate da parecchi anni come strumenti fondamentali su cui fondare la sicurezza di base. Quello che ho cercato di fare è stato semplicemente dotare (o anche far emergere, visto che, ad esempio, le Shadow Passwords erano già supportate) il nostro Dreambox di questi strumenti o impostazioni, in modo da farlo assomigliare un po' di più, sul piano della sicurezza, ai cugini PC che usano un sistema operativo basato su UNIX/Linux. La domanda veramente sorprendente, quindi, è un'altra. Visto che fin dall'inizio il Dreambox ha offerto servizi di rete (server FTP, interfaccia Web ecc.) che a parer mio esigevano almeno una minima preoccupazione per l'aspetto sicurezza, come mai nessuno (che io sappia) lo ha fatto prima? Il lavoro che ho fatto è stato senz'altro faticoso e a tratti noioso, ma non credo assolutamente che possa essere classificato tra quelli difficili, anche considerando che ho fatto questo come hobby senza dedicargli il tempo pieno (a parte la scrittura di questa introduzione eh! eh!). Quindi, se avete fiducia nell'efficacia dei metodi usati in questo firmware per aggiungere sicurezza (che, ripeto, sono ormai divenuti uno standard), dovreste considerare il livello di sicurezza raggiunto accettabile. So di finire ancora con un giro di parole ma spero di essere stato capito. Quanto detto vale per quanto riguarda la fiducia nei metodi e criteri generali usati per aggiungere sicurezza. Vi è un'altro aspetto che spesso viene total- 11

12 mente sottovalutato ed è quello della fiducia implicitamente riposta sia nei tools che implementano i criteri di sicurezza scelti sia più in generale, in tutto il software che viene eseguito sulla macchina. A quest'aspetto ho già accennato all'inizio di questa sezione. Merita tuttavia richiamarlo ancora perché è spesso il più sottovalutato ed anche perché diversi software inclusi in questo firmware (una discreta parte di quelli standard ed extra presenti nel CVS) sono un po' datati. Non ho fatto una ricerca approfondita delle implicazioni che quest'aspetto può avere sulla sicurezza ed ho resistito alla tentazione di sostituire i software già presenti nel CVS con versioni più recenti (in particolare Busybox, Samba e OpenSSL) per due ragioni. La prima e più ovvia ragione è che parte del lavoro era già stato fatto, mentre la seconda è dovuta vincoli sulla dimensione finale dell immagine. È regola comune infatti che il codice di un software cresca di dimensione nel corso della sua evoluzione ed è assai probabile che se avessi seguito il percorso di un aggiornamento completo alle ultime versioni, avrei superato le dimensioni massime consentite per un immagine firmware, dettate dalla dimensione della flash del Dreambox 7000, visto che l immagine attuale non supera questo limite per una manciata di kb. Inoltre, come detto nell ultima parte di questa guida, il software e le configurazioni presenti in questa immagine costituiscono un primo esperimento di fattibilità, e si presterebbero meglio ad una distribuzione nella forma di pacchetto da installare su un dispositivo di memoria USB o su hard disc Tipo d'uso Previsto I diversi servers presenti in questa immagine sono stati preconfigurati pensando ad un uso degli stessi di tipo privato e personale o da parte di utenti di fiducia su una rete locale o anche attraverso internet per mezzo degli strumenti forniti (il server SSH e Stunnel). Devo inoltre sottolineare che, qualora il Dreambox sia collegato in una rete permanentemente connessa ad Internet (caso ormai frequente) tramite un router, ritengo indispensabile, per completare il quadro di sicurezza preimpostato, che quest'ultimo o altro dispositivo svolga anche le funzioni di firewall per la rete. Credo che l'ultimo requisito sia frequentemente rispettato visto che, nella maggioranza dei casi, la connessione permanente ad internet viene realizzata tramite ADSL per mezzo di router/firewall provvisti di modem ADSL o porta ethernet connessa ad un modem ADSL. Vista la disponibilità di hard disc dalla capacità ormai impressionante e dal prezzo abbordabile, con l'aggiunta di qualche utente ed eventualmente gruppo (le linee guida per la loro creazione sono date in seguito), il Dreambox potrebbe diventare un piccolo NAS per scopi personali. Sicuramente mancano tools che ne agevolino la configurazione ed altri che completino ulteriormente il quadro (sto pensando al demone syslogd e ad una configurazione ponderata dei logs di sistema), tuttavia, per esigenze personali e non esagerate, la sicurezza offerta dovrebbe essere sufficiente. Se avete intenzione di modificare le impostazioni iniziali per destinare i servers ad un uso diverso da quello sopra descritto (ad esempio accesso incondizio- 12

13 nato o ad utenti non di fiducia al server FTP) siete sulle vostre gambe. Mi raccomando solo, in questo caso, di leggere attentamente i manuali di configurazione dei vari servers e soprattutto (vedi discorsi sull'ortogonalità) di non mescolare tipi di servizi, ad esempio usare il Dreambox sia come NAS personale che come server per un accesso meno ristretto. Un'ultima raccomandazione, per il caso in cui vogliate configurare un'accesso meno ristretto ai servers, è quella di creare una DMZ nella quale collocare il Dreambox (esistono ormai router/firewall con DMZ a prezzi non esagerati). Poiché ho considerato la presenza di un firewall come prerequisito per il completamento del quadro di sicurezza, nelle spiegazioni che seguono, relative al software installato, dò qualche consiglio sulle configurazioni più opportune per questo dispositivo. 13

14

15 2 Cosa c è Sotto al Cofano Qualcosa deve pur esserci altrimenti che scrivo a fare? 2.1 Cambiamenti al Software Standard Il progetto di fornire una base software più sicura unitamente all'aggiunta di software extra di grosso calibro si è rivelato subito più impegnativo di quanto potesse sembrare all'inizio. Non era infatti sufficiente modificare qualche file di configurazione, compilare ed installare il software extra per raggiungere l'obiettivo. È stata necessaria innanzitutto un'analisi preliminare del software di base normalmente fornito con il Dreambox per valutare come questo rispondesse sia alle richieste di sicurezza sia alle necessità dei pacchetti software aggiuntivi. Riporto di seguito i principali cambiamenti effettuati al software di base sia in fase di compilazione che in quella di configurazione/installazione Kernel Linux Versione: (?) Links: Non a caso ho inserito un punto interrogativo tra parentesi nel numero di versione del kernel di Linux. Infatti se anche è vero che i sorgenti di base corrisondono a questa versione è altrettanto vero che questi sono 'pesantemente' modificati mediante patches ricavati per la maggior parte da versioni successive del kernel (parliamo di qulche centinaio di files modificati) ed in parte minore corrispondenti a modifiche 'ad hoc' per l'hardware del Dreambox. Queste ultime corrisspondono a loro volta, in discreta parte, alla configurazione del kernel, eseguita in batch prima della compilazionene del kernel stesso. Secondo il mio modo di vedere, in questa situazione, è difficile attribuire una corrispondenza del numero di versione del kernel del Dreambox con quelle ufficiali e disponibili nel source tree di riferimento del kernel di Linux. Rispetto alla versione normalmente compilata con i firmware ufficiali, Ho aggiunto i moduli di rete necessarri per il supporto del protocollo AppleTalk. I moduli sono inseriti nel corretto ordine in fase di avvio della macchina (script start_daemon in /etc/init.d) Enigma Versione: CVS Ottobre 2006 Links: Per le ragioni esposte precedentemente, Enigma non ha subito modifiche, sono stato anzi costretto, per i vincoli imposti sulla dimensione finale dell'immagine, ad eliminare tutti i plugins e gli skins extra (ad eccezione dello skin Small usato come default) normalmente presenti anche nelle immagini ufficiali. 15

16 2.1.3 Scripts di Init Poiché l'interfaccia ethernet viene attivata e configurata da Enigma nella fase di avvio, senza possibilità, da parte di altro software residente sulla macchina di modificare tale comportamento, ho dovuto modificare in modo sostanziale (la modifica stessa si limita a poche righe ma il cambiamento è comunque sostanziale) lo script di init rcs in modo da aggirare tale comportamento. Nelle immagini ufficiali (ed anche in tutte quelle di sviluppatori indipendenti che ho avuto modo di verificare) normalmente lo script principale di avvio rcs termina in un loop che interroga con cadenza regolare lo stato di Enigma circa le azioni da intraprendere. A seconda delle scelte effettuate dall'utente tramite il telecomando (o anche tramite l'interfaccia web di Enigma), il loop termina in uno dei seguenti modi: 1) arresta la macchina; 2) riavvia la macchina; 3) riavvia la macchina eseguendo il comando /bin/flashtool a seguito dell'installazione di un nuovo firmware ; 4) riavvia il demone dccamd. I file binari flashtool e ddcamd fanno parte del software fornito dalla Dream Multimedia in forma binaria dei quali di più non sono in grado di dire se non del fatto che, dal nome si può supporre che dccamd sia il demone che si occupa della codifica dreamcrypt. Anche se con l'intuito era facile supporre che flashtool veniva eseguito a seguito di una nuova installazione firmware, ho impiegato un po' di tempo a recuperare il codice di uscita da Enigma quando viene eseguito un aggiornamento del software in flash, ancora una volta a conferma della scarsa linearità e intricatezza del software Enigma che inoltre è praticamente sprovvisto di documentazione o codice ben commentato. In ogni modo, quello che è importante osservare ai nostri fini è che, per la presenza del loop ora descritto, lo script rcs resta in esecuzione per tutto il tempo in cui è in esecuzione Enigma ed obbiga ad eseguire prima di esso tutti gli altri comandi o scripts aggiuntivi (compreso lo script /var/etc/init eventualmente presente, normalmente usato per 'customizzare' il boot del Dreambox da parte dell'utente). Questo fatto crea un problema per l'avvio di tutti i demoni di rete che hanno bisogno di conoscere lo stato e l'indirizzo IP dell'interfaccia ethernet, in quanto l'interfaccia è attivata da Enigma stessa in funzione delle impostazioni fissate dall'utente. Ho risolto il problema creando uno script (start_daemons) lanciato in background da rcs che monitora lo stato dell'interfaccia ethernet e non appena rileva che è attiva e configurata con un indirizzo IP lancia i servers facenti parte del pacchetto. Oltre a questo lo script start_daemons esegue anche le seguenti operazioni: 16

17 1) Imposta una tantum i permessi su /var/tuxbox in modo tale che il gruppo admin abbia i permessi in lettura e scrittura (l'impostazione è controllata dall'esistenza o meno del file nascosto.dreamboxsetupdone e per le ragioni di questa impostazione vedi la sezione successiva riguardo gli utenti preimpostati sul sistema) 2) Ad ogni avvio imposta i permessi su /tmp in modo tale che il gruppo admin abbia i permessi in lettura e scrittura (per i motivi vedi anche in questo caso la sezione successiva riguardo gli utenti preimpostati sul sistema) ed in modo adeguato i permessi su importanti files per la sicurezza. 3) Carica i moduli del kernel necessari per il funzionamento di AppleTalk. 4) Prima dell'avvio dei servers di rete esegue una modifica al volo dei files di configurazione /var/etc/hosts e /var/etc/smb.conf per il corretto funzionamento di Netatalk e Samba e forza Samba (che eventualmente è stato già avviato da Enigma) a ricaricare la configurazione. Ho trovato quest'ultimo passo necessario affinché funzionasse (almeno su Mac) il browsing delle condivisioni di rete, sia quelle attivate da Samba che quelle attivate da Netatalk. Osservo infatti che fino ad ora, con le immagini da me provate e con Mac OS X come client, il browsing Samba non ha mai funzionato, in altri termini non è mai apparso il nome del Dreambox nella cartella Network del Mac. Un ruolo essenziale è giocato dal file /var/etc/hosts che, nella configurazione di default è impostato in modo scorretto, dal momento che sia al nome localhost che al nome Dreambox è associato l'indirizzo dell'interfaccia di loopback Ad ogni modo lo script start_daemons dovrebbe essere ben commentato e per ulteriori dettagli basta leggerlo. Anche il loop finale che lancia Enigma e precedentemente descritto è stato incorporato in uno script a parte (start_enigma) lanciato in background dallo script principale rcs subito prima di start_daemons. Questa modifica forse non era proprio necessaria (lo script start_daemons dovrebbe funzionare anche se lanciato prima del loop finale in rcs), ma avendo ormai imboccato una strada ho cercato, anche per ragioni estetiche, di perseguirla fino in fondo. La logica vorrebbe infatti che, anche se alcuni scripts sono lanciati in background, la sequenza finale di avvio del Dreambox fosse: avvia Enigma (che imposta la rete) -> avvia i servers di rete -> avvia lo script /var/etc/init (customizzazione da parte dell'utente). Purtroppo non ho potuto spostare /var/etc/init in fondo alla procedura di avvio in quanto ho riscontrato che tale spostamento interferisce negativamente con fwpro qualora l'immagine sia installata su pen USB o hard disc. Probabilmente fwpro, che modifica lo script rcs, fa delle assunzioni precise sulla posizione di alcuni elementi in rcs. Il risultato, spostando /var/etc/init in fondo alla sequenza di avvio, è che ogni volta che il Dreambox viene avviato, dopo qulache secondo si rispegne. La sequenza finale di avvio è quindi: avvia lo script /var/etc/init (customizzazione da parte dell'utente) -> avvia Enig- 17

18 ma (che imposta la rete) -> avvia i servers di rete. Ho voluto entrare nei dettagli delle modifiche apportate alla procedura di avvio perché penso che oltre a poter essere di aiuto agli utenti meno smaliziati, possono essere uno spunto per chiunque abbia la necessità di creare uno script di init di customizzazione per una qualsiasi immagine e per il quale sia importante conoscere stato e configurazione della rete. L'intera procedura di avvio probabilmente non è sufficientemente robusta (soprattutto se pensiamo a quello che siamo abituati a vedere su Mac OS X, il cui launchd è da molti invidiato) ma dopo diversi giorni di prove sembra funzionare. Infine, è l'unica soluzione che ho trovato senza dover mettere le mani al codice di Enigma Utenti, Gruppi Preimpostati e Passwords La prima preoccupazione è stata quella di rendere inoffensivo o detto in altri termini disabilitare il superutente root. Questo è stato fatto seguendo uno dei metodi più usati nei vari ambienti Unix e cioè impostando nel file passwd, come shell di root il comando inoffensivo nologin, che semplicemente informa l'utente che l'account non è disponibile ed esce. Disabilitare root comporta necessariamente la creazione di almeno un utente con compiti amministrativi e l'introduzione di un tool che consenta di eseguire tali compiti. Il tool è naturalmente costituito dall'arcinoto comando sudo (vedi più avanti) e l'utente preimpostato per i compiti amministrativi (facente parte cioè dei sudoers) è dreamadm. Ho anche creato un'altro utente meno privilegiato: dreamuser. Le home directories dei due nuovi utenti sono rispettivamente /var/tuxbox per dreamadm e /hdd/movie per dreamuser e penso che qualcuno abbia già chiaro il perché di tale scelta. Le funzioni degli utenti e delle rispettive home directories corrispondono infatti anche a come sono state preimpostate le condivisioni per FTP, Samba e Netatalk e spiegate successivamente. Per ciascuno dei nuovi utenti ho preimpostato un gruppo con lo stesso id e nome dell'utente e che costituisce il gruppo principale dell'utente stesso ed al quale non dovrebbero essere associati altri utenti. Ho inoltre creato due gruppi che, come funzionalità corrispondono a quelle dei due utenti preimpostati. Il primo gruppo è admin (al quale appartengono root e dreamadm) mentre il secondo è dbusers (al quale appartiene dreamuser). Nell'impostazione dei gruppi mi sono ispirato allo schema usato su Mac OS X. In particolare la creazione di un gruppo unico per ogni utente con lo stesso id dell'utente garantisce una maggiore sicurezza delle home directories. Spero che l'impostazione iniziale da me data per utenti e gruppi, unitamente alle spiegazioni appena esposte, possa stabilire una linea guida ed una facilitazione per l'eventuale inserimento di nuovi utenti. La password preimpostata per tutti i nuovi utenti e l'utente root è quella a cui ormai siamo da sempre abituati e cioè Dreambox. 18

19 Suggerimenti per la sicurezza Se volete sfruttare le impostazioni di sicurezza offerte da questa immagine, naturalmente la prima cosa da fare, una volta effettuato il login con secure shell come utente dreamadm, sarà quella di cambiare le password di tutti gli utenti inviando il comando sudo passwd <nome_utente> per ognuno dei tre utenti del sistema: root, dreamadm e dreamuser. Una cosa imortante da osservare è che il comando passwd non si comporta nel modo in cui normalmente siamo abituati e l'uso di sudo è necessario. In altri termini non è possibile inviare semplicemente il comando passwd senza nome utente per cambiare la password dell'utente correntemente connesso. Questo accade perché, anche se normalmente il comando passwd ha il bit setuid impostato, sul Dreambox questo non accade e per motivi di sicurezza non conviene assolutamente impostarlo. Il comando passwd è infatti un link simbolico a busybox e impostarne il bit setuid equivale ad impostare il bit setuid di busybox che fa capo alla maggior parte dei comandi presenti sul Dreambox (vedi oltre per una descrizione del funzionamento di busybox). Riconosco che questo aspetto costituisce un limite nel caso vogliate creare nuovi utenti e consentire loro la modifica autonoma della password. Una possibile soluzione potrebbe essere quella di creare o trovare un utlity adatta allo scopo ma, attenzione!!! Un utility per il cambio password mal scritta e con il bit setuid impostato è un potenzale pericolo capace di distruggere in un batter di ciglio tutta la sicurezza faticosamente impostata. Forse ancor meglio sarebbe ricompilare Busybox senza il supporto per il comando passwd e compilare separatamente tale comando prendendolo dalle util-linux. Se questa immagine avrà un riscontro terrò in considerazione questa possibilità per un eventuale seconda versione. Scegliete le nuove passwords in modo adeguato: uno o due segni di interpunzione, presenza di maiuscole e minuscole e, soprattutto, parole difficilmente rintracciabili in un dizionario. Esistono molti metodi per costruire password di questo tipo e che allo stesso tempo siano facili da ricordare. Le passwords (come spiegato più avanti) sono memorizzate in forma cifrata nel file /var/etc/shadow. La password preimpostata di default Dreambox è quella di tipo crypt classica di UNIX (password cifrata con algoritmo DES a 56 bit). La cosa interessante è che Busybox, come default, genera le passwords con algoritmo MD5, molto più sicure delle passwords di tipo crypt e quindi, una volta modificate le passwords, queste saranno tutte cifrate con algoritmo MD5 (anche questo ormai uno standard sulla gran parte delle distribuzioni Linux/UNIX). Le passwords cifrate in MD5 possono avere lunghezza arbitraria (con passwords molto lunghe si preferisce usare il termine passphrases perché in questo caso può essere abbastanza sicuro usare la giustapposizione di parole anche presenti in un dizionario) mentre le passwords di tipo crypt sono limitate ad 8 caratteri, quelli forniti in eccesso vengono infatti eliminati dall'algoritmo. 19

20 C'è ancora di più: il comando passwd con l'opzione -a sha1 genera la password con l'algoritmo SHA1, ancora più sicuro dei precedenti. Esiste un tipo di password cifrata ancora più sicuro? La risposta è sì e si tratta delle passwords bcrypt (algoritmo blowfish) anche se tali tipi di password non sono supportate da Busybox. Usato per la prima volta su OpenBSD, l'algoritmo bcrypt si sta diffondendo ad altre distribuzioni Linux/UNIX. Penso tuttavia che le password di tipo MD5 o SHA1 fornsiscano, al momento, un livello di sicurezza adeguato per il nostro Dreambox Software Busybox Versione: (Disponibile nel CVS) Links: Come molti sapranno, Busybox è il software tuttofare del Dreambox e racchiude le funzionalità di un discreto numero di tools che sono standard sulle varie distribuzioni Linux/Unix. Le diverse funzionalità di Busybox vengono assolte in funzione del nome con cui viene invocato il comando busybox stesso. Questo viene realizzato mediante una serie di link simbolici a busybox, ognuno con il nome dell'utility rimpiazzata da busybox. Il parco di utilities standard che busybox può sostituire e che in gergo Busybox vengono chiamate applets è abbastanza ampio e viene stabilito in fase di compilazione di Busybox stessa. Visto che ora il Dreambox si rivela per quello che in realtà è sempre stato e cioè una macchina multiutente, non poteva non mancare la compilazione in Busybox degli applets per la gestione di gruppi e utenti. I nuovi applets sono: 1) adduser (aggiunta di un nuovo utente); 2) addgroup (aggiunta di un nuovo gruppo); 3) deluser (cancellazione di un utente esistente); 4) delgroup (cancellazione di un gruppo esistente). Ho tolto invece l'applet che offre le funzionalita di vi. Ho infatti inserito nell'immagine l'editor Nano molto più semplice da usare anche per i meno esperti e credo sufficiente per le eventuali operazioni di editing dei files di configurazione sul Dreambox. 20