– Att säkra ett operativsystem handlar i huvudsak om att endera förhindra inloggade användare att skaffa sig rättigheter de inte ska ha (”privilege escalation”) eller att upprätthålla strikta regler för vad som kan och får skickas mellan olika delar av applikationen och operativsystemet, säger Aljoscha Lautenbach, security engineer på konsultföretaget Evidente i Göteborg som är specialiserat på utveckling av inbyggda system.

Även metoderna för att säkra systemet kan sorteras i två grupper, säger han: djupförsvar, där man lägger lager på lager av säkerhet kring det som ska skyddas, samt att minska attackytorna genom att ta bort eller avaktivera moduler och tjänster som inte behövs i den aktuella produkten.

Som säkerhetskonsult ägnar Aljoscha Lautenbach mycket av sin tid åt säkerhetsarkitektur, riskanalys och annat strategiskt arbete. Men implementation ingår också i arbetsuppgifterna och när han höll en presentation på Embedded Online-konferensen i maj valde han att fokusera på detta.

– Jag har presenterat på Embedded Online Conference tidigare och då har det varit ganska abstrakta ämnen, men den här gången valde jag att ta upp några praktiska möjligheter att säkra Linuxinstallationer.

Systemsäkerhet är ett stort ämne och det finns mycket man borde tänka på. En basfunktion som bör finnas på plats är Secure Boot, som verifierar signaturer vid start av systemet för att garantera att det är rätt bootloader som körs. Randomiserad placering av koden i minnet, känt som ASLR, som gör att en angripare inte kan veta var i minnet en viss rutin eller variabel finns, bör också vara påslaget. Och förstås en brandvägg i stil med nftables för att försvåra angrepp via nätverksporten.

Därefter börjar det roliga: konfigurering av Linuxkärnan. Det finns många säkerhetsrelaterade konfigurationsvariabler att skruva på, säger Aljoscha Lautenbach, och illustrerar med två exempel: CONFIG_INIT_ON_ALLOC och CONFIG_INIT_ON_FREE. Om dessa är påslagna nollställs minne när det allokeras respektive frisläpps vilket minskar risken för att data ska läcka mellan processer när en process tilldelas minne som en annan process nyligen har frisläppt.

Dessa variabler illustrerar också en vanlig målkonflikt: bättre säkerhet till priset av mer processorlast. Beroende på exakt hur applikationen beter sig kan nollställandet kräva allt från någon enstaka procent upp till 7–8 procent av processortiden.

– Det man behöver veta om kernel-konfiguration finns lyckligtvis väl dokumenterat på webbplatser som kernel.org och kernsec.org/doc. Jag kan också rekommendera verktyget kernel-hardening-checker som listar de variabler som finns och föreslår lämpliga värden på dem, säger Aljoscha Lautenbach.

Linux Security Modules (LSM) är ett ramverk för att förpacka säkerhetsfunktioner och lägga till dem till Linuxkärnan. En vanlig funktion, som bland annat erbjuds i SELinux (LSM som ingår som standard i Android) och AppArmor (dito för Debian-baserade distiributioner), är MAC (Mandatory Access Control, det vill säga obligatorisk åtkomstkontroll). Med MAC kan utvecklaren styra i detalj vilka processer i systemet som får komma åt vilka objekt, och vilka processer som får kommunicera med varandra.

Ett annat exempel är LoadPin, som har en mer avgränsad funktion: den ser till att kernel-moduler bara kan läsas in från ett visst filsystem. Då kan man läsa in operativsystemet från ett skrivskyddat filsystem och förlita sig på att ingen angripare har varit där och ändrat i koden.

– LSM:er är kraftfulla verktyg men det är ändå inte det första man ska titta på för inbyggda system. Det är en hög inlärningströskel och det finns oftast andra, enklare, vägar att förbättra säkerheten, säger Aljoscha Lautenbach.

– Men om man ändå vill använda LSM är Debian och App­Armor bra exempel att studera.

Lautenbach framhåller också att säkerhetsarbetet ändå måste börja med en del abstrakt tänkande. Man behöver skaffa sig en realistisk hotbild för att veta vad systemet behöver skyddas mot, och man behöver göra en riskanalys – riskanalysen är dessutom ett krav för många certifieringar inom reglerade branscher som medicinska instrument och fordon.

Jonas Lejon, säkerhetskonsult på egna företaget Triop, pekar på Microsofts Secure Development Lifecycle, en process som Microsoft förvisso tog fram för att få ordning på sin egen utveckling men som också går att tillämpa på utveckling av inbyggda system.

– SDL täcker hela utvecklingsprocessen. Mycket handlar om organisation men sådant som hur man bygger systemet och hur man säkrar leveranskedjan ut till kund ingår också, säger Jonas Lejon.

Artikeln är tidigare publicerad i magasinet Elektroniktidningen. Prenumerera kostnadsfritt!

Några kärnbegrepp i SDL är Zero Trust, det vill säga utgå från att ett intrång har skett och lita bara på det som du kan verifiera, använd beprövade kryptografiska standarder, utbilda utvecklarna i säkerhet, testa säkerheten och så vidare.

– Överlag pågår också ett skifte från C till minnessäkra programspråk som till exempel Rust. USA:s säkerhetsmyndighet NSA är en av de instanser som rekommenderar ett sådant skifte. Om alla skulle följa det rådet skulle hela klasser av buggar försvinna i ett slag, säger Jonas Lejon.