Tutti gli articoli di Raoul Scarazzini

Un bug in npm (installer per pacchetti node.js) compromette tutti i permessi dei sistemi Linux

Facebooktwittergoogle_plusredditlinkedin

Lo scorso anno abbiamo parlato di NPM, il sistema di installazione pacchetti Node.js largamente (eufemismo) utilizzato nelle applicazioni web, e di come una patch sbagliata avesse praticamente “bloccato” internet, o quantomeno tutti i siti che facevano affidamento a questo sistema.

Bene, la notizia di oggi è che l’ultimo update distribuito per questa piattaforma cambia i permessi dei file presenti in alcune locazioni cruciali, quali /etc, /usr e /boot, costringendo quindi (a meno di non avere un backup recente ripristinabile unicamente per quanto riguarda i permessi) a reinstallare l’intero sistema.

Vien da se che il problema riguarda da vicino sviluppatori ed ingegneri software che hanno installato la recente pre-versione 5.7.0 in quanto al momento, per fare un esempio, in Fedora 27 la versione del software distribuita è la 5.6.0, ma in ogni caso il problema è rilevante e costringe a porsi diverse domande sulle modalità in cui certe componenti accedono al sistema.

Soluzioni a problemi simili non esistono: un pacchetto di installazione, sia esso rpm o deb, avrà sempre completo accesso al sistema e se all’interno delle proprie azioni di post installazione qualche burlone decidesse di aggiungere un comando come “rm -rf” ci sarebbe ben poco da fare. Ma stiamo estremizzando, sia chiaro. Una cosa del genere non è mai accaduta forse proprio perché aspetti così delicati come la creazione di pacchetti vengono testati in maniera approfondita prima di essere distribuiti.

Cosa è successo quindi questa volta? Tutto è descritto nel link riportato qui sopra, nel quale viene indicato come la release che risolve il problema, la 5.7.1 è già disponibile.

Una cosa è chiara comunque: mai usare versioni definite “pre-release” in produzione (anche se in questo caso nell’annuncio della versione questa non è stata indicata come pre release)! Se poi siete sviluppatori e non potete farne a meno beh… Succede!

Il sistema operativo scelto nel Public Cloud? RedHat Enterprise Linux!

Facebooktwittergoogle_plusredditlinkedin

Un recente sondaggio, pubblicato e (giustamente) pubblicizzato da Red Hat, ha stabilito come per i carichi di produzione all’interno dei cloud pubblici la scelta del sistema operativo da parte degli operatori sia per la maggioranza la stessa: Red Hat Enterprise Linux.

Oltre comunque ai dati in favore di Red Hat, tutti consultabili in questo pdf, il sondaggio aiuta a ricostruire quella che è in generale la situazione nei cloud pubblici oggi in nord america e in europa. Le percentuali sulla tipologia di sistema operativo sui server raccontano che Linux ha il predominio, con il 54% delle installazioni, seguito a ruota da Windows che stabilisce un 43%. La top 3 delle applicazioni vede al primo posto Applicazioni Web (12%), al secondo database MySQL (7%) ed al terzo database Oracle (sempre al 7%).

I dati iniziano a farsi interessanti nell’ambito dei tipi di workload, proponendo questo scenario: in ambiti di produzione “Business critical” il 78% dei clienti preferisce “paid Linux” ossia distribuzioni che come Red Hat necessitano di una subscription. Questa percentuale cala al 54% nel caso di produzioni a basso impatto e finisce al 40% per test e sviluppo. In generale comunque la percentuale di installato che necessita di subscription nel cloud pubblico oggi occupa il 65%.

Infine le classifica delle distribuzioni:
  1. Red Hat Enterprise Linux (RHEL) – 48%
  2. Ubuntu Server – 38%
  3. Oracle Linux – 19%
  4. SUSE Linux Enterprise Server (SLES) – 19%
  5. CentOS – 17%
