Komiskt falsklarm från Sophos

Sophos Antivirus misslyckades nyligen på ett ganska spektakulärt sätt:

On Wednesday, Sophos antivirus products did something very wrong: they started detecting false positives. The company has since fixed the issue, but only on Thursday did it become clear what the fiasco was all about: the Sophos software was detecting its own binaries as malware.

Programmet identifierade alltså en av sina egna komponenter som spyware, och tog bort den. Till råga på allt var det den del i programmet som genomför automatiska uppdateringar som "oskadliggjordes", så att de senare uppdateringar som rättade till felet inte kunde komma fram. Lätt lustigt är det.

Även om just det här fallet är litet ovanligt så är falsklarm inte ovanliga. På sätt och vis är de faktiskt önskvärda. Antivirusprogram fyller samma funktion som brandvarnare. De ska väsnas om det brinner, och det är bättre att det går tio falsklarm på varje verklig fara än att larmet har överseende med en eller annan eldsvåda mellan varven.

Sophos misslyckande var alltså egentligen inte att de råkade falsklarma, utan att de inte ordentligt testade uppdateringen som orsakade falsklarmet innan de skickade ut den.

Analogin håller faktiskt längre än så. När det brinner och larmet går så är det redan för sent och dags att släcka, sanera och göra något åt att brandsäkerheten är dålig. På samma sätt är det i princip redan för sent när ett antivirusprogram identifierar ett (verkligt) hot på datorn. Den skadliga koden har ju redan tagit sig in i maskinen. Då är det dags för en jobbig totalsanering och att sluta använda datorn på ett farligt sätt.

En bra början är att sluta använda Internet Explorer, om man nu fortfarande gör det. I samma veva bör man sluta med olika riskbeteenden på nätet, som att besöka och ladda ned från piratsajter, hålla på med porr eller googla på låttexter. (Det sista förvånade mig litet när jag hörde talas om det första gången.)

Det är även en bra idé att aldrig använda sig av öppna trådlösa nätverk – vare sig de är krypterade och kräver inloggning eller inte.

xsudo.sh – en skriptad X11-wrapper för sudo

För att fira slutet av min exil i Windows skriver jag en följetong om de olika program, inställningar och knep som gör mitt sätt att använda OpenBSD… ja, värt att fira.

Gårdagens inlägg handlade om att byta plats på Escape och Caps lock, och var en uppfräschning av ett tidigare inlägg. I dag är det dags för en uppdatering av ett annat gammalt inlägg, som beskriver hur man kan köra X11-program som andra användare eller root.

Själv använder jag den här metoden för att köra webbläsare som användaren _web med hemkatalogen /home/_web. Därigenom saknar webbläsaren skrivrättigheter under min hemkatalog, och kan inte sabba något.

Eftersom jag dessutom kör med umask 077 i min .profile och med jämna mellanrum gör chmod -R og-rwx på min hemkatalog, kan webbläsarna inte heller läsa mina filer. Den enda nackdelen med det upplägget är inte så blodig: När jag vill ladda upp eller ned något genom webbläsaren måste jag låta filerna ifråga passera /tmp (som för övrigt töms automatiskt av OpenBSD vid uppstart, och dessutom är mountad async på min maskin).

Det här upplägget borde fungera i de allra flesta X11-varianter, exempelvis X.org.

sudo och $SUDO_ASKPASS

Du känner kanske till gksudo och kdesudo, två grafiska sudo-prompter för GNOME respektive KDE? De är smidiga när man vill köra ett X11-program som någon annan användare eller root, men inte vill ta en omväg över xterm.

Men de är utom räckhåll här, eftersom jag inte vill ha vare sig KDE eller GNOME. Som tur är behövs de inte heller, för samma funktionalitet uppstår i det närmaste av sig självt, om man bara har OpenSSH installerat. Det följande är klippt ur sudo (8):

-A    Normally, if sudo requires a password, it will read it from
      the user's terminal.  If the -A (askpass) option is
      specified, a (possibly graphical) helper program is executed
      to read the user's password and output the password to the
      standard output.  If the SUDO_ASKPASS environment variable is
      set, it specifies the path to the helper program.  Otherwise,
      the value specified by the askpass option in sudoers(5) is
      used.  If no askpass program is available, sudo will exit
      with an error.

