PHK funderer over reaktion imod forskere med pen-testing patches til Linux-kernen

Ja, FOSS er nok næsten lige så dårligt til at hindre at ondsindet kode kommer ind i systemet, som de mere lukkede. Det har nu været kendt i mange år. Men FOSS forhindrer konspirationstanker, fordi hvis man har konspirationstanker (og det er der jo mange der har), så kan man bare gå ind og kigge i koden. Så vil tanken enten blive bekræftet eller afvist.



Og ja, jeg forstår også godt Kamps principielle pointe. Og er enig i den. Men måske kan man også godt forstå at man som systemansvarlig bliver træt af, at skulle reviewe kode, der blot er lagt ind for at teste om koden bliver reviewet. Et eksempel på at universitetsverden blander sig i produktionsverden, og hvor man kan sige, at man nok skal være sikker på, at man har sine aftaler på plads, hvilket det ikke lyder til, at man har haft her.



Når det så er sagt, er jeg bestemt enig i, at det er vigtigt at lytte til de pointer, der kan komme ud af undersøgelsen.

Men jeg synes, når vi har at gøre med en stor kommercielt anlagt kerne, - ganske vist fri og åben, men med alle de kæmpe gigastore firmaer med på holdet, - så må man forvente lidt mere code review, og en helt anden indstilling til audit. Her viser det sig, at OpenBSD-folkene med Theo De Raadt i spidsen, har en helt anden mindre fornærmet indstilling til kodekritik.



Ja, FOSS er nok næsten lige så dårligt til at hindre at ondsindet kode kommer ind i systemet



Linus og co. er dårlige til, at forhindre, at for komplekse kodestumper og patches, især blobs kommer u-auditet ind i kernen. Det har vi set utallige andre eksempler på. Det er efterhånden et giga, monolitisk projekt. Sådan er livet, når man bliver mainstream. Svært, at holde koden simpel, når Facebook, Microsoft, Google, Intel, VMware og de mange andre store kæmper gerne vil befænge Linux med hø og hakkelse, oven i købet non-free blobs, som der er en del af. - Det kan du ikke reviewe.

Hvis formålet er, at undersøge, om man kan snige skumle "rettelser" ind i koden, og hvor længe det varer, inden det bliver opdaget, kan man jo ikke advisere eller aftale det på forhånd. Det ville jo fuldstændigt ødelægge undersøgelsen.



Jeg vil blot håbe, at man tager ved lære af undersøgelsen, og ikke blot lægger den for had.



I øvrigt mener jeg ikke, at non-free blobs burde have nogen plads i kernen.

Er den ikke licenseret som GPL?

#2: Her viser det sig, at OpenBSD-folkene med Theo De Raadt i spidsen, har en helt anden mindre fornærmet indstilling til kodekritik.

Blev OpenBSD udsat for samme eksperiment? Det kunne jo være interessant at sammenligne, hvis flere udviklingsmiljøer bliver udsat for det samme, om de så dels opdager fejlen, og dels hvordan de efterfølgende reagerer på kritik (hvilket jeg egentlig synes bør adskilles som to forskellige diskussioner).

Blev OpenBSD udsat for samme eksperiment?



Nej, men jeg ved, at de har en meget anderledes holdning til kodekritik og kode korrekthed. Så det er plausibelt, at de ville tage uanmeldt pen-testing pænere.

Så vil jeg bare moderere påstanden med, at PKH, som ellers har en ganske stærk aktie i FreeBSD-verdenen, ikke tilsvarende tør lægge hovedet på blokken for FreeBSD-folkene.



https://www.version2.dk/blog/ny-religioes-fanatisme-1092507#comment-426…



Det kan selvfølgelig godt være, at OpenBSD-folkene bare er helt anderledes. Men at kunne undgå irritation over at forskningsverdenen forstyrrer produktionsverdenen, det er nok at tillægge den menneskelige natur lidt for stærke evner til at kontrollere sig selv.



BTW #3: Som én der selv færdes i forskningsverdenen, så vil jeg gerne anerkende, at det kan være vanskeligt at lave et forskningsdesign af den slags problematikker, fordi des mere de undersøgte ved, des mere vil det forurene data. Men det er nu engang vilkåret for universitetsdreven forskning, at man skal have sine tilladelser på plads, og så må man tage højde for urenhederne i den faktiske anvendelse af data. Ellers taber man på troværdighed i forhold til sine samarbejdspartnere. I det konkrete tilfælde tænker jeg, man ville være nødt til at få en tilladelse fra de øverst ansvarlige i projektet. Altså folk, der ikke selv står for testdelen. Og ja, naturligvis risikerer man så, at disse øverst ansvarlige lader denne viden "sive", hvis man af politiske grunde ikke ønsker at fremstå dårligt. Derfor ville man muligvis ikke kunne slutte så meget, hvis der ikke viser sig et problem. Til gengæld ville data være valide, hvis der faktisk viser sig et problem (fordi det vil være et "least likely" udfald).

Så vil jeg bare moderere påstanden med, at PKH, som ellers har en ganske stærk aktie i FreeBSD-verdenen, ikke tilsvarende tør lægge hovedet på blokken for FreeBSD-folkene.



Nej, og det er der en vældig god grund til. Ganske vist udgør korrekt kode og sikkerhed en vigtig del af FreeBSD-projektet og styresystemet, men det er ikke deres hovedfokus. Det er på kompatibilitet med Linux, performance og skalering, samt filsystem redundancy og netværk-performance.



