Linux, scoperto bug critico in attività da 9 anni

[Piedone1113]

Originariamente inviato da cdimauro

Purtroppo non c'è niente che ti garantisca che un numero sufficiente di occhi possa trovare proprio TUTTI i bug di un software. Specialmente coi software che sono via via sempre più complicati.

Anche le leggi probabilistiche sono comunque... leggi. Dietro ci sono formule e teoremi.

Inoltre stai assumendo che tutti gli "occhi" siano uguali: non è così.

Ma un insieme infinito di occhi è composto da diversi sottoinsiemi infiniti di occhi (quindi ci sarà comunque un sottinsieme infinito di occhi che ci vede doppio di quello normale e trovarà i bug anche che se il sottinsieme orbo non sarà in grado di trovare nemmeno il proprio pisello per urinare).
La legge è sempre valida per occhi che cercano bug tendenti ad infinito.
Per il resto questo stesso assunto ci dice che per quanti occhi (di un insieme finito) possano cercare bug non è certo che li trovino tutti (e qua torniamo alla tua speranza ), quindi non sono sufficienti.

[fano]

Ma appunto perchè il kernel di Linuxe monolitico composto da milioni di righe di codice (driver di schede video morte da secoli, porte seriali*, porte parallele), io non credo che nemmeno Linus Torvalds lo comprenda tutto!

Questo è un altra cosa che va contro la "Legge di Linus"

* ma con2 driver bacato visto che non supporta RS485 ed ho dovuto fare kludge io a livello utente

[Piedone1113]

Originariamente inviato da fano

Ma appunto perchè il kernel di Linuxe monolitico composto da milioni di righe di codice (driver di schede video morte da secoli, porte seriali*, porte parallele), io non credo che nemmeno Linus Torvalds lo comprenda tutto!

Questo è un altra cosa che va contro la "Legge di Linus"

* ma con2 driver bacato visto che non supporta RS485 ed ho dovuto fare kludge io a livello utente

Capisco il tuo punto di vista, ma un kernel monolitico non porta solo svantaggi, come un microkernel non porta solo vantaggi.
Per l'open di massa (come è linux) è preferibile un kernel monolitico piuttosto che un microkernel.
Io non sto parlando di efficenza o bug, ma di gestione dello sviluppo.
Ogni software può essere scritto meglio, ma a furia di migliorarlo (per quante risorse di uomini e mezzi tu abbia) sarà in perenne beta.
Un os moderno a microkernel non può che essere proprietario e sviluppato in modo closed.

[LMCH]

Originariamente inviato da cdimauro

O semplicemente perché è il più supportato (fra i s.o. open), e dunque è comodo poterlo sfruttare.

E' anche il più supportato, altro aspetto non da poco, ma non l'unico.
Di solito non è che un sistema operativo diventa il più supportato così per caso, deve avere sufficienti caratteristiche positive da attirare una community di sviluppatori di buona qualità.

Originariamente inviato da cdimauro

La crittografia, invece, è una cosa completamente diversa.

Com'è anche vero che nessuno sano di mente metterebbe in giro lo schema dell'antifurto di casa sua, solo perché milioni di occhi potrebbero trovare eventuali falle nella sua sicurezza...

I principi di base sono gli stessi, non a caso chi progetta un BUON antifurto parte dall'idea che i possibili intrusi conoscano come è fatto, ma che non conoscano i codici di accesso, quelli fanno parte dei parametri dell'implementazione, non dell'algoritmo/progetto (algoritmo nel caso di software e progetto in caso di hardware).

Avendo avuto a che fare con lo sviluppo di software per sistemi domotici, relativi sistemi di allarme ed analisi di prodotti di fornitori e della concorrenza
non ti dico quanti di essi sono delle pachianate assurde proprio perchè si basano sulla "security by obscurity"
(pieni zeppi di dettagli implementativi vulnerabili, basati sul "tanto nessuno lo saprà mai").

[cdimauro]

Originariamente inviato da Piedone1113

Capisco il tuo punto di vista, ma un kernel monolitico non porta solo svantaggi, come un microkernel non porta solo vantaggi.
Per l'open di massa (come è linux) è preferibile un kernel monolitico piuttosto che un microkernel.
Io non sto parlando di efficenza o bug, ma di gestione dello sviluppo.
Ogni software può essere scritto meglio, ma a furia di migliorarlo (per quante risorse di uomini e mezzi tu abbia) sarà in perenne beta.
Un os moderno a microkernel non può che essere proprietario e sviluppato in modo closed.