Vi behöver med andra ord något enkelt program som visar ett fönster, läser in ett lösenord och sedan trycker ut det på standard output. Programmet heter ssh-askpass. Manualsidan ssh-askpass (1) menar att det inte ska köras direkt, men det struntar jag i.

Följande skript skulle alltså kunna fungera:

Men ska det verkligen vara så lätt? Vi provar att köra xcalc som användaren _web:

$ sh bin/xsudo.sh -Hu _web xcalc
No protocol specified
Error: Can't open display: :0

Visst ja – användaren _web har ju ingen åtkomst till min X11-server. Det är nu allt blir krångligt.

Display-åtkomst i X11

Säkerhet och X11 går inte direkt hand i hand, och de säkerhetsmekanismer som faktiskt finns är svåranvända påbyggnader som alltjämt riskerar att rasa samman. När en X11-session startas på din maskin, så är det i själva verket två program som drar i gång. Först en X11-server, och sedan en X11-klient. Medan servern kör alla program är det klienten som direkt kommunicerar med dig via tangentbord, mus och skärm.

En fördel med den modellen är att klient och server inte alls behöver vara på samma maskin. I vanliga fall, t.ex. på hemdatorer, ansluter klienten till servern via loopback-gränssnittet, alltså till adressen localhost eller 127.0.0.1.

Det som i själva verket händer när xcalc försöker komma åt X11 i vårt xsudo-skript ovan, är att servern nekar användaren _web att ansluta. Tre lösningar på det problemet är vanligt förekommande.

  1. xhost kan användas för att ge full åtkomst till din X11-display åt en viss användare på samma maskin. (Programmet kan även ge full åtkomst till alla användare på valfri IP-adress, men det är en dålig idé.)
  2. xauth kan användas för att ge full eller begränsad åtkomst till din X11-display åt en användare eller ett program, vare sig de finns på samma maskin eller någon annan.
  3. ssh kan alternativt köras med X11 forwarding, och ger då begränsad åtkomst till din X11-display.

Vill vi använda begränsad eller full åtkomst? Det beror på. Begränsad åtkomst innebär att bland annat accelererad grafik och direkt åtkomst till X input devices inte fungerar. Grafiskt intensiva program, som exempelvis webbläsare faktiskt är, går därför långsammare med begränsad åtkomst. En annan nackdel är att AltGr kan sluta fungera.

När det är möjligt bör man ändå använda begränsad åtkomst. Det är ganska lätt att visa varför. Om du själv vill prova det följande ska du se till att ha xinput på din maskin.

kaja$ xhost +si:localuser:_web # Släpp in lokal användare '_web' i X11
localuser:_web being added to access control list
kaja$ xinput list # Lista alla input devices
+ Virtual core pointer                  id=2    [master pointer  (3)]
|   + Virtual core XTEST pointer        id=4    [slave  pointer  (2)]
|   + /dev/wsmouse0                     id=7    [slave  pointer  (2)]
|   + /dev/wsmouse                      id=8    [slave  pointer  (2)]
+ Virtual core keyboard                 id=3    [master keyboard (2)]
    + Virtual core XTEST keyboard       id=5    [slave  keyboard (3)]
    + /dev/wskbd                        id=6    [slave  keyboard (3)]
kaja$ sudo -u _web xinput test 6 # Dumpa händelser på device 6
key release 36
key press   33
key release 33
key press   38
key release 38
key press   39
key release 39
key press   39
key release 39
key press   25
key press   32
key release 25
key release 32
key press   27
key release 27
key press   40
key release 40

Vad var det egentligen som hände? Med xinput list listade jag alla aktiva X input devices, och kom fram till att tangentbordet var device nummer 6. Sedan körde jag xinput test 6 som användaren _web, och skrev därefter "password" i ett annat fönster, som jag körde i egenskap av mig själv. Trots att jag skrev i ett fönster som tillhörde användaren jesper, och till råga på allt i ett lösenordsfält, så kunde användaren _web se exakt vilka tangenter jag tryckte ned (och släppte upp, för den delen).

