OpenBSD
I hela min professionella karriär har jag kört Linux, samtidigt har jag dock alltid varit hemligt förälskad i OpenBSD.
Varför borde OpenBSD vara förstahandsvalet när du ska sätta upp en server? Det behövs knappast ett långt blogginlägg för att motivera varför OpenBSD borde övervägas först. Utan inbördes ordning:
Problem som brukar tas upp med OpenBSD är höga inlärningskurvor, bökig patchhantering, att det är för få funktioner, att det saknas drivrutiner och att projektet, eller åtminstone ledaren Theo, beter sig som skitstövlar emellanåt. Det sistnämnda bekräftar de genom att strunta i vad andra tycker om bl a patchhantering.
Like it or not men jag har avsevärt större förtroende för säkerheten i OpenBSD än i något annat system. Tyvärr kommer det med en kostnad: det finns jättemånga som kan göra jättemånga saker med Windows, det finns ganska få personer som kan göra ett ganska begränsat antal saker med OpenBSD.
Det finns dock exempel på företag och organisationer som använder OpenBSD; CERT-SE (tidigare Sitic) föredrar t ex operativsystemet (gissningsvis till MSB:s förtret). Det finns även mer omfattande exempel:
Stefan Pettersson
Varför borde OpenBSD vara förstahandsvalet när du ska sätta upp en server? Det behövs knappast ett långt blogginlägg för att motivera varför OpenBSD borde övervägas först. Utan inbördes ordning:
- Enkelhet, kodmassan i OpenBSD är relativt liten.
- Granskning, koden i OpenBSD granskas regelbundet över tiden.
- Få uppdateringar, säkerhetspatchar kommer sällan och inför minimala förändringar.
- Säkerhetsfunktioner, man är tidig med generiska skydd som NX/XD, ASLR, stack cookies, alternativ till str*()-funktionerna o s v.
- Enkel dokumentation, stor vikt läggs vid manualerna.
- Strängt releaseschema, ny version varje halvår.
Problem som brukar tas upp med OpenBSD är höga inlärningskurvor, bökig patchhantering, att det är för få funktioner, att det saknas drivrutiner och att projektet, eller åtminstone ledaren Theo, beter sig som skitstövlar emellanåt. Det sistnämnda bekräftar de genom att strunta i vad andra tycker om bl a patchhantering.
Like it or not men jag har avsevärt större förtroende för säkerheten i OpenBSD än i något annat system. Tyvärr kommer det med en kostnad: det finns jättemånga som kan göra jättemånga saker med Windows, det finns ganska få personer som kan göra ett ganska begränsat antal saker med OpenBSD.
Det finns dock exempel på företag och organisationer som använder OpenBSD; CERT-SE (tidigare Sitic) föredrar t ex operativsystemet (gissningsvis till MSB:s förtret). Det finns även mer omfattande exempel:
As a regular user, when the IT staff starts migrating your Windows XP workstation to Windows 7, it is very traumatic! But, you accept it because everyone else in the world is more or less doing the same. But imagine if you had to migrate from Windows XP to Mac OS X! Ok you can also accept it because, well you own an iPod like everyone else, so Apple is known to you.
But the real challenge comes from migrating users from a >10 years habit of using Windows and MS Office to an OpenBSD GNOME Desktop with Libre/Openoffice without impacting their daily work, aka production, aka company revenue.
Stefan Pettersson
Ye Olde Security: Saltzer-Schroeder
För länge, länge sedan, på 1970-talet, inte långt efter vi tågade över Bält och skrämde slag på danskarna, levde två lärda män som hette Jerome H. Saltzer och Michael D. Schroeder. Saltzer och Schroeder var forskare och hade stora anslag för att undersöka hur information kunde skyddas i system för ADB. 1973 skrev de sitt magnum opus: The Protection of Information in Computer Systems.
Eller varför inte: "In particular, the user himself and the communication system connecting his terminal to the computer are components to be viewed with suspicion. Conversely, the user needs to verify that he is in communication with the expected computer system and the intended virtual machine."
Eller vad sägs om: "An easy way for an intruder to penetrate a password system, for example, is to intercept all communcations to and from the terminal and direct them to another computer—one that is under the interceptor's control. This computer can be programmed to 'masquerade,' that is, to act just like the system the caller intended to use, up to the point of requesting him to type his password. [...]"
Economy of mechanism: Designa små, enkla system. Ju enklare desto mindre risk att sårbarheter införs, desto enklare är det att upptäcka dem och desto lättare är det att laga dem.
Fail-safe defaults: Själv brukar jag göra skillnad på fail-safe och fail-secure (egentligen är det väl Schneier som har inspirerat distinktionen i Beyond Fear) eftersom de ofta står mot varandra; nödutgångar är skolexemplet. Här avses oavsett att normalläget är ingen åtkomst och att systemet istället ska definiera under vilka förutsättningar åtkomst ges. Whitelisting kontra blacklisting.
Complete mediation: Varje anrop eller åtgärd ska omfattas av säkerhetsbeslut viz. det ska inte finnas "bakdörrar" som går förbi det som konceptuellt kallas en reference monitor. Faktum är att detta var ett av de tre kraven på en reference monitor som James P. Anderson lade fram i Computer Security Technology Planning Study från 1972. (Den rapporten är också gammal men avsevärt mer svårsmält.)
Open design: Kerckhoffs princip.
Separation of privilege: Här avses snarare det vi idag oftast kallar defense in depth, att säkerheten inte ska bero på bara en försvarslinje. Man ger exemplet där en dörr har två oberoende lås vars nycklar kan förvaras av olika personer på olika platser. Dels handlar det om att göra det svårt för en tredje person att få tag i båda nycklar, dels för att skydda sig mot insiders. Det är inte uttalat i uppsatsen men man kan argumentera för att låsen kan vara av olika modell för att för att skydda sig mot sårbarheter i ett lås. Eller använda helt olika tekniker för att skydda sig mot class breaks.
Least privilege: Det här kan vara den mest kända principen och är precis vad den låter som. Militärens need-to-know används som exempel. Den är givetvis nära besläktad med fail-safe defaults ovan.
Least common mechanism: Detta tangerar segmentering, att minimera gemesamma kontaktytor mellan användare (processer). Eftersom multi-level security-system (Bell-LaPadula o s v) var på tapeten vid den här tiden så var informationsläckage och covert channels ett stort bekymmer. Samtidigt rörs det vi idag kallar process isolation där en modern, närliggande teknologi är t ex Windows Integrity Mechanism som kom med Vista.
Psychological acceptability: Gör det lätt för användaren att fatta rätt säkerhetsbeslut. Nuförtiden skulle jag dock lägga till "men undvik helst att blanda in användaren överhuvudtaget". Problemet med principen är att "användare" i början av 70-talet inte, som idag, betydde Joppe och Göran, utan diverse forskare och programmerare. Att inte blanda in användaren i säkerhetsbeslut är tyvärr fortfarande en utopi, principen borde dock användas för att mildra problemet med dancing pigs.
Så, trots 40 år på nacken är principerna precis lika aktuella idag.
Såg just att kollega Christoffer också har skrivit om gammal hederlig säkerhet och enkelhet, ta en titt.
Trevlig påsk!
--
Stefan Pettersson
Saltzer-Schroeder-uppsatsen är ett fantastiskt exempel på att vi stöter på samma problem om och om igen. I texten hittar vi nuggets som de åtta designprinciperna (mer om dessa nedan):
- Economy of mechanism
- Fail-safe defaults
- Complete mediation
- Open design
- Separation of privilege
- Least privilege
- Least common mechanism
- Psychological acceptability
Eller varför inte: "In particular, the user himself and the communication system connecting his terminal to the computer are components to be viewed with suspicion. Conversely, the user needs to verify that he is in communication with the expected computer system and the intended virtual machine."
Eller vad sägs om: "An easy way for an intruder to penetrate a password system, for example, is to intercept all communcations to and from the terminal and direct them to another computer—one that is under the interceptor's control. This computer can be programmed to 'masquerade,' that is, to act just like the system the caller intended to use, up to the point of requesting him to type his password. [...]"
Economy of mechanism: Designa små, enkla system. Ju enklare desto mindre risk att sårbarheter införs, desto enklare är det att upptäcka dem och desto lättare är det att laga dem.
Fail-safe defaults: Själv brukar jag göra skillnad på fail-safe och fail-secure (egentligen är det väl Schneier som har inspirerat distinktionen i Beyond Fear) eftersom de ofta står mot varandra; nödutgångar är skolexemplet. Här avses oavsett att normalläget är ingen åtkomst och att systemet istället ska definiera under vilka förutsättningar åtkomst ges. Whitelisting kontra blacklisting.
Complete mediation: Varje anrop eller åtgärd ska omfattas av säkerhetsbeslut viz. det ska inte finnas "bakdörrar" som går förbi det som konceptuellt kallas en reference monitor. Faktum är att detta var ett av de tre kraven på en reference monitor som James P. Anderson lade fram i Computer Security Technology Planning Study från 1972. (Den rapporten är också gammal men avsevärt mer svårsmält.)
Open design: Kerckhoffs princip.
Separation of privilege: Här avses snarare det vi idag oftast kallar defense in depth, att säkerheten inte ska bero på bara en försvarslinje. Man ger exemplet där en dörr har två oberoende lås vars nycklar kan förvaras av olika personer på olika platser. Dels handlar det om att göra det svårt för en tredje person att få tag i båda nycklar, dels för att skydda sig mot insiders. Det är inte uttalat i uppsatsen men man kan argumentera för att låsen kan vara av olika modell för att för att skydda sig mot sårbarheter i ett lås. Eller använda helt olika tekniker för att skydda sig mot class breaks.
Least privilege: Det här kan vara den mest kända principen och är precis vad den låter som. Militärens need-to-know används som exempel. Den är givetvis nära besläktad med fail-safe defaults ovan.
Least common mechanism: Detta tangerar segmentering, att minimera gemesamma kontaktytor mellan användare (processer). Eftersom multi-level security-system (Bell-LaPadula o s v) var på tapeten vid den här tiden så var informationsläckage och covert channels ett stort bekymmer. Samtidigt rörs det vi idag kallar process isolation där en modern, närliggande teknologi är t ex Windows Integrity Mechanism som kom med Vista.
Psychological acceptability: Gör det lätt för användaren att fatta rätt säkerhetsbeslut. Nuförtiden skulle jag dock lägga till "men undvik helst att blanda in användaren överhuvudtaget". Problemet med principen är att "användare" i början av 70-talet inte, som idag, betydde Joppe och Göran, utan diverse forskare och programmerare. Att inte blanda in användaren i säkerhetsbeslut är tyvärr fortfarande en utopi, principen borde dock användas för att mildra problemet med dancing pigs.
Så, trots 40 år på nacken är principerna precis lika aktuella idag.
Såg just att kollega Christoffer också har skrivit om gammal hederlig säkerhet och enkelhet, ta en titt.
Trevlig påsk!
--
Stefan Pettersson