Un ottimo riscontro quindi per Red Hat nello specifico, ma anche per Linux in generale a dimostrazione di come il dominio nel cloud del Pinguino non sia minimamente in discussione. Che poi si tratti di centri elaborazione dati locali o cloud pubblici per il cliente finale pare non esserci differenza, una distribuzione che si paga è sinonimo di maggiore affidabilità. Cosa ne pensate?

LinuxJournal e la classifica della migliore distro Linux 2018: chi sta vincendo?

Facebooktwittergoogle_plusredditlinkedin

Come abbiamo raccontato poco tempo fa le sorti di una delle più famose riviste Linux sono state decise, e la sopravvivenza della stessa è stata alla fine garantita. Questa ventata di freschezza ha portato ad una rivitalizzazione della comunità LinuxJournal, perciò analizzare i risultati del sondaggio che chiede quale sia la migliore distro del 2018 è molto interessante, poiché i numeri non sono così bassi e la statistica comincia ad avere un suo peso.

Nel momento in cui scriviamo il sondaggio ha avuto 9403 votanti e la classifica provvisoria, per le prime cinque posizioni è la seguente:

  1. Debian con il 33% dei voti (3089)
  2. Fedora con il 12% dei voti (1111)
  3. OpenSuSe con il 12% dei voti (1101)
  4. Arch Linux con il 9% (857)
  5. Ubuntu con il 9% (826)

Al di là del dominio netto di Debian, che tutto sommato stupisce poco, a far notizia sono i bassi numeri relativi a Ubuntu.

Il trend negativo della distribuzione di casa Canonical è sotto gli occhi di tutti e certamente le recenti notizie relative alla volontà di vendere da parte di Shuttleworth ed al cambio di direzione sul motore desktop che ora è GNOME non paiono aver contribuito positivamente alla popolarità generale della distribuzione.

Il sondaggio non è ancora chiuso, perciò ognuno può ancora dire la sua. Partecipate!

Razer (produttore di hardware per giochi) è molto chiaro: non ci importa di Linux!

Facebooktwittergoogle_plusredditlinkedin

L’apertura di questo recente post dal blog di GNOME lascia poco spazio all’immaginazione:

Don’t buy hardware from Razer and expect firmware updates to fix security problems on Linux.

Non comprate hardware da Razer aspettandovi aggiornamenti che risolvano problemi di sicurezza in Linux.

Prima di tutto: chi sono i tizi di Razer? L’azienda produce hardware dedicato al gaming, attrezzature videoludiche che dovrebbero aiutare i giocatori ad avere un’esperienza definitiva in termini di prestazioni.

Richard, autore del post, racconta come dopo aver proposto la propria collaborazione per aumentare il grado di supporto di Linux all’interno delle soluzioni Razor (in seguito alla chiamata alle armi dell’azienda stessa) si sia sentito candidamente rispondere:

I have discussed your offer with the dedicated team and we are thankful for your enthusiasm and for your good idea.
I am afraid I have also to let you know that at this moment in time our support for software is only focused on Windows and Mac.

Traduzione: grazie, ma al momento ci preoccupiamo unicamente di Windows e Mac. Il che lascia davvero perplessi. Non tanto per la conferma di quella consapevolezza ormai assodata (se giochi, Linux scordatelo), ma soprattutto perché era stata l’azienda stessa a proporre la collaborazione del mondo open per creare soluzioni vicine all’universo del Pinguino.

Stratagemmi commerciali? Smentite in arrivo? Staremo a vedere, nel frattempo se volete giocare a qualcosa con Linux, che ne dite di provarlo su Nintendo Switch?

I sistemi BSD sono a rischio estinzione?

Facebooktwittergoogle_plusredditlinkedin

Quella di J.M. Porup è una riflessione che farà storcere il naso a molti, e nasce da una semplice domanda:

Are the BSDs dying? Some security researchers think so