Med andra ord kan vilket program som helst, oavsett vilken användare som kör det, avläsa alla nedslag på tangentbordet, oavsett vilket program som "egentligen" tar emot dem, så länge det har full åtkomst till X11-displayen.

Exceptionellt illa. Så pass illa att om du bara lyckas peta in ett xhost localhost på någon dator du har åtkomst till via ssh, så är det följande en fungerande keylogger:

kaja$ ssh struts xinput test 6

…förutsatt att tangentbordet är device 6 på maskinen struts, då. Detta är förklaringen till varför xhost-autentisering mot någon annan dator än localhost är så dåligt. Med en sådan regel på plats behöver man inte ens ha tillgång till maskinen via exempelvis ssh, utan kan köra sin keylogger direkt mot maskinens IP-adress.

Lätt skrämmande. Med begränsad åtkomst kan vi däremot inte göra några sådana hyss. I exemplet nedan ansluter jag till min egen maskin (som heter kaja) via ssh för att få en session utan full åtkomst.

kaja$ ssh -o ForwardX11=yes localhost
kaja$ xinput list
X Input extension not available.
kaja$ xinput test 6
X Input extension not available.

Mycket bättre, men som sagt också fritt från både grafisk acceleration och AltGr.

Vilken typ av autentisering ska vi då välja?

Alternativ 3, alltså X11 över ssh, är inte intressant för oss, eftersom samma resultat kan uppnås utan att belasta processorn med en krypterad anslutning till localhost.

Alternativ 1, alltså att köra xhost för en lokal användare, är visserligen användbart när vi behöver full åtkomst, men klarar inte att ge begränsad åtkomst. Vi vill kunna välja.

Kvar blir alltså alternativ 2, att använda xauth, som givetvis är krångligast.

xsudo.sh – en skriptad X11-wrapper för sudo

Efter en blick (eller tjugotre) i xauth (1) verkar följande ordning gångbar:

  1. Skapa en tom, privat och tillfällig fil i /tmp.
  2. Be X11-servern om en MIT-cookie (som är trusted eller untrusted beroende på om vi vill ha full eller begränsad åtkomst) och placera denna i den tillfälliga filen.
  3. För över ägandet av den tillfälliga filen till användaren vi vill bli.
  4. Kör sudo för användaren vi vill bli, med XAUTHORITY satt till vår temporära fil och DISPLAY till den X11-display som kakan vi skapat gäller för.
  5. Ta bort den tillfälliga filen när sudo (och det program som sudo startat) avslutats.

Bäst att ge ett praktiskt exempel. Nedan körs xcalc som _web med begränsad åtkomst.

$ umask 077                                 # Bli privat
$ mktemp                                    # Skaffa en tempfil
/tmp/tmp.OVZCpcwL4A
$ xauth -f /tmp/tmp.OVZCpcwL4A generate \   # Skapa cookie i filen...
    $DISPLAY \                              # ...för DISPLAY
    . \                                     # ...av MIT-COOKIE-typ
    untrusted                               # ...med begränsad åtkomst
$ sudo chown _web._web /tmp/tmp.OVZCpcwL4A  # Ge ägande till _web
$ sudo -AHu _web \                          # Bli _web...
    env DISPLAY=$DISPLAY \                  # ...med rätt X11-display
    env XAUTHORITY=/tmp/tmp.OVZCpcwL4A \    # ...och rätt MIT cookie
    xcalc                                   # ...och kör xcalc
$ rm -f /tmp/tmp.OVZCpcwL4A                 # Ta bort tempfilen

Och för att hoppa över ett närmast oändligt antal steg: Så här ser ett skript som automatiserar processen ut:

(Givetvis kan du även läsa den senaste versionen av skriptet.)

Hur använder man då skriptet? Vi kan ju börja med att testa det:

kaja$ sh /usr/opt/bin/xsudo.sh whoami  
root
kaja$ sh /usr/opt/bin/xsudo.sh -u _web whoami
_web
kaja$ sh /usr/opt/bin/xsudo.sh -tu _web xinput list
+ Virtual core pointer                  id=2    [master pointer  (3)]
|   + Virtual core XTEST pointer        id=4    [slave  pointer  (2)]
|   + /dev/wsmouse0                     id=7    [slave  pointer  (2)]
|   + /dev/wsmouse                      id=8    [slave  pointer  (2)]
+ Virtual core keyboard                 id=3    [master keyboard (2)]
    + Virtual core XTEST keyboard       id=5    [slave  keyboard (3)]
    + /dev/wskbd                        id=6    [slave  keyboard (3)]
kaja$ sh /usr/opt/bin/xsudo.sh xinput list        
X Input extension not available.

Lägg märke till hur flaggan -t ger sådan där otäck åtkomst till tangentbordet.

Lägg även märke till att jag lagt skriptet i /usr/opt/bin/ i stället för under min hemkatalog; skript som kör sudo ska ägas av root och vara oskrivbara för andra användare.

För att starta Chromium med xsudo.sh har jag kopplat ett menyalternativ i fönsterhanteraren till följande formel:

/bin/sh /usr/opt/bin/xsudo.sh -tu _web /usr/local/bin/chrome

Trots X11:s skrämmande brist på isolering mellan program kör jag alltså webbläsaren med full åtkomst, dels för att det går långsamt utan acceleration och dels för att det är tråkigt att behöva kopiera in tecken som @ och $ från något annat fönster – AltGr fungerar ju som sagt inte med begränsad åtkomst. Det får räcka med att webbläsaren inte kommer åt filerna under min hemkatalog.

Pidgin klarar sig däremot utan sådana finesser:

/bin/sh /usr/opt/bin/xsudo.sh -u _web /usr/local/bin/pidgin

Och tar man även bort "-u _web" ur ovanstående så körs pidgin förstås som root.

Om du nu vill börja köra något program som en annan användare, så vill du antagligen även flytta över programmets dotfiles till den andra användarens hemkatalog, innan du drar i gång programmet.

För Chromium och användaren _web ser processen ut så här:

kaja$ umask 077
kaja$ sudo -u _web mkdir -p ~_web/.config
kaja$ sudo cp -r ~/.config/chromium ~_web/.config/
kaja$ sudo chown -R _web._web ~_web/.config/chromium

Det var det hela. Skriptet kommer bo och uppdateras på diskussionsforumet.

Ändra och skriva ut skyddade PDF-dokument

I det här inlägget beskriver jag några olika sätt att kringgå utskrifts- och ändringsskydden i PDF-dokument. Om du struntar i varför det går, så kan du klicka här för att hoppa över inledningen, som förklarar varför detta är och alltid kommer vara möjligt.

Miniteori

En fördel för oss som inte gillar slentrianmässigt bruk av kopierings- eller redigeringsskydd, är att sådana skydd egentligen är teoretiskt omöjliga. Varför det är på det viset, kan förklaras rätt enkelt med ett Alice and Bob-exempel.

Alice kallar vi avsändaren av ett stycke information, till exempel ett dokument eller en film. Den mottagare som Alice tänker sig kallar vi för Bertil. Alice vill dela med sig av sin information till Bertil utan att Eva får tag på den, eftersom Eva kopierar eller redigerar allt hon kommer över. (Och häng med här: Om Eva inte gjorde detta, så skulle hon inte längre vara Eva, utan ännu en Bertil.)

När det gäller hemlig kommunikation mellan Alice och Bertil, så är det möjligt att hålla Eva utom hörhåll, till exempel genom att viska eller lämna över ett USB-minne. Men problemet för Alice, när hon publicerar ett skyddat PDF-dokument, är att Eva därmed får tillgång till dokumentet, och kan titta på det precis som Bertil.

En enkel tumregel, som aldrig slår fel, är att om man har tillgång till ett stycke information så kan man kopiera den. Och det man kan kopiera kan man också redigera.