Haiku è l'esempio più eloquente, ma ce ne sono altri.

Originariamente inviato da LMCH

E' anche il più supportato, altro aspetto non da poco, ma non l'unico.
Di solito non è che un sistema operativo diventa il più supportato così per caso, deve avere sufficienti caratteristiche positive da attirare una community di sviluppatori di buona qualità.

Sulle caratteristiche / feature nulla da dire, ma questo deriva dal supporto che ha ricevuto e dagli sviluppatori che hanno scritto un sacco di codice.

In ogni caso in tutto ciò continua a sfuggirmi, da questo:

"la sua superiorità qualitativa sotto TUTTI gli aspetti importanti"

che avevi scritto, dove sarebbe dimostrata la superiorità qualitativa (e cosa intendi con ciò).

I principi di base sono gli stessi, non a caso chi progetta un BUON antifurto parte dall'idea che i possibili intrusi conoscano come è fatto, ma che non conoscano i codici di accesso, quelli fanno parte dei parametri dell'implementazione, non dell'algoritmo/progetto (algoritmo nel caso di software e progetto in caso di hardware).

Avendo avuto a che fare con lo sviluppo di software per sistemi domotici, relativi sistemi di allarme ed analisi di prodotti di fornitori e della concorrenza
non ti dico quanti di essi sono delle pachianate assurde proprio perchè si basano sulla "security by obscurity"
(pieni zeppi di dettagli implementativi vulnerabili, basati sul "tanto nessuno lo saprà mai").

L'unica similitudine in questo caso riguarda esclusivamente il meccanismo che fa uso di codici.

Per il resto, se pubblichi l'intero schema qualcuno potrebbe trovare il modo di aggirare o eliminare il blocco che fa uso dei codici.

La similitudine, infatti è la seguente: il meccanismo dei codici sta all'algoritmo di criptazione, come il resto del sistema d'allarme sta al resto della piattaforma software.

[GTKM]

Originariamente inviato da LMCH

E' anche il più supportato, altro aspetto non da poco, ma non l'unico.
Di solito non è che un sistema operativo diventa il più supportato così per caso, deve avere sufficienti caratteristiche positive da attirare una community di sviluppatori di buona qualità.

Credo che, soprattutto nei primi anni, un gran peso l'abbia avuto la GPL.

Originariamente inviato da LMCH

I principi di base sono gli stessi, non a caso chi progetta un BUON antifurto parte dall'idea che i possibili intrusi conoscano come è fatto, ma che non conoscano i codici di accesso, quelli fanno parte dei parametri dell'implementazione, non dell'algoritmo/progetto (algoritmo nel caso di software e progetto in caso di hardware).

Avendo avuto a che fare con lo sviluppo di software per sistemi domotici, relativi sistemi di allarme ed analisi di prodotti di fornitori e della concorrenza
non ti dico quanti di essi sono delle pachianate assurde proprio perchè si basano sulla "security by obscurity"
(pieni zeppi di dettagli implementativi vulnerabili, basati sul "tanto nessuno lo saprà mai").

Credo che il punto sia questo: un algoritmo sicuro rimane tale pure se lo conoscono nel dettaglio tutti, in quanto di solito la sicurezza è data dalle caratteristiche matematiche dello stesso. Il problema sta nell'implementazione, che potrebbe contenere approssimazioni e/o errori. A quel punto, chi mi dice che la community lo noti prima dei malintenzionati?
Abbiamo già rimosso Heartbleed?

[Piedone1113]

Originariamente inviato da cdimauro

Haiku è l'esempio più eloquente, ma ce ne sono altri.

.

Non ho capito?
Forse confermi quello che ho scritto indicando haiku come os open a microkernel in pre beta da 15 anni?

[freesailor]

Originariamente inviato da LMCH

Verba volant, scripta manent.

Appunto.
Basta andare a leggere e si capisce la sottovalutazione di Torvalds sull'importanza della sicurezza.

Originariamente inviato da LMCH