I BSD stanno morendo? Alcuni ricercatori di sicurezza lo pensano

La motivazione è altrettanto semplice: non ci sono abbastanza occhi nel codice BSD. In comparazione a Linux, il numero di vulnerabilità al kernel riportate per BSD è drammaticamente più basso.

Se da un lato questo dato può sembrare positivo (“BSD è più sicuro!”) i ben accorti sanno che è vero l’esatto contrario. Un ricercatore di IOActive, Ilja van Sprundel, in questo video dispiega un po’ di numeri.

Basandosi sui dati disponibili fino al luglio 2017, il totale delle vulnerabilità del kernel scoperte sono state nell’anno 346, e la cosa interessante è che controllando oggi gli stessi dati il valore è ancora più impressionante, 453! Bene, per BSD i numeri sono totalmente diversi, premettendo che cvedetails.com non li raccoglie (almeno non nella stessa forma del link illustrato sopra), Sprundel ha raggruppato le diverse fonti, concludendo che nel 2017 il numero di bug trovati è stato il seguente:

  • FreeBSD -> 1
  • NetBSD -> 3
  • OpenBSD -> 13

Fermo restando quindi che delle tre distribuzioni la più sicura apparentemente sembra essere OpenBSD il dato rimane: a fronte di 453 bachi trovati per Linux i *BSD non sono riusciti ad arrivare a venti… Qualcosa di anomalo certamente c’è. Quindi tornando alla domanda di apertura: i BSD stanno morendo? La popolarità agisce sulla sicurezza, si sa. E allora sicuramente i sistemi *BSD sono certamente poco popolari, ma questa non è propriamente una novità.

Ma poco popolare è diverso da estinto… O forse no?

Nuovi orizzonti per difendersi da Meltdown e Spectre, ecco LKRG, protettore del Kernel Linux!

Facebooktwittergoogle_plusredditlinkedin

Mitigare o non mitigare. Dopo Meltdown e Spectre è questo il problema, ma come diciamo da tempo c’è tutto uno spettro di possibilità di attacco ancora inesplorate che diventeranno attualità da un giorno con l’altro.

E’ per questo che suona positiva la notizia riportata dal team LKRG che ha reso pubblica la prima release del progetto, la 0.0, disponibile per il download.

Nato nel 2011, quindi a dispetto di quel 0.0 del numero di release non certo un progetto giovane, LKRG si pone come una guardia operativa dei processi eseguiti dal Kernel. Di fatto si tratta di un modulo vero e proprio che effettua controlli di integrità del Kernel Linux e rileva vulnerabilità di sicurezza ed exploit contro lo stesso.

La volontà dei creatori è quella di rilevare gli attacchi ed agire mentre il Kernel è in esecuzione e quando vengono stabilite e verificate le credenziali di accesso.

Certo, come descrive questo articolo di bleepingcomputer.com  il modulo ha un paio di svantaggi decisamente pesanti:

  1. Come gli stessi creatori del progetto affermano, trattandosi di un modulo, LKRG è bypassabile per design, e quindi ha dei limiti impliciti di utilizzo;
  2. L’impatto sulle performance è piuttosto consistente, 6,5%. Anche se gli sviluppatori hanno già avvertito che tale dato andrà a ridursi man mano che lo sviluppo evolverà;

Insomma, una soluzione imperfetta le cui potenzialità però risultano parecchie, ma visti i tempi che corrono è sicuramente un buon passo avanti per sentirsi più protetti.

La nextbigthing? Dimenticate OpenStack, retrogradi! Arrivano le architetture ServerLess!

Facebooktwittergoogle_plusredditlinkedin

Ci siamo, il prossimo passo per l’evoluzione, il mondo migliore che tutti ci aspettiamo, il paradiso in terra è dietro l’angolo: le architetture ServerLess!

L’articolo di techrepublic di cui vi parliamo si apre con questa affermazione, ripresa dal blog CloudOpinion:

“Using containers today is like using CloudStack or OpenStack in 2012. Exciting, but limited future potential.”

Utilizzare i container oggi è come utilizzare CloudStack o OpenStack nel 2012, eccitante, ma litante nei confronti degli sviluppi futuri.

Quindi non solo OpenStack è obsoleto perché ci sono i container, ma loro stessi sono pronti ad essere sostituiti.

Insomma, ancora non tutti hanno capito cosa sia il cloud, OpenStack o di cosa tratti Kubernetes, che è già ora di imparare un nome strano come quello di AWS Lambda.

Tornando all’affermazione in apertura: alzi la mano chi nel 2012 ha avuto modo di lavorare su OpenStack in un ambiente di produzione. Bene, ora alzi la mano chi oggi lavora in un ambiente di produzione OpenStack. Non vi vedo, ma spero molti lo abbiano fatto, perché altrimenti siamo rovinati.

Il mondo IT odierno pare avere un grosso problema: le evoluzioni vanno più veloce del loro stesso utilizzo. La chiosa dell’articolo fa riflettere:

Remember OpenStack? It was supposed to be a magical open source elixir for turning old-school enterprise data centers into new-school “private clouds.” It didn’t work. Instead of OpenStack displacing AWS, the dream of many a legacy tech vendor, AWS mowed it down, bringing along an army of developers who sought the true promise of the cloud: Convenience.

Nella sostanza, quindi, OpenStack non ha funzionato, Amazon ha combattuto e, almeno secondo gli autori dell’articolo, ha vinto perché anziché cercare di competere con OpenStack ha reso più competitivo il proprio prodotto, non vendendo più server, ma servizi. Spazio per applicazioni. Workload.

Bisogna solo imparare ad usare la tecnologia. Quindi rimbocchiamoci le maniche, finito con OpenStack ci sono i container con Kubernetes e dopo tutti sotto con Lambda!

Certi giorni è proprio difficile essere informatici.

Meltdown e Spectre sono un problema per tutti, per Linux di più?

Facebooktwittergoogle_plusredditlinkedin

Lo avevamo detto dall’inizio: per il problema Meltdown e Spectre il meglio aveva ancora da venire. Ed in effetti le previsioni sono state rispettate. Ecco quindi gli ultimi aggiornamenti.

Per quanto poco Linus Torvalds dica che il ritardo nell’uscita dell’ultima release del Kernel dipenda dal problema Meltdown/Spectre (ne abbiamo parlato ieri qui), rimane il fatto che era dal 2011 che una release non arrivava alla RC9.

È facile comunque immaginare come l’argomento sia di estrema attualità per il creatore di Linux, che non perde occasione per affermare come la responsabilità di Intel, mitigation o no, sia totale. Leggendo messaggi come questo, densi di “BULLSHIT” o “WHAT THE F*CK IS GOING ON?”, il punto è chiaro:

So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint.

Quindi anziché risolvere il problema, passano la patata bollente a noi. E lo stanno facendo in maniera totalmente sbagliata, persino da un punto di vista tecnico.

Nel frattempo Red Hat si è trovata costretta ad effettuare un revert delle precedenti patch relative a Spectre e Meltdon. Come infatti indica la soluzione pubblicata sul sito ufficiale di Red Hat:

Red Hat is no longer providing microcode to address Spectre, variant 2, due to instabilities introduced that are causing customer systems to not boot

Red Hat non fornisce più il microcode che sistema la variante 2 di Spectre a causa dell’instabilità introdotta che non permetteva di avviare i sistemi dei clienti.

Insomma, la guerra è ancora in corso e ci sarà ancora molto, moltissimo da scoprire. E se siete amanti di 007, apprezzerete questo sito https://skyfallattack.com/ nel quale, abbastanza misteriosamente, vengono previste nuove ed entusiasmanti avventure per tutti gli agenti (mica troppo) segreti dell’IT. Noi.