Nel 2021, ci sono più ragioni per cui le persone amano Linux che mai. In questa serie, condividerò 21 diversi motivi per utilizzare Linux. Questo articolo discute l'influenza di Linux sulla sicurezza del software open source.
Una virtù spesso elogiata del software open source è che il suo codice può essere rivisto (o "verificato", come amano dire i professionisti della sicurezza) da chiunque e da tutti. Tuttavia, se chiedi a molti utenti open source quando è stata l'ultima volta che hanno esaminato il codice, potresti ottenere risposte che vanno da uno sguardo vuoto a un mormorio imbarazzato. Inoltre, ci sono alcune applicazioni open source davvero grandi là fuori, quindi può essere difficile rivedere ogni singola riga di codice in modo efficace.
Estrapolando da queste verità un po' scomode, devi chiederti:quando nessuno guarda il codice, importa davvero se è aperto o meno?
Dovresti fidarti dell'open source?
Tendiamo a fare una banale ipotesi nell'informatica per hobby che l'open source sia "più sicuro" di qualsiasi altra cosa. Non si parla spesso di cosa significhi, di quale sia la base del confronto ("più" sicuro di cosa?), o di come sia stata raggiunta la conclusione. È un'affermazione pericolosa da fare perché implica che fintanto che chiami qualcosa open source , eredita automaticamente e magicamente una maggiore sicurezza. Non è di questo che si occupa l'open source e, in effetti, è ciò che la sicurezza dell'open source è fortemente contraria.
Non dovresti mai presumere che un'applicazione sia sicura a meno che tu non abbia verificato personalmente e compreso il suo codice. Dopo averlo fatto, puoi assegnare ultimate trust a tale applicazione. La massima fiducia non è una cosa che fai su un computer; è qualcosa che fai nella tua mente:ti fidi del software perché scegli di credere che sia sicuro, almeno finché qualcuno non trova un modo per sfruttare quel software.
Sei l'unica persona che può riporre la massima fiducia in quel codice, quindi ogni utente che desidera quel lusso deve controllare il codice da solo. Credere sulla parola di qualcun altro non conta!
Quindi, finché non hai verificato e compreso una base di codice per te stesso, il livello di affidabilità massimo che puoi dare a un'applicazione è uno spettro che va da approssimativamente, per niente affidabile a abbastanza affidabile . Non c'è nessun cheat sheet per questo. È una scelta personale che devi fare per te stesso. Se hai sentito da persone di cui ti fidi fortemente che un'applicazione è sicura, allora potresti fidarti di quel software più di quanto ti fidi di qualcosa per cui non hai ricevuto consigli affidabili.
Poiché non puoi controllare il codice proprietario (non open source), non puoi mai assegnarlo ultimate trust .
Legge di Linus
Più risorse Linux
- Comandi Linux cheat sheet
- Cheat sheet sui comandi avanzati di Linux
- Corso online gratuito:Panoramica tecnica RHEL
- Cheat sheet della rete Linux
- Cheat sheet di SELinux
- Cheat sheet dei comandi comuni di Linux
- Cosa sono i container Linux?
- I nostri ultimi articoli su Linux
La realtà è che non tutti sono programmatori e non tutti coloro che sono programmatori hanno il tempo da dedicare alla revisione di centinaia e centinaia di righe di codice. Quindi, se non hai intenzione di controllare il codice da solo, devi scegliere di fidarti (in una certa misura) delle persone che lo fanno codice di controllo.
Quindi esattamente chi controlla il codice, comunque?
La legge di Linus afferma che dato un numero sufficiente di occhi, tutti gli insetti sono superficiali , ma non sappiamo davvero quanti bulbi oculari siano "abbastanza". Tuttavia, non sottovalutare il numero. Il software è molto spesso recensito da più persone di quanto tu possa immaginare. Lo sviluppatore o gli sviluppatori originali ovviamente conoscono il codice che hanno scritto. Tuttavia, l'open source è spesso uno sforzo di gruppo, quindi più il codice è aperto, più sviluppatori di software finiscono per vederlo. Uno sviluppatore deve rivedere le parti principali del codice di un progetto perché deve imparare una base di codice per scrivere nuove funzionalità per esso.
I packager open source vengono anche coinvolti in molti progetti per renderli disponibili per una distribuzione Linux. A volte un'applicazione può essere impacchettata quasi senza dimestichezza con il codice, ma spesso un packager acquisisce familiarità con il codice di un progetto, sia perché non vuole firmare un software di cui non si fida sia perché potrebbe dover apportare modifiche per farlo compilare correttamente. I bug reporter e i triager a volte acquisiscono familiarità con una base di codice mentre cercano di risolvere anomalie che vanno da stranezze a gravi arresti anomali. Naturalmente, alcuni bug reporter rivelano inavvertitamente le vulnerabilità del codice non rivedendolo da soli, ma portando l'attenzione su qualcosa che ovviamente non funziona come previsto. Gli amministratori di sistema spesso acquisiscono familiarità con il codice di un importante software su cui fanno affidamento gli utenti. Infine, ci sono ricercatori di sicurezza che scavano nel codice esclusivamente per scoprire potenziali exploit.
Fiducia e trasparenza
Alcune persone presumono che, poiché il software principale è composto da centinaia di migliaia di righe di codice, sia praticamente impossibile da controllare. Non lasciarti ingannare dalla quantità di codice necessaria per eseguire un'applicazione. In realtà non devi leggere milioni di righe. Il codice è altamente strutturato e i difetti sfruttabili raramente sono solo una singola riga nascosta tra milioni di righe; di solito sono coinvolte intere funzioni.
Ci sono delle eccezioni, ovviamente. A volte una grave vulnerabilità viene abilitata con una sola chiamata di sistema o collegandosi a una libreria difettosa. Fortunatamente, questo tipo di errori è relativamente facile da notare, grazie al ruolo attivo dei ricercatori di sicurezza e dei database di vulnerabilità.
Alcune persone indicano bug tracker, come il sito Web Common Vulnerabilities and Exposures (CVE), e deducono che in realtà è chiaro come il giorno che l'open source non è sicuro. Dopotutto, centinaia di rischi per la sicurezza vengono presentati contro molti progetti open source, aperti agli occhi di tutti. Non lasciarti ingannare, però. Solo perché non riesci a vedere i difetti nel software chiuso non significa che quei difetti non esistano. In effetti, sappiamo che lo fanno perché anche contro di loro vengono archiviati exploit. La differenza è che tutti gli exploit contro le applicazioni open source sono disponibili per gli sviluppatori (e gli utenti) in modo da poter mitigare questi difetti. Fa parte del sistema che aumenta la fiducia nell'open source e manca del tutto al software proprietario.
Potrebbero non esserci mai occhi "abbastanza" su nessun codice, ma più forte e diversificata è la community attorno al codice, maggiori sono le possibilità di scoprire e correggere i punti deboli.
Fiducia e persone
In open source, la probabilità che molti sviluppatori, ciascuno al lavoro sullo stesso progetto, abbiano notato qualcosa di non sicuro ma sono rimasti tutti ugualmente in silenzio su quel difetto è considerato basso perché gli umani raramente concordano reciprocamente di cospirare in questo modo. Abbiamo visto quanto il comportamento umano possa essere disarticolato di recente con la mitigazione del COVID-19:
- Abbiamo tutti identificato un difetto (un virus).
- Sappiamo come prevenirne la diffusione (rimanete a casa).
- Eppure il virus continua a diffondersi perché una o più persone si discostano dal piano di mitigazione.
Lo stesso vale per i bug nel software. Se c'è un difetto, qualcuno che lo nota lo porterà alla luce (a patto, ovviamente, che qualcuno lo veda).
Tuttavia, con il software proprietario, può esserci un'alta probabilità che molti sviluppatori che lavorano su un progetto notino qualcosa di non sicuro ma rimangano ugualmente silenziosi perché il modello proprietario si basa sulle buste paga. Se uno sviluppatore denuncia un difetto, allora quello sviluppatore potrebbe nel migliore dei casi danneggiare la reputazione del software, diminuendo così le vendite o, nel peggiore dei casi, potrebbe essere licenziato dal proprio lavoro. Gli sviluppatori pagati per lavorare sul software in segreto non tendono a parlare dei suoi difetti. Se hai mai lavorato come sviluppatore, probabilmente hai firmato un accordo di non divulgazione e ti è stato insegnato l'importanza dei segreti commerciali e così via. Il software proprietario incoraggia, e più spesso impone, il silenzio anche di fronte a gravi difetti.
Fiducia e software
Non fidarti del software che non hai controllato.
Se devi fidarti di un software che non hai controllato, scegli di fidarti del codice esposto a molti sviluppatori che in modo indipendente potrebbero parlare di una vulnerabilità.
L'open source non è intrinsecamente più sicuro del software proprietario, ma i sistemi in atto per risolverlo sono pianificati, implementati e dotati di personale molto meglio.