È iniziato così, MA POI poi con il contributo fondamentale di un esercito di altri sviluppatori è diventato qualcosa di molto più grande.
La "mentalità della comunità Linux" è evidente in quello che ha prodotto: un sistema operativo usato in ogni genere di settore proprio per la sua superiorità qualitativa sotto TUTTI gli aspetti importanti.

Linux è usato in tutti i settori MENO quello principale, il desktop, dove ha percentuali da prefisso telefonico.

Linux è usato così tanto, ma solo nei settori dove la "human interface" non è veramente importante, semplicemente perchè C'E' GIA' ed è GRATUITO, non è necessario reinventarsi un SO da zero.

La mentalità della comunità Linux è quella per cui fra dieci anni sarai ancora qui a chiederti come mai dal 2017 al 2027 nessun'anno è stato "l'anno di Linux".

La mentalità della comunità Linux è quella per cui non sto neppure a perdere tempo a discutere con un linaro, so già che vive fuori dal mondo e che continuerà a non saper distinguere tra software professionale e software da smanettoni (che non è la totalità in Linux ma è tanta parte). E dato che nel campo del software professionale ci lavoro da 34 anni, e da quindici nella sicurezza IT, credo proprio di avere le basi per capirlo.

Quindi, divertiti con Linux, se ti diverte. Mica voglio rompere il giocattolo a nessuno.
Io mi fermo qui.

[cdimauro]

Originariamente inviato da Piedone1113

Non ho capito?
Forse confermi quello che ho scritto indicando haiku come os open a microkernel in pre beta da 15 anni?

Il microkernel è pronto da un pezzo. Se non ricordo male, è "soltanto" tutto il resto che è in beta.

[Nurabsa]

quanti ricordi sto linux,

na volta per cofigurare l ethernet su gnome certi bestemmioni molti molti anni fa
Mi ha sempre dato l impressione di un so incompleto poco molto poco user friedly

magari mi sbaglio oggi è migliorato

[Piedone1113]

Originariamente inviato da cdimauro

Il microkernel è pronto da un pezzo. Se non ricordo male, è "soltanto" tutto il resto che è in beta.

Forse non mi è chiara la differenza tra monolitico e micro kernel.
Nel primo c'è tutto il brodo "primordiale" pronto ad essere usato, nel secondo ci sono gli attrezzi per cucinare a cui vanno aggiunti da fuori tutti gli ingredienti.
Quindi un microkernel da solo inizializza ed utilizza solo un numero ristretto di chiamate, mentre la totalità è demandata a moduli (?) che avviano ed inizializzano funzionalità hardware e logiche aggiuntive.
Credo quindi che un microkernel da solo sia del tutto inutile perchè deve essere coadiuvato dal layer successivo.
Che sia definitivo il microkernel, ma che non lo siano i moduli successivi significa che la totalità del kernel non è pronto.
Se la guida è direttiva senza che ci siano iniziative esterne il microkernel è fattibile ed auspicabile, ma nel mondo open si creano solo revisioni su revisioni dei vari moduli portando ad un perenne beta o peggio ancora alpha.

[cdimauro]

Il micro-kernel offre soltanto una serie (molto) limitata di servizi & API, lasciando tutto il resto a moduli che girano in user-space.

Quindi è molto più facile da scrivere e mantenere, rispetto ai classici kernel monolitici.

E' ovvio che quello che non va nel micro-kernel deve comunque essere implementato in user-space.

[GTKM]

Originariamente inviato da Piedone1113

Forse non mi è chiara la differenza tra monolitico e micro kernel.
Nel primo c'è tutto il brodo "primordiale" pronto ad essere usato, nel secondo ci sono gli attrezzi per cucinare a cui vanno aggiunti da fuori tutti gli ingredienti.
Quindi un microkernel da solo inizializza ed utilizza solo un numero ristretto di chiamate, mentre la totalità è demandata a moduli (?) che avviano ed inizializzano funzionalità hardware e logiche aggiuntive.
Credo quindi che un microkernel da solo sia del tutto inutile perchè deve essere coadiuvato dal layer successivo.
Che sia definitivo il microkernel, ma che non lo siano i moduli successivi significa che la totalità del kernel non è pronto.
Se la guida è direttiva senza che ci siano iniziative esterne il microkernel è fattibile ed auspicabile, ma nel mondo open si creano solo revisioni su revisioni dei vari moduli portando ad un perenne beta o peggio ancora alpha.

