Een zeer goede zaak voor mensen die Linux gebruiken.
Zo wordt het systeem nog veiliger.

Spuit 11.

Top van debian...gebruik zelf ook een ubuntu/debian based linux distro, dus zal er ook baat bij hebben.

En hoeveel zitten er nog in die niet gevonden zijn. Welke nieuwe zijn er inmiddels bij gekomen. Het maakt niet uit om wel OS het gaat dat riedeltje blijft gelijk.

Ok ook een beschamend iets hoe het niet hoort. https://annex.debconf.org/debconf-share/debconf15/slides/341-linux-in-the-city-of-munich-aka-limux.pdf Die IOT embedded zaken noemde je al. Maar wat dacht je van appliances - storageboxes.
Het universele probleem is onafhankelijk van het OS. Het partch/update beleid dat gaat wat verder dan het OS. Het OS dient om tools en business applicaties te laten draaien. Als die geen continuïteit hebben is het nutteloos. Daarmee wort een change om een patch aan te brengen als een hoog risico ingeschat dat je moet beoordelen en plannen. (COBIT ITIL)

Je link naar dat word gebeuren is een typische die eerder uitgewerkt is volgens mij moest het document vertrouwd worden en de link ook (of niet). Dit soort rijke functies werden ooit verkocht als de kracht van het tool. Als je naar php en java kijkt zie je het zelfde. Zolang het in de eigen user-context blijft is het nog te overzien je moet het op tijde herkennen. Als er ook nog privilege escalation bij komt is het ernstiger.

Als de bovenstaande link uit het arikel volgt kun je ook https://access.redhat.com/security/cve/cve-2017-5669 als onderdee vinden. "The do_shmat function in ipc/shm.c in the Linux kernel, through 4.9.12, does not restrict the address calculated by a certain rounding operation. This allows privileged local users to map page zero and, consequently, bypass a protection mechanism that exists for the mmap system call. This is possible by making crafted shmget and shmat system calls in a privileged context." Risico en impact analyse: je moet een lokale gebruiker met toegang zijn die dat soort code gaat draaien. Uh misschien thuis (niet interessant) maar als dat de normale werksituatie is heb je een meer fundamenteel probleem.

Komisch https://linux.die.net/man/2/shmat is in de zelfde hoek van multiprocessing en execve calls. Het is het meest lastige deel om echt goed te doen. Semaphores timing cleanup is nu niet het meest gangbarre voor code kloppers. Zijn we weer terug op een eerdere discussie.
https://users.cs.cf.ac.uk/Dave.Marshall/C/node27.html
http://www.cs.toronto.edu/~iq/csc209s/smalllectures/csc209_w10_4.pdf
Let op die concurrency noot "Managing concurrency is difficult, as execution behaviour is not always reproducible"
Deze moet je natuurlijk ook meenemen http://hpc.mines.edu/bgq/xlc/developingonaix.pdf

Een beetje oud nieuws - voor de linux kernel.

De debian updates zijn van 8 Maart.

De NCSC waarschuwing is een update van de oorspronkelijke alert met de melding dat sommige bugs van toepassing zijn op de F5 BIG-IP (load balancer) .

Versie 0210-1.00 van de NCSC was voor de Debian updates, versie 0210-1.01 heeft de F5 advisory toegevoegd.

https://www.ncsc.nl/dienstverlening/response-op-dreigingen-en-incidenten/beveiligingsadviezen/NCSC-2017-0210+1.00+Meerdere+kwetsbaarheden+verholpen+in+de+Linux+kernel.html

meer dan 2 jaar bezig om een stack die werkt te bouwen. In de tussentijd geen patches overal verouderde zaken!

Word is een applicatie en wordt bij bedrijven niet door MS beheerd, vaak compleet overwogen met heel veel beperkingen anders ingesteld. De bedrijfseconomische belangen met integratie naar grote commerciële jongens als SAP.