OpenBSD er et meget lille, men dedikeret projekt og styresystem, der udelukkende har sikkerhed og simpel kodebase og kodekorrekthed i fokus. Nærmest hen i det minutiøse, nært vanvittige.



Til gengæld kan OpenBSD ikke det Linux og FreeBSD kan mht. kompatibilitet med grafikdrivere, specielt Nvidia, fordi de ikke tillader blobs i systemet. Det er et trade-off, ligesom de andre mitigations de har også er et trade-off, hvor sikkerhed er i højsædet. Det er også derfor jeg godt tør sige, at de ikke ville ryste på hånden, i forhold til FreeBSD og Linux, fordi de ikke går op i andet :-D

En tilføjelse.



Jeg kan godt have mine bange anelser omkring hvordan det ville blive modtaget af FreeBSD Core Team. Ikke at FreeBSD er så mainstream og stort og bredt, som Linux er - langtfra - men fokus er mere det samme.

#3



I øvrigt mener jeg ikke, at non-free blobs burde have nogen plads i kernen.

Er den ikke licenseret som GPL?



Microcode, firmware, drivere. Det findes, så du kan installere din yndlingsdistro på din computer. Nuvel, da vi taler om, at kunne studere kernen, kan du kun studere den del, der indeholder åben kode. Det vil sige, at non-free blobs kan du ikke studere. Derfor ved vi heller ikke med sikkerhed hvad f.eks. en non-free Wifi-driver indeholder. Ej heller hvad f.eks. intel-microcode indeholder.



Hvis man vil have en 100% fri kerne, så skal man nok gå efter at installere en af de her:



https://www.gnu.org/distros/free-distros.html



Og så er vi tilbage til, at her er en trade-off:



Manglende hardwarekompatibilitet med proprietære computermærker.



*******



Det kan selvfølgelig godt være, at OpenBSD-folkene bare er helt anderledes. Men at kunne undgå irritation over at forskningsverdenen forstyrrer produktionsverdenen, det er nok at tillægge den menneskelige natur lidt for stærke evner til at kontrollere sig selv.



Nu er der jo et stykke fra, at blive irriteret, det skal vi allesammen have lov til, ligesom det er en menneskeret at ryge (Mick Øgendahl-joke ;-D) Men til så, at udelukke et hold forskere. Der er altså ret langt. Det er lidt en overreaktion, og bekræfter mig egentlig lidt i, hvor dumstolte og selvhøjtidelige Linux-udviklere til tider er. Mangel på ydmyghed, og af egne programmeringsevner - manglende selvransagelse, kan man også sige.

Glimrende artikel. Og interessant forsøg.

Tror Linus ville have fået en blodprop hvis det var ham det var gået ud over.

Mon ikke det er hovedpersonerne i udvikler toppen der flegner ud fremfor det enkelte projekts community (Linux BSD,...)

En hacker der viser dig dine sikkerheds fejl skal man i hvert fald altid - når man har sundet sig - klappe på ryggen fremfor at tilsvine / fængsle / udelukke.

Mon ikke det er hovedpersonerne i udvikler toppen der flegner ud fremfor det enkelte projekts community



Det skulle man mene. Men jeg vil alligevel sige, at hos OpenBSD ville det undre mig mindre, hvis de tog godt imod uanmeldt pen-testing, end hos FreeBSD, DragonflyBSD, NetBSD og Linux.

Men til så, at udelukke et hold forskere. Der er altså ret langt. Det er lidt en overreaktion



Det kan godt opfattes som en overreaktion, men lad os vender den om:



Lad os sige det ikke var en undersøgelse og universitetet blev blokeret.

Det ville uden tvivl få personalet og elever på universitetet til at undre sig, hvilket starter en undersøgelse på universitetet. Med lidt held finder universitetet frem til den skyldige (som bevidst har prøvet at sabotere linux kernen) og personen får sin straf (bliver smidt ud / får en bøde etc.).



Desuden. Undersøgelsen gik på, hvor let det er at tilføje dårlig / skadelig kode til linux kernen og om disse bliver opdaget. I artiklen blev forskerholdet tydeligvis opdaget og bannet, hvilket viser at kode ikke BARE kommer igennem.



I stedet for at tilføje deres egen dårlige / skadelige kode, så kunne de også have gennemgået den eksisterende kode i et forsøg på at finde uopdagede bugs og sikkerheds huller. Tænker, at man kan se datoen på, hvornår en given kode er blevet tilføjet.

I artiklen blev forskerholdet tydeligvis opdaget og bannet,



Efter de - ifølge god forsker-etikette - gjorde opmærksom på det. På det tidspunkt havde den kode nået helt til stable, før den blev fjernet.











I stedet for at tilføje deres egen dårlige / skadelige kode, så kunne de også have gennemgået den eksisterende kode





Men det gjorde de ikke. I stedet havde de en anden mission, de ville teste, som en del af deres forskningsprojekt, hvor nemt det er at snige ondsindet kode ind i kernen - og den lykkedes tilsyneladende meget godt, hvilket er lidt foruroligende.



Lad os sige det ikke var en undersøgelse og universitetet blev blokeret.



Hvis og hvis ... Lad os holde os til fakta.



Jeg synes egentlig ikke jeg har mere, at bidrage med i denne diskussion. Jeg har fået delt artiklen og synspunktet. Og der er egentlig ikke så meget mere, at snakke om. Så det bliver det sidste jeg siger i denne kommentartråd.