Ma questa non è colpa del microkernel in sé. Semmai il problema sta nel modello di sviluppo. Il design a microkernel è sicuramente più "elegante" rispetto al pappone monolitico, oltre che, come ha già detto cdimauro, più facile da mantenere.

[Piedone1113]

Originariamente inviato da GTKM

Ma questa non è colpa del microkernel in sé. Semmai il problema sta nel modello di sviluppo. Il design a microkernel è sicuramente più "elegante" rispetto al pappone monolitico, oltre che, come ha già detto cdimauro, più facile da mantenere.

Modello di sviluppo?

Originariamente inviato da Piedone1113

Capisco il tuo punto di vista, ma un kernel monolitico non porta solo svantaggi, come un microkernel non porta solo vantaggi.
Per l'open di massa (come è linux) è preferibile un kernel monolitico piuttosto che un microkernel.
Io non sto parlando di efficenza o bug, ma di gestione dello sviluppo.
Ogni software può essere scritto meglio, ma a furia di migliorarlo (per quante risorse di uomini e mezzi tu abbia) sarà in perenne beta.
Un os moderno a microkernel non può che essere proprietario e sviluppato in modo closed.

Che io reputo imputabile all'approccio OPEN.
Certamente un microkernel sarà più semplice, più sicuro e stabile, ma in uno sviluppo open dove tutti si scrivono i propri moduli (che magari fanno crashare i moduli di un'altro servizio e/o periferica perchè nel frattempo riscritti da altri) preferisco l'approccio monolitico che mi sembra più semplice da gestire (sviluppo e stesura con relative modifiche).
Ho usato apposta il termine Brodo Primordiale per indicare il minestrone che è il monolitico.
Per sviluppare un os su microkernel non si può utilizzare il modello open per le inefficienze proprie delle forza di tale modello.
Spero di essermi fatto capire anche se ho espresso la mia opinione in modo contorto.

[cdimauro]

E' l'esatto contrario: con una piattaforma basata su micro-kernel anche la gestione dei moduli diventa più semplice e testabile. Infatti se un modulo non risponde più, il (micro)kernel può benissimo farlo ripartire.

L'unico vantaggio di un kernel monolitico è che la comunicazione fra kernel e moduli è più veloce, perché non si deve passare da kernel space a user space, e viceversa.

[fano]

Allora prima di tutto partiamo dalle basi che cos'è un microkernel?
https://en.wikipedia.org/wiki/Microkernel

Questo è come è stato sviluppato Haiku OS:
https://en.wikipedia.org/wiki/Haiku_...em)#Technology

in realtà Haiku pecca forse di troppa modestia quella che loro chiamano Alpha 3, Linux Torvalds l'avrebbe tranquillamente chiamato kernel 2.0

Funziano già molte cose (alcune che con questa semplicità su Linux te le scordi):

1. Haiku OS ha sempre la GUI funzionante (non ci sono schermi neri su Haiku) se il driver della GPU non esiste viene usato il driver generico VESA
2. Non ci sono diecimila sottosistemi audio
3. Multi threading pervasivo (cosa che Windows inizia ad avere forse da Windows 10?)

Quindi perché non riescono a "finirlo"? Perché sono in 3 gli sviluppatori non perché Haiku OS è un microkernel (che poi loro stessi mi corressero dicendo che effettivamente è un kernel ibrido)... son tutti a patchare Linux?

[robertogl]

Originariamente inviato da Nui_Mg

https://github.com/hfiref0x/UACME

Però:

Admin account with UAC set on default settings required.

[cdimauro]

Gliel'ho già fatto notare in un altro thread, ma tanto continua lo stesso a riportare ciclicamente lo stesso link (che peraltro testimonia come Microsoft sia costantemente impegnata nel sistemare le falle, visto che ne sono rimaste poche).

/OT

[Nui_Mg]

Originariamente inviato da robertogl

Però:

Certo e guarda caso è la situazione di default, a cui quindi vanno incontro la maggior parte di utenti (cosa che non si verifica con implementazioni di sudo per windows).

[cdimauro]

Come quelli di Lindows.