Aangenaam weinig reacties :-D

Een kwetsbaarheid, kan gebeuren. Er is al een patch, probleem waarschijnlijk opgelost. Ik wacht nog op een update van de Manjaro kernel, ik draai 4.14 LTS. Heeft ook geen haast voor mij, dit betreft alleen servers, desktops hebben standaard geen poorten open staan.

Gelukkig hebben ze bij Linux geen "patch tuesday". Anders zouden we nog een maand lang moeten wachten totdat deze kwetsbaarheid gefixt zou zijn. Maar nee... ik lees dit, en besef dat ik de patch al geïnstalleerd had bij het opstarten van mijn computer.

Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.

Alleen wordt het met Linux nooit uitgerold. IOT mist patch beleid, servers zijn te kritisch om een patch ongetest door te laten gaan. Het zal nog jaren blijven zitten. Als je iets automatisch laat installeren heb je het open staan om gehacked te worden.

Patches worden bij Linux nooit zomaar ongetest en automatisch geïnstalleerd bij het opstarten. Geen idee wat Anoniem @03:48 voor Linux systeem heeft. Ik draai Manjaro Linux en heb nog geen patch gezien. Waarom niet? Omdat hij eerst door het Manjaro Team getest wordt voordat hij bij de stabiele updates aangeboden wordt. Daarna beslis ik zelf wanneer ik 'm instaleer. Maar dat is meestal meteen omdat hij al getest is.

Wat ik met anoniem eens ben is dat "Patch Tuesday" compleet achterlijk is en niets te maken heeft met het feit dat updates in een groot bedrijf eerst getest moeten worden voordat ze enterprise wide uitgerold worden. Ja zonder patch tuesday zullen de IT jongetjes meerdere keren per maand updates moeten testen i.p.v. op een vast maandelijks tijdstip na patch tuesday, goed voor ze, dat is hun werk!

Als je iets automatisch laat installeren loop je hoogstens de kans op instabiliteit, niet om gehacked te worden.

En waarom begin je weer over IoT? Voor jou is IoT een synoniem voor Linux maar er zijn ook andere OS voor IoT, dat "geweldige W10" van jou b.v. https://developer.microsoft.com/nl-nl/windows/iot

Als Linux gebaseerde IoT systemen achterlopen met updates is dat puur de schuld van de IoT applicatie ontwikkelaars en niet van Linux.

Ik niets met Windows. Ik zie de ellende met data analyses gegevensverwerkingen. Daar wordt Linux als schaamlapje gebruikt om als ontwikkelaars niet aan security informatieveiligheid te doen. Dat wordt verergerd aan de onwil van Linux nerd om mee te denken over betere oplossingen voor de op te lossen vraagstukken.
Zoals je aantoont elke vorm wat op kritiek zou kunnen duiden wordt afgedaan als "windows aanhang". Dat brengt geen verbetering, integendeel.

"Als je iets automatisch laat installeren loop je hoogstens de kans op instabiliteit, niet om gehacked te worden."

ik kan je uit profesionele ervaring vertellen op bijv CentOS / RHEL dat je de yum update vol automatisch aan kunt zetten via cron dagelijks als je je beperkt tot de nette officiele distro en epel repos en yum protection van die repos gebruikt. In de 20j ervaring heb ik nog geen 'rotte' update ervaren op servers en of op werkstations (>400 en dat zlefs met de meltdown/spectre rotte microcodes fase begin dit jaar van Intel) en hoewel in theorie inderdaad er eens een rotte update voorbij zou kunnen komen, denk ik persoonlijk dat 20j RHVE up to date zijn de resources/fte ballans nu al gunstig maakt als er vannacht ineens op alle servers zo een rotte update binnen zou komen. Maargoed dat is slechts mijn ervaring / risico analyse en die is niet een one size fits all voor iedereen, maar om nu zo uptight over die ene mogelijk rotte update in theorie te doen vind ik dus ook enigsinds overtrokken en heb ervaring en data om die stelling te ondersteunen. ook is een bekende rotte update eenvoudig tegengehouden met bijv yum versionlock danwel een rollback te doen via yum history undo. verschilletje tussen theorie en praktijk ervaring?

Alleen in jouw kleine wereldje! De kans dat dit aan jou ligt (bv. door een gebrek aan professioneel overwicht of overtuigingskracht - eigenlijk een beperkt ethos) is véél groter dan de kans dat dit met Linux te maken heeft.

Meeste systemen draaien toch niet eens de 4 kernel. EL/CentOS zitten nog op 2.6 en 3.10.

maar het zou toevallig kunnen dat de 'bug' wel in de 3.10 gebackport was door RH.

deze lijkt bijv misschien wel van toepassing:

https://access.redhat.com/security/cve/cve-2018-5391

correctie https://access.redhat.com/security/cve/cve-2018-5390