Kijk die office integraties met allerlei cross-ref afhankelijkheden met de paketten van de grote leveranciers zijn niet voor niets ontstaan. Dat het voor thuis situatie met enkel een briefje/tekst wat anders is een ander verhaal. Leef je in in die situatie bij grote organisaties.
Met applicances bedoel ik b.v. http://www.oracle.com/technetwork/database/database-appliance/overview/index.html of https://www.emc.com/corporate/glossary/hyper-converged-infrastructure-appliance.htm het beheer en support ligt niet meer intern maar extern. Een SAN werkt wat anders dan een NAS voor thuis is het meestal een NAS.

Linux / Unix komt uit de jaren 60. Het huidige Windows borduurt voort op de ruzie met IBM OS/2 met een flink redesign meer naar de s360 concepten maar dan herbouwd. Lijkt me dat Linux/Unix op achterstand staat, je kunt het aan het domein concept en beheersbaarheid met AD zien. Selinux (dankzij de NSA) is weer een stap verder.

Gezien de condities waar het risico optreed zou ik voorzichtige aan doen. Open access naar Linux dozen om eigen programma's te draaien is een uitzondering. Bedrijfscontinuïteit is het argument en doel, niet een leuke laatste distro.
Even testen valideren in A omgeving dan pas doorzetten. Denk ook aan het budget.

Nope de fabrikanten zeggen enkele of een herstart nodig is. Voor desktops (windows) nauwelijks relevant omdat de gebruikers zelf kunnen aangeven dat het even niet uitkomt. Aan het het eind van de dag (8uur) komt het wel.
Een server downhalen die 24*7 geacht wordt te draaien is veel vervelender Die 24*7 is vaak de bedrijfscontinuïteit.
Je blijft er met je tengels vanaf totdat je kan aantonen dat er niets fout gaat.

Die vendor lockin is niet eens zo op hardwareapparatuur of OS. Het is de hele applicatiestack die er boven op komt. Je kent het verhaal van de ICT van UWV en ABN/AMRO toch wel? Het is de complete afhankelijkheid van de dienstverleners die alle werkzaamheden uitvoeren. Het is de toekomst alles moet naar de cloud en op afstand gezet worden.

Voor de admin rechten, die krijgen gebruikers op desktops niet (windows). Waar veel met root dan wel een privileged account met veel rechten gedraaid wordt is onder server processen. Daar vind men dat een ieder een gescheiden iets moet hebben maar lastig. Neem nu het dbms dat heeft een eigen account dat overal bij kan. Draai vanuit het dbms een external routine (b.v. R package) en je gaat onder dat account voor je het weet.
Intern doet het een eigen user management met identificatie autenticatie en autorisatie.

Een webserver heeft dat zelfde effect maar ken niet eens een eigen user management. Het web is stateless en kent niet een usermanagement. Zie je dat iedereen dat zelf gaat zitten bouwen. SQL injectie naar de userdatabase zelfs naar het OS Shadow-deel komt voor. Mwah een multiuser adressspace kent nogal wat eisen om het goed ingevuld te krijgen. spookverhalen genoeg meegemaakt.
Voor dat webserver gedoe. Je zou een onderzoek kunnen vinden (2001) met als doel de usersessie in een eigen context gescheiden van de rest te laten lopen. Dat is niet het webserver proces maar echt de usersessies.

Ooit met SQL server (db2/2) aan de slag onder windows. Het usermanagement (identificatie/authenticatie) was niet te vinden wel de autorisatie. Even moeten laten landen dat AD als centrale service is geaccepteerd voor dat doel. Het is/was SSON by default. Dat zie ik bij de marketing implementaties snel& oedkoop niet zo maar gebeuren.

Ik neem aan dat je het over pagina 10 hebt. Noem dat gewoon even, dat helpt erg bij het specifiek zijn.

