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:

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

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.

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å? :-)

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 ett mandelträd med en päronplantage.)

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 det 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 egen 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!

Jag läser att flera Linux-system (eller ja, åtminstone Fedora) har en pseudo-enhet som heter /dev/watchdog. Funktionen är denna: Om ett program öppnar enheten för läsning, men sedan inte hör av sig på någon minut, så startas systemet om.

Detta är puckat. Det är också själva syftet med enheten.

Problemet är att om enheten kan öppnas av vem som helst, så kan vem som helst starta om systemet:

Men om enheten bara är läsbar för root då, i sådana fall kan väl ändå inte vem som helst ta ned burken? Så fungerar ju (enligt uppgift) SELinux.

Det hjälper inte. Gör så här så får du reda på varför:

En sådan sökning ger dig en lista över alla program som körs som root. Det innebär att de kan öppna enheten.

Allt du behöver göra är alltså att lista ut hur du ska få något av dem att öppna /dev/watchdog för läsning, men sedan inte något mera. Det är tokmöjligt.

Som webbparanoid står man inför ständiga faror. Tänk om min webbläsare har något farligt säkerhetshål, som någon otrevlig webbsida jag råkar besöka får för sig att utnyttja för att ladda upp alla mina filer, eller än värre ta bort dem helt?

Problemet går givetvis att lösa på flera sätt, och lika givet är att ingen lösning är fullkomlig. Den jag tänker lägga fram här torde fungera som försvar mot de flesta »opersonliga« attacker man kan råka ut för. Om någon däremot faktiskt är ute efter dig så har du nog ingen glädje av det.

Vad vi kommer att göra är att ordna så att Firefox (och faktiskt vilka program du vill) kan köras utan rättigheter till din home-katalog. Simpelt som en plätt.

The following takes place in a unix-like environment. Du måste ha sudo och XTerm installerat.

Skulle sudo bråka med dig, se avsnittet längre ned om sudo.

1. Skapa en ny användare på ditt system, och döp den till något smart. Låt oss kalla den _web. Ge den en egen home-katalog som heter /home/web.
2. Spärra all tillgång till din egen home-katalog för andra användare än du själv:

   $ chmod og-rwx $HOME

3. Kontrollera att användaren _web berövats sådan tillgång:

   $ echo "Den här textfilen får du inte läsa." > ~/kontrollfil.txt
   $ sudo -u _web cat ~/kontrollfil.txt
   Password:
   cat: /home/jesper/kontrollfil.txt: Permission denied

   Sedan kan du ta bort testfilen:

   $ rm ~/kontrollfil.txt

   Om inget permission blev denied så har du ett konstigt filsystem. Lämna en kommentar!
4. Kopiera din webbläsares inställningskatalog till den nya användaren. Använder du Firefox heter den .mozilla och kör du Opera är det .opera. Kopiera katalogen såhär:

   $ sudo cp -r $HOME/.mozilla /home/web/
   $ sudo chown -R _web._web /home/web/.mozilla

   Och liknande för Opera:

   $ sudo cp -r $HOME/.opera /home/web/
   $ sudo chown -R _web._web /home/web/.opera

   En del andra webbläsare sparar sina inställningar i en katalog inuti katalogen .config, däribland Midori. För att kopiera en sådan katalog måste du gå litet annorlunda tillväga.

   $ sudo -u _web mkdir /home/web/.config
   $ sudo cp -r $HOME/.config/midori /home/web/.config
   $ sudo chown -R _web._web /home/web/.config

5. Med ett par enkla trollformler kan du nu köra igång din webbläsare under en annan användare, men med samma inställningar som dem du kopierade från ditt vanliga konto. Men trollformler är inte roliga att komma ihåg, så vi automatiserar det hela med ett skalskript. I exemplet lägger vi det i filen $HOME/bin/webuser.sh, och detta är vad den skall innehålla:

   #!/bin/sh
   if [ X$1 == X ]; then exit; else app=$(which $1); fi
   xhost localhost && cd /home/web/ && \
       sudo -H -u _web env HOME=/home/web $app --display localhost:0.0&

   (Eventuellt klagar någon insatt läsare på att $HOME-variabeln får samma värde flera gånger om. Men det verkar faktiskt krävas i vissa sammanhang, och jag är osäker på varför.)
6. Sista stegets utförande lämnar jag som en övning åt läsaren. Det som måste skapas är en ikon, ett menyalternativ eller något annat fiffigt, som vid aktivering gör bruk av den smått makalösa trollformeln ovan:

   xterm -geometry 20x1 -e 'sudo sh $HOME/bin/webuser.sh WEBBLÄSARE'

   Det sista ordet ska givetvis inte vara »WEBBLÄSARE«, utan det kommando som din webbläsare startas med. Till exempel firefox. Om du får välja mellan att köra kommandot i ett terminalfönster eller inte, så kan du välja att låta bli.

Vad kommer hända när du dubbelklickar på den där ikonen? Jo, en pytteliten ruta dyker upp på skärmen som frågar efter lösenord. Det är sudo som frågar, och i sina flesta inkarnationer är det lösenordet till ens eget konto det ber om. Vanligtvis frågar sudo inte heller efter lösenordet oftare än kanske var tionde eller tjugonde minut. Programmet kommer nämligen ihåg lösenordet åt dig en stund efter att du matat in det.

Om sudo bråkar!

Om sudo inte vill låta dig hålla på med sådant precis hur som helst, så kan du lägga till följande rad i slutet av filen /etc/sudoers – men akta dig! Om du råkar göra den filen ogiltig kan du bli utelåst från ditt eget system!

Första ordet ska förstås inte vara user, utan ditt eget användarnamn på din burk. Detta är viktigt! Gör du fel, som sagt, så får du rejäla problem, och kommer sitta och svära över att du aldrig lärt dig ed, en texteditor anpassad för en tid då man hade skrivare istället för datorskärmar. (Jag skojar inte.)

Ett sätt att undvika sådana missöden är att försöka redigera filen med följande kommando:

Ersätt gedit med den texteditor du gillar att använda. När du ändrat färdigt i filen och sparar och stänger, så kommer visudo kontrollera att filen är riktig. Har du gjort något tokigt kommer den ge dig en chans att reparera skadan innan det är för sent.

Och till sist, om du inte gillar att sudo kommer ihåg dina lösenord, lägg till följande rad långt upp i /etc/sudoers, bland de andra Defaults-raderna, om du har några.

Det var allt!