Utskriftsskyddet är enkelt att besegra, eftersom det är korkat. Skyddet går nämligen enbart ut på att PDF-dokumentet berättar vad man får och inte, och när PDF-läsare sedan öppnar dokumentet, så stänger de i regel lydigt av alla otillåtna funktioner. Lösningen på problemet är alltså inte svårare än att man helt enkelt struntar i vad dokumentet säger att man får göra och inte.

Vad som däremot inte är lika lätt, är att komma åt åtkomstskyddade dokument som man inte har rätt nyckel, certifikat eller lösenord till. Det är visserligen genomförbart, men ofta inte särskilt praktiskt eller snabbt. Inte heller är det särskilt intressant att förfalska signerade dokument.

När du gör en oskyddad kopia enligt metoden nedan, så tas de enkla skydden bort, alltså de där som går ut på att dokumentet berättar vad man får göra eller inte, och hoppas att man är duktig och lyder. Resultatet blir ett rent PDF-dokument utan sådana förmaningar eller andra tillbehör.

Avlägsna utskrifts- och redigeringsskydd

Man kan skapa oskyddade kopior av skyddade PDF-dokument på flera intressanta sätt. Den som googlar kan till exempel hitta patchar för både ghostscript, xpdf och pdftools.

Men den metod jag beskriver här är den som är enklast att återge och genomföra, om än inte den mest praktiska att använda i längden. Det enda du egentligen behöver är qpdf.

Windows-användare får det enklast om de hämtar arkivet qpdf_vc6_exe.zip, och packar upp .exe-filen i en mapp som är enkel att hitta tillbaka till. Vill du inte använda kommandoprompten, så rekommenderar jag att du även hämtar det här zip-arkivet, och packar upp .bat-filen i samma mapp som du lade qpdf_vc6.exe.

Sedan är installationen färdig. För att ta bort alla skydd från ett PDF-dokument, så tar du tag i dokumentet, och släpper det på ikonen som heter Släpp skyddade PDF-dokument på mig. I samma mapp som PDF-dokumentet ligger dyker strax en oskyddad kopia av det upp.

Om du inte vill behöva trycka på en knapp varje gång du konverterat ett dokument, så sätter du ett dubbelkolon (alltså ::) framför raden pause i .bat-filen. (Men då kommer du inte hinna se vad som gick snett, om något gick snett.)

På andra operativsystem än Windows använder du qpdf så här:

$ ./qpdf --decrypt "Skyddat original.pdf" "Oskyddad kopia.pdf"

Och om du vill köra qpdf i Windows själv, utan .bat-fil:

C:\...>.\qpdf_vc6.exe --decrypt "Skyddat original.pdf" "Oskyddad kopia.pdf"

Kommandot innebär att qpdf ska göra en oskyddad kopia av dokumentet Skyddat original.pdf och spara den som Oskyddad kopia.pdf.

Ett annat sätt: doPDF

Ett alternativt sätt att skapa oskyddade PDF-dokument i Windows är att installera doPDF. Därigenom dyker det upp en ny skrivare på datorn, som heter doPDF. När du skriver ut ett dokument till den skrivaren, så blir du ombedd spara ett PDF-dokument någonstans. Du kan alltså göra PDF-dokument av vad som helst som går att skriva ut.

Om du till exempel skapat ett Word-dokument med typsnitt som inte får bäddas in i en PDF, så kan du göra det ändå, genom att skriva ut till den här skrivaren.

Om man vill använda den här alternativa metoden för att skapa oskyddade kopior av PDF-dokument, så fungerar den givetvis bara om PDF-originalen tillåter utskrift.

(Ett liknande program är PDFCreator. Fördelen är att det är öppen källkod, vilket doPDF inte är. Nackdelen är att installationsprogrammet på ett riktigt envist sätt försöker få dig att installera en reklamsnyltare också. Installerar du på slentrian, utan att granska varenda förbaskad kryssruta, så blir dina webbläsare kapade och fyllda med reklam, och varje steg du tar på nätet kartläggs fortsättningsvis av vad det nu är för reklamföretag.)

Åtkomstskyddade PDF-dokument