Maar wat is hier relevant aan? Debian brengt kernel-patches uit, en jij zegt: ja maar in München hebben ze twee jaar geen patches in hun afgeleide van Ubuntu verwerkt. Zegt dat iets over Debian? Over Ubuntu? Over de kernel? Over organisaties die iets daarvan gebruiken maar die niet zoals München een eigen distro hebben gecreëerd? Niets toch? Dus wat wil je er eigenlijk mee zeggen?

En het alles van SAP tot S/390 erbij slepen voegt ook niets toe. Door zoveel mogelijk hoeken van het IT-landschap op te sommen maak je nog geen punt, je komt vooral onsamenhangend over.

Het argument patch klaar installeren zegt niets of je het ook echt kan uitrollen.Daar was het hierboven over.
Het onsamenhangende is dat: jouw machientje thuis met jouw eigen handelingen niet het beeld is wat normaal gangbare ICT is. In een bedrijfsomgeving heb je met veel meer factoren te maken. Namelijk het bedrijfsdoel en bedrijfscontinuïteit.

Ik noem even expliciet SAP omdat dat zo wijdverspreid is en overal op doorwerkt. Als je verder naar LHM kijkt zie je hoe dat een van de belangrijkste peilers daar is. Dat is een zeer wijdverspreid iets dat SAP. Dat negeren als voorwaarde voor een ICT invulling maakt dat je vast gaat lopen.

Dat is niet specifiek voor Debian, voor Linux of voor deze patch, je moet altijd nadenken over de mogelijke impact van elke change en minimaal zorgen dat je hem direct weer terug kan draaien als er problemen blijken te zijn. De situatie in München zegt er helemaal niets over, die hebben een eigen afgeleide van Ubuntu gemaakt en hebben als distro-maker problemen gehad hun zaken op orde te krijgen. Dat is een wezenlijk andere situatie dan waarin een rechtstreekse gebruiker van een mainstream Linux-disto zich bevindt.

En je gaat er kennelijk van uit dat anderen dat niet weten. Je bent niet de enige met uitgebreide ervaring in professionele omgevingen, weet je? Neem niet meteen aan dat iemand die van jou niet onder de indruk raakt niets weet.

Dit is een security upgrade. De kans dat applicaties hier ook maar ene donder anders van gaan draaien is klein. Debian heeft in dat opzicht een reputatie hoog te houden, voor als je het nog niet wist. "Even testen valideren", zoals je het noemde, volstaat juist in complexe omgevingen niet om te ontdekken of een upgrade problemen gaat geven, de problemen kunnen een stuk subtieler zijn dan een simpel "doet 'ie het". En dan komt budget om de hoek kijken, je noemde het zelf al: je kan niet voor elke security upgrade een testweekend voor alle applicaties gaan houden. Je accepteert dus een zeker risico maar zorgt dat je de upgrade direct weer terug kan draaien als zich problemen voordoen.

En natuurlijk lees je release notes, natuurlijk denk je na over de impact van een change, natuurlijk heb je al lang en breed op een rijtje welke categorieën machines je qua risico hebt en op welke momenten je wel en niet van die machines af moet blijven, natuurlijk bepaal je hoe urgent een change voor welke machines is en hoe riskant. Er zullen machines zijn waarvoor deze change urgent is en (gezien de kwaliteit die we van het Debian security team gewend zijn) een voldoende laag risico oplevert om de change met spoed aan te brengen.

En dat heeft geen donder met SAP of S/390 of AD of wat dan ook te maken, niet specifiek althans, het zijn algemene principes die gelden of je nou het ene produkt of het andere noemt. Je voegt daarom inhoudelijk niets toe door met veel namen te gaan strooien. Je komt alleen maar incoherent en interessantdoenerig over door het over die boeg te gooien.

Maakt wel uit over welk OS het gaat, het ene OS is open source en voor iedereen in te zien en te analyseren, zowel voor overheidsdiensten als particulieren. Het andere OS is closed source en oncontroleerbaar behalve voor veiligheidsdiensen in bepaalde landen.

Daarnaast is de snelheid van patchen van belang, de ene organisatie doet daar veel langer over dan de andere.

