I denne tid er der meget snak omkring beskyttelse af personlige data og privatliv, men det lader først og fremmest til, at der fokuseres på compliance og indhentning af samtykke. Jeg synes i stigende grad, det er relevant at tænke mere over, hvordan vi rent faktisk behandler data på en sikker måde.
Jeg blev for noget tid siden opmærksom på BCHS-stakken, som er en værktøjskasse, der har OpenBSD som fundament og bruger samme filosofi som OpenBSD-projektet til at opnå den ønskede funktionalitet på sikker vis.
Som de fleste nok ved, er fokus i OpenBSD sikkerhed, og det går forud for både performance og kompatibilitet. OpenBSD har bygget en sikkerhedsmekanisme, der hedder pledge, som i al sin enkelthed er et systemkald, en process kan anvende til at begrænse mulighederne for systemkald efterfølgende. Ved at organisere koden, så det mest sårbare overfor angreb køres efter pledge-kaldet, reduceres risikoen for, at en sårbarhed kan udnyttes, væsentligt.
Som noget nyt i OpenBSD 6.4 er der også introduceret en mekanisme kaldet unveil. Den kan bruges til kun at give adgang til begrænsede dele af filsystemet, således at skaderne kan begrænses kraftigt, i de tilfælde, hvor man ikke på et tidligt tidspunkt i processens levetid kan åbne de nødvendige filer.
BCHS står for BSD, C, httpd, SQLite. Man skriver sin applikation i C med SQLite som backend. At skrive den slags i C kan til at starte med virke non-intuitivt. C er jo kendt for ikke at beskytte programmøren mod array-overløb o.s.v. Men hvis man benytter sig af de hjælpefunktioner, der findes i OpenBSD til bl.a. håndtering af strenge, reduceres disse problemer betydeligt.
Overordnet set står httpd for at modtage requests, som via FastCGI-protokollen sendes videre til slowcgi, der laver requests om til gammeldags CGI og kalder den ønskede binary. Idet der er tale om en statisk linket C-applikation, tager det stort set ingen tid at starte eksekveringen. Når vi bruger pledge og unveil, kan vi ikke genbruge processen til andet, når et request er behandlet færdigt, idet den på det tidspunkt er bundet af for mange restriktioner. Det har dog den klare fordel, at der ikke er nogen risiko for at lække tilstand fra et request til det næste.
I rigtigt mange moderne webapplikationer er det meste præsentationslogik lagt ud på klienten i form af javascript-kode, der håndterer JSON-data, som modtages fra serveren. Serverside-koden er således reduceret til et tyndt lag af filtrering og validering mellem webklient og database. Derfor er der ikke så stort behov for template-systemer og den slags, som kan være lidt tungt at bygge i C.
Hvis man er vant til andre unix-lignende systemer, kan OpenBSD godt virke noget gammeldags på flere punkter. En del af dem skyldes bevidste valg, hvor andre har valgt lidt lettere løsninger har OpenBSD holdt fast i den gamle måde at gøre tingene på, fordi det enten gav højere sikkerhed, stabilitet eller gennemskuelighed.
Der har de seneste år været en bevægelse i retning af, at alting skal bygges med microservices, container-teknologi, virtualisering o.s.v. Man får hurtigt mange millioner linjer kode fra tredjeparter i drift, før man overhovedet når til den kode, man har skrevet selv. Det giver i mine øjne en bekymrende stor angrebsflade. Mit postulat er, at mange ting vil kunne bygges langt simplere, fx. med BCHS.