Det finns flera variationer på den här typen av skydd, och alla är lika irriterande. Vissa dokument kräver bara att man matar in rätt lösenord för att man ska få se dem, medan det är värre med andra. Vid något tillfälle köpte jag till exempel Språknämndens Svenska Skrivregler som PDF.

Det dokumentet går inte att öppna i Adobe Reader, som klagar över saknade "skyddsinsticksprogram". Efterhand som Adobe uppdaterat sin programvara har de funktioner som krävs för att öppna boken försvunnit, och nu är det alldeles för opraktiskt att komma åt innehållet.

Hade jag ansträngt mig litet medan jag fortfarande kunde öppna boken, så hade jag kunnat göra en kopia utan åtkomstskydd, men det var jag visst för bekväm för.

Så nu är jag inte någon Bertil längre, skulle man kunna säga. Adobes kunder för den här typen av dokumentskydd är förstås inte heller sådana som jag, alltså folk som vill läsa sina böcker, utan bokhandlarna. Och de lär inte protestera särskilt högljutt, för jag hade ju inget annat val än att köpa boken en gång till. Fast den gången blev det den mycket dyrare pappersvarianten.

Att tröttna på reklamen

För någon vecka sedan blev jag varse att någon meningslös rackare anmält en obefintlig epostadress på en av mina domäner till ett företags nyhetsbrev.

Jag gillar såklart inte skräppost, och därför har jag ett bra och enkelt spamfilter (bmf) integrerat via procmail.

Filtret tränar jag dock enbart på sådan skräppost som inte har någon tydlig avsändare. När något spårbart företag däremot skickar ut sina (vanligtvis legitima) nyhetsbrev, så vill jag inte att de ska fastna i filtret. Därför lägger jag ned en del tid på att bli av med sådana utskick, istället för att bara träna filtret på dem.

Men hur blir jag av med dem då? Vanligtvis läxar jag helt enkelt upp avsändaren genom att berätta på vilket eller vilka sätt deras utskick bryter mot lagen:

Huvudregeln är att det är förbjudet att skicka e-postreklam till konsumenter och enskilda firmor. Företag får bara skicka e-postreklam om mottagaren i förväg har tackat ja till att få reklam från företaget. Tidigare var det tillåtet att skicka e-postreklam om mottagaren inte hade tackat nej.

Om det finns ett "etablerat kundförhållande" mellan företag och konsument, till exempel om du har köpt något från företaget, får företaget skicka e-postreklam – men bara om följande förutsättningar är uppfyllda:

  • Du får inte ha tackat nej till att din e-postadress används i marknadsföringssyfte.
  • Marknadsföringen måste gälla företagets egna likartade produkter som den du har köpt förut.
  • Du måste få möjlighet att kostnadsfritt och enkelt förhindra att e-postadressen används i marknadsföringssyfte.

I e-postreklamen ska det alltid finnas en giltig adress dit du kan skicka en begäran om att marknadsföringen ska upphöra.

Detta är oerhört effektivt. Nio av tio företag svarar, ber om ursäkt och rättar till det hela.

Men ibland orkar jag inte vara instruktiv och trevlig, och senast så skedde var nyss. För någon vecka sedan anmäldes som sagt en (icke existerande) epostadress på en av mina domäner till ett företags utskickslista. Följaktligen började jag få deras nyhetsbrev på min catch-all.

Det vill jag absolut inte ha! Som tur var så fungerade avprenumerationslänken.

Ändå damp snart nya utskick ned. Det visar sig att adressen hade anmälts till väldigt många av deras nyhetsbrev, och att varje utskickslista krävde en egen avprenumeration. Detta riskerade att bli väldigt irriterande eftersom det finns jättemånga utskickslistor – en per större stad i Sverige. Dessutom verkar adressen ha hamnat på listor som hör till städer även utanför Sverige. Kanske över hundra listor sammanlagt!

Så många orkar jag absolut inte göra mig av med, men jag provade att avprenumera ett par av de nya listorna. Det fungerade inte. Således var utskicken olagliga. Nå, den här gången orkade jag faktiskt inte bråka om den saken.