Alleen jammer dat het weer botte quick fixes zijn waardoor het nu weer sterft van de regressie!

Overheden krijgen ook inzage in closed source als ze dat eisen. Is al meerdere keren naar buiten gekomen. Geen verschil.

Het nakijken van alle code is een leuk argument. In de tijd dat E Dijkstra nog bekend moest worden werd dat al als ongeloofwaardig neergezet alleen door het aantal regels code. Inmiddels zijn het er veel meer en bij linux is 80% inmiddels aangeleverd door de grote commerciëlen. Geen verschil.

Snelheid van patches klinkt ook leuk maar is meer een teken van zwakte. Fundamentele problemen die je echt wil oplossen is geen pleisterwerk.


.

Ik denk dat je hier voor de bijl gaat. Wat er niet goed ging heeft te maken met de hele applicatiestack zoals het in de bedrijfsvoering nodig is. Het gaat niet om dat doosje met een os. Leuk bijhouden kan misschien thuis als dat het enige doel is. Dat beeld als enige waarheid is problematisch daar heb ik last van.

Leer toch eens begrijpend lezen man, hij schrijft dat de open source code voor IEDEREEN in te zien is, dit in tegenstelling tot closed source die alleen voor SOMMIGE overheden in te zien is.

Ook blackhats kunnen de opensource code lezen en in geval van fouten misbruiken toch is het aantal succesvolle aanvallen aanzienlijk minder bij opensource OS'en dan bij closed source OS'en. MEDE door de installed base dat wel.

Snelheid van patchen heeft wel degelijk invloed op de veiligheid van een OS, slecht patchen heeft dat niet natuurlijk.

Met een druk vanuit de hierarchie is dat opgelegd, zeker geen open draagvlak. De burgers waren/zijn het slachtoffer want te vaak ligt de boel plat en krijgen ze niets geregeld. Neem aan dat dit is wat nu tegen het project werkt.
Je hebt de link waarin nu net staat dat dat niet ging. 300 fixes en dus geconstateerde problemen in die stack.
Die fixatie op dat de Linux de oplossing voor alles zou moeten zijn zonder naar de samenhang te kijken is nu net de reden dat je reactie van mij krijgt. Natuurlijk doet dat bij jou pijn omdat het niet je geloof en visie past.
Maar de reactie is typisch voor Linux aanhang het ligt altijd aan de anderen de gebruikers.

Natuurlijk geen verder antwoord. Je ziet de samenhang met de grote commercie en de geldstromen de (links). Meer feten zal niet helpen .Je blijft toch vasthouden in het geloof van de belofte van 25 jaar geleden. Iemand uit een geloof halen is lastig. Als je dan in de praktijk ziet hoe van dat geloof misbruik gemaakt wordt door de commercie dan is dat triest.

Wat is beschamend aan die slides over het limux project ?
Of geeft u in dit geval toe aan aan een gevalletje van "framing" ?

Suggestief en dan druk ik mij nog zacht uit. Er is helemaal niets mis met dat document en evenmin is het erin gepresenteerde Limux project beschamend.

Bij distributies als Debian enz. is het toepassen van security-updates - deze zijn nimmer vermengd met functionele updates - naar mij bekend nog zelden een probleem gebleken. Dat sluit niet uit dat er nooit iets is misgegaan - ik ben niet alwetend - maar de (automatische) installatie van security updates vormt geen "hoog risico" (het omgekeerde vermoedelijk wel).

Close reading baat in dit geval niet. Wat er staat is en blijft ook na zorgvuldige lezing onbegrijpelijk.

Komt allemaal erg interessant en geïnformeerd over. Men neme een stukje tekst van een CVE, dat is altijd behoorlijk specifiek, en zet daarachter wat algemeenheden. Maar het is suggestieve wartaal. (Waarom ? Omdat het suggereert dat kernel hackers de (algemene) wijsheiden negeren en dat is beslist onjuist. Als abonnee van lwn.net weet ik heel zeker dat gebrek aan wijsheid geenszins het probleem is.)

Hoezo ?

Sommige overheden != iedereen. U gaat voorbij aan de relevantie van volledige openbaarheid.

Dat veel van de bijdragen aan OSS van bedrijven komt doet niets af aan de betekenis van openbare ("vrije") code.

Afgezien van wat u hier schrijft is het aardig om op te merken dat als dit uw bijdrage aan een OSS project zou zijn, die rücksichtslos geweigerd zou worden wegens gebrek aan betekenis, slordig gebruik van "white space" en een syntaxfout (dubbele punt). Voor bedrijven die besluiten hun code onder OSS licentie uit te brengen is gebrekkige kwaliteit van de code die eerst als gesloten code is ontwikkeld veelal een een groot probleem. Gebrek aan aan consistente codeerstijl, quick hacks/fixes enz.; bij gebrek aan meekijkende ogen wordt al snel de makkelijke weg gekozen. Kostbaar en duur om te "fixen". Ook duur als als je de last van de doorontwikkeling niet verder in je eentje dragen wilt.

Omdat het mij tegenstaat steeds als een azijnpisser op uw bijdragen in te gaan is dit bij deze mijn laatste reactie. Ik twijfel niet aan de goede bedoelingen, maar het is te vermoeiend.

Joep je verwoord het leuk echter je draait er aardig omheen.
Het linux gebeuren lijkt nu meer op een religie waar andersdenkenden ofwel critici de mond gesnoerd mieten worden.
Die houding helpt echt niet om de informatieveiligheid en privacy op een hoger plan te krijgen.


Het stuk wat je als te lastig en onbegrijpelijk omschrijft is Hoe je met multi user adres spaces om zou moeten gaan. Pas als je die begrijpt kun je het risico en de impact van issues inschatten.
Voor de oss code projecten zijn er vele verlaten en niet van acceptabele kwaliteit. Met de linux kernel heb je een eenvormigheid door de samenwerkende commerciëlen diep een and er vlak terugverdiend wordt. Miljoenen coderegels kunnen zien die zonder design onbegrijpelijk zijn is nutteloos.

Waar het geld van de comercieken vandaan komt is de dienstverlening en bundeling. Daar heb je meteen de vendor lockin. Oss had nut gehad bijvoorbeeld door alle overheidsoftware gemeenschappelijk te ontwikkelen. Nu maken meerdere marktpartijen van alles in een gesloten toepassing met het verkoopargument van open software.

In de beschrijving van de patches van Debian staat steeds wie er misbruik van kunnen maken, bijvoorbeeld: "local attacker", "local unprivileged user", "privileged users", "remote attacker", "local user". Er staat waar van toepassing ook een specifieke context bij (KVM, TCP, n_hdlc module) en indien mogelijk een maatregel waarmee het probleem omzeild kan worden (het laden van de module blokkeren waar hij niet nodig is). Dat is het soort informatie dat een systeembeheerder nodig heeft en die wordt kort en bondig verstrekt. Met die informatie kan je heel behoorlijk risico's inschatten, ook zonder op de hoogte te zijn van de details van lastige programmeertechnieken en hoe die in specifieke (sub-)systemen zijn toegepast.

Je vertrouwt erop dat de leverancier van de patches die technieken onder de knie heeft en een degelijke kwaliteitscontrole toepast, of dat nou een vrijwilligersproject als Debian is of een commerciële leverancier als IBM. Dat vertrouwen baseer je op je eigen ervaring met die leverancier en op die van anderen (de reputatie van die leverancier).

Linux is als een hobbyproject begonnen. Die commerciële partijen zijn pas gaan meedoen nadat het goed genoeg en groot genoeg bleek te zijn om interessant voor ze te worden. Dat ze geld, menskracht en kennis inbrengen is evident, en dat dat enorm bijdraagt om het project gezond te houden ook, maar verlies nooit uit het oog bij dit soort zaken (dat het internet niet zou kunnen bestaan zonder advertenties is er ook een) dat het zonder die inbreng al zelfstandig de massa en kwaliteit heeft ontwikkeld om die commerciële partijen überhaupt ervoor te interesseren.

Uiteindelijk wordt het door mensen gedaan en is het de kwaliteit van die mensen die bepalend is voor het resultaat.

Linus Torvalds is nog steeds de klootzak aan de top die bepaalt wat er wel en niet in de kernel belandt. Ik zeg klootzak omdat hij genadeloos kan zijn tegenover mensen die slechte kwaliteit aanleveren, en daarbij maakt het geen donder uit of die persoon een vrijwilliger is of iemand die voor IBM of RedHat werkt. Die houding is uiteindelijk wat Linux succesvol heeft gemaakt.

Voor de continuïteit van de kwaliteit van het project is niet alleen de financiering ervan essentieel, maar ook dat Torvalds mensen om zich heen heeft verzameld die zelf voortdurend aantonen dat ze slechte kwaliteit buiten de deur weten te houden. Daar zullen geschikte opvolgers tussen zitten voor de projectleiding. Dat gaat over hun persoonlijke kwaliteiten, niet over wie hun salaris betaalt.

Dat het een OSS-project is is ook een factor van belang voor de continuïteit. Als de projectleiding er op een gegeven moment een puinhoop van gaat maken dan leidt dat geheid tot onvrede bij de nodige mensen die eraan meewerken, en dan kan je er nagenoeg zeker van zijn dat er een of enkele forks ontstaan. Een goede fork trekt de goede ontwikkelaars als een magneet aan en effectief gaat het project gaat onder de nieuwe naam verder terwijl er een skelet achterblijft. Mooie voorbeelden daarvan zijn xfree86 (het balletje is overgenomen door x.org) en OpenOffice (met Apache OpenOffice en LibreOffice als opvolgers, de laatste wordt door zo'n beetje iedereen die niet voor MS Office heeft gekozen gebruikt). Als een commerciële partij ontaardt in slechte organisatie, en dat gebeurt echt wel, dan is het nog maar de vraag of en hoe het balletje wordt overgenomen. Het kan tot een faillissement leiden en einde oefening zijn. Het kan op supplier lockin blijven drijven zonder dat de kwaliteit nog het marktaandeel waarmaakt, bij de originele leverancier of overgenomen door een ander die meer in de klanten dan in het bedienen van de klanten geïnteresseerd is (in de mainframewereld was CA ooit agressief op overnamepad, wat gewoonlijk resulteerde in stilvallen van de ontwikkeling van een pakket en slechte support tegen verdubbeling van de licentiekosten). Commercie is geen garantie op kwaliteit.

Dat er partijen met geld achter staan is essentieel. Dat er individuele mensen achter staan die kwaliteit eisen is ook essentieel. Er zijn zat bedrijven die een rammelende puinhoop maken van wat ze doen, en er zijn zat individuele mensen die ook kwaliteit leveren als ze er niet voor betaald worden, die gewoon in hun aard hebben zitten dat ze dingen heel goed willen doen. En meer dan genoeg van die mensen branden af als werknemer van commerciële partijen omdat de bedrijfscultuur helemaal niet op kwaliteit gericht is.

Vereenzelvig kwaliteit niet met commercie, dat is geen automatisch verband. Menig bedrijf is niet succesvol omdat ze kwaliteit leveren maar omdat ze harder van de daken schreeuwen dat ze bestaan dan hun concurrenten. Kwaliteit is uiteindelijk het resultaat van mensen die op kwaliteit gericht zijn en die de ruimte hebben om die neiging te botvieren. Allerlei methodes, procedures, certificeringen etc. kunnen dat zeker ondersteunen, maar niet vervangen. Je kan een ISO-certificering halen voor het produceren van betonnen zwemvesten, het zegt niet alles.