Istället ville jag ha litet mellandagsroligt, och gjorde så här:

  1. Jag satte upp en forward från den ogiltiga adressen som fick utskicken, så att de hädanefter skickas vidare till företagets support.
  2. Sedan skickade jag ett epostmeddelande till deras support, från den adress jag nyss forwardat, där jag förklarar vad jag gjorde, varför jag gjorde det, och avslutade med uppmaningen att de ska »observera att det inte går att svara på detta meddelande :-)«.
  3. Till sist log jag i mjugg.

Om det i praktiken drabbar dem på något otrevligt vis är förstås osäkert, och det enda jag kan vara säker på är att jag hade kul. Deras skräppostfilter kanske sorterar bort deras egna nyhetsbrev? I sådana fall borde alla vara nöjda och skräppostfria alldeles omedelbart.

Men det kan förstås vara annorlunda också. I värsta fall, insåg jag tyvärr först senare, så har de ett ticket-system, som skickar ut bekräftelser på att ens supportärende emottagits. Dessa bekräftelser levereras ju i sådana fall till min numera forwardade adress, och därifrån vidare tillbaka till deras support.

Och om personen som kodat ticket-systemet är en klant, vilket inte är det minsta osannolikt, så har han eller hon knappast förutsett att ticket-systemet kan råka få en ticket-bekräftelse. Då kommer bekräftelsemeddelandet att föranleda ytterligare ett bekräftelsemeddelande, som denna gång levereras direkt till deras support-adress. Detta kommer i sin tur att föranleda ett likadant bekräftelsemeddelande, och så vidare.

En DoS-attack var ju inte riktigt vad jag hade tänkt mig. Men lika förhoppningsvis som antagligen så blev det inte någon sådan av det hela. Men visst hade det varit litet roligt även då? :-)

Kan man jämföra OpenBSD och SELinux?

Jag har fått en fråga! Kurt undrar så här:

En säkerhetsfråga från en novis.

Vad jag förstår så bygger säkerheten i OPENBSD på att undvika säkerhetshål, så ingen kan komma in. Säkerheten i SELINUX bygger väl på principen att om någon kommer in kan de inte göra något elakt. Skulle man inte kunna kombinera principerna och implementera SELINUX i OPENBSD och därmed få ett supersäkert system?

Det korta svaret är: Nej.

Ett förtydligande tillägg lyder: Beskrivning av de båda projekten är inte riktigt riktig.

En längre utläggning följer. :-)

Jag tror båda projekten sysslar med både intrångssäkerhet och intern säkerhet i lika hög utsträckning. Däremot skiljer de sig från varandra på så vis att SELinux (nästan) bara är en åtkomstmodell, som så att säga "står i mitten" och försöker styra upp eventuella taskigt konstruerade program, medan OpenBSD är ett helt operativsystem (i ordets vidare bemärkelse).

OpenBSD innefattar till exempel varianter av GNU-kompilatorn och Apache-servern, och är »hemsystem« för både OpenSSH och sudo, och GCC-varianten som följer med har ett inbyggt skydd mot stack-smashing. SELinux omfattar däremot inte ens något skal, och än mindre någon kompilator, utan är en uppsättning patchar för Linux-kärnan.

Projekten är alltså inte helt jämförbara, eftersom SELinux bara är en modifikation av Linux-kärnan, medan OpenBSD är både en unik kärna och ett userland bestående av unika program (alltså ungefär en »distribution« på Linux-språk, fast en distribution där alla program kommer från samma källa istället för att ha plockats ihop från olika håll).

Vill man göra en ordentlig jämförelse, så bör det alltså vara mellan OpenBSD och en enskild Linux-distribution (till exempel Ubuntu, Fedora eller Slackware), inte mellan OpenBSD och Linux (vilket vore litet som att jämföra en päronplantage med ett mandelträd.)

Om vi ägnar en stund åt de områden där jämförelser ändå går att göra i någon mån, alltså sådana områden där projekten i en annan värld hade kunnat vara likadana, så finns det faktiskt flera väsentliga skillnader. Den säkerhetsmässigt mest avgörande tror jag är inställningen till användaren. OpenBSD bibehåller aktivt en viss inlärningströskel, och de flesta program som utgör ens en perifer säkerhetsrisk är inte aktiverade på en fräsch installation. Konfigurering sker därtill i regel på klassiskt vis, genom att man ändrar i textfiler, vilket i sin tur kräver att man läser de noggrant underhållna man-sidor som följer med systemet.

Inlärningströskeln gör att man måste lära sig en del om hur programmen fungerar för att få dem att bete sig som man vill, eller för att ens starta dem. Konsekvensen är (förhoppningsvis) mera upplysta användare och administratörer, vilket i grund och botten är vad all säkerhet går ut på, både intern och extern.

I rättvisans namn så är en sådan inriktning antagligen omöjlig att genomföra för SELinux. Projektets fokus är rent kodmässigt betydligt snävare, och svängrummet är därför mera begränsat. Kärnan har inget som helst inflytande över hur svåra eller lätta program är att administrera, hur säker programmens kod är, vad som körs och inte körs direkt efter en installation eller hur bra dokumentationen av programmen är. Däremot kan en kärna vara konstruerad så att den begränsar skadeverkningarna av dåliga program (vilket givetvis inte är förbehållet SELinux, utan gäller alla kärnor).

Att kombinera SELinux och OpenBSD är i praktiken omöjligt. Linux är rent kodmässigt en klon av Unix, medan BSD-systemen är direkta avkomlingar. BSD-systemen (däribland Darwin under OSX) har var sina egna kärnor, som liknar och delar viss kod med varandra, medan Linux-kärnan har en helt egen struktur och bygger på helt annan kod. BSD är alltså inte Linux, men Linux är (tillsammans med GNU-systemet som brukar följa med) ursprungligen skapat för att efterlikna BSD:s förfäder.

Linux-kärnan är dessutom GPL-licensierad, vilket gör det mycket svårt att använda kod därifrån i BSD-systemen, eftersom de i regel använder olika varianter på BSD-licensen. OpenBSD använder numera mestadels en ISC-licens, som i praktiken bara kräver att licenstexten och copyright-snutten lämnas orörda, och det endast i källkoden. Därför kan man hitta BSD-licensierad i helt sluten programvara, som Windows, marslandaren och en del routrar. GPL tillåter inte något sådant.

Den licensen kräver ju en hel del mer, bland annat att samma licens gäller alla ändringar och tillägg i koden, och att den alltid är tillgänglig till självkostnadspris för alla som har programmet. Om du infogar GPL-kod i ett BSD-licensierat program så måste hela programmet därefter distribueras enligt GPL-villkoren. Det är alltså inte omöjligt att infoga GPL-kod i BSD-licensierade program, men det är få BSD-utvecklare som vill, eftersom de tycker BSD-licensen passar dem bättre.

Om man däremot tar BSD-kod och placerar i GPL-program, så uppstår inga problem förrän någon får lust att hämta tillbaka eventuella förbättringar i koden till ett BSD-program; detta är omöjligt utan att hela programmet blir GPL-licensierat istället. På så vis är BSD-licensen alltid den »svagare« i relation till GPL.

Men som tur är, så tror jag det vore onödigt att kombinera själva idéerna i SELinux med OpenBSD-kärnan. Jag vågar inte påstå att det vore ett säkerhetsmässigt nerköp för OpenBSD, men det skulle nog inte heller tillföra något väsentligt. Ibland talas det om att den mera flexibla filåtkomst-modellen som SELinux implementerar skulle vara en fördel i OpenBSD, men i praktiken kan man uppnå samma effekt med den för Unix-system traditionella åtkomstmodell som OpenBSD använder. En fördel med den traditionella modellen är att den är lättare att förstå sig på och överblicka.

Jag hoppas det här duger som svar på frågan. Dessutom kostar jag på mig brasklappen att jag inte är någon »säkerhetsexpert«, vare sig i betydelsen white hat, eller på så vis att jag försörjer mig genom att varna för internetmaskar åt något antivirusföretag. ;-)

Däremot är jag intresserad sedan flera år tillbaka. Kritiska eller utvecklande kommentarer är med andra ord (också) välkomna!