Dokumentbaserad säkerhet i Apache Solr ANDERS RASK

Dokumentbaserad säkerhet i Apache Solr ANDERS RASK Examensarbete Stockholm, Sverige 2012

Dokumentbaserad säkerhet i Apache Solr ANDERS RASK DD221X, Examensarbete i datalogi om 30 högskolepoäng vid Programmet för datateknik 270 högskolepoäng Kungliga Tekniska Högskolan år 2012 Handledare på CSC var Henrik Eriksson Examinator var Johan Håstad TRITA-CSC-E 2012:019 ISRN-KTH/CSC/E--12/019--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.kth.se/csc

Dokumentbaserad säkerhet i Apache Solr Sammanfattning En sökmotor är potentiellt ett väldigt stort säkerhetshål för en organisation. Använd på fel sätt kan sökmotorn exponera känslig information som ondsinta användare då kan ta del av och utnyttja. Även om de inte kan läsa dokumenten de hittar så kan vetskapen om att informationen finns där eller kontexten den hittas i vara nog så skadlig. Detta examensarbete undersöker olika sätt att implementera en dokumentbaserad säkerhet i sökmotorn Apache Solr. Det finns i stort sett två olika metoder för sökmotorn att tillgripa när den kontrollerar säkerheten: tidig bindning eller sen bindning. I en tidig bindning lagras dokumentens säkerhetsinformation tillsammans med dokumenten i indexet och säkerheten kan därför verifieras utan inblandning från datakällan. (Det kan dock behöva hämtas information om användarens grupper) I en sen bindning lagras ingen säkerhetsinformation i indexet och datakällan måste istället tillfrågas för varje dokument som ska returneras vid en sökning ifall användaren har rätt att läsa det. Säkerhetslösningen för Apache Solr bör vara flexibel och därför ha stöd för både tidig och sen bindning. För att kunna tillämpa en tidig bindning i Apache Solr krävs först och främst en förståelse för hur säkerheten fungerar i de datakällor som lösningen ska täcka. Sedan krävs det att säkerhetslösningen efterliknar den säkerheten på ett korrekt och effektivt sätt. Vidare bör lösningen vara enkel att bygga ut till fler system och därför inför jag begreppen säkerhetsmodell och säkerhetsleverantör som utbytbara komponenter. Den förra används för att i sökmotorn efterlikna säkerheten i en datakälla och den senare används för att antingen hämta användarinformation från en datakälla eller fråga en datakälla ifall användaren kan läsa ett visst dokument. Denna rapport kommer förklara hur en säkerhetsmodell för filsystemen NTFS och UFS samt innehållshanteringssystemen Documentum och Polopoly kan se ut. Den kommer även förklara hur Documentum och Polopoly samt katalogtjänsten Active Directory kan användas som säkerhetsleverantör.

Document level security in Apache Solr Abstract A search engine has the potential to be a significant security threat for an organization. Implemented incorrectly the search engine may reveal sensitive information which can be abused by a malicious user. Even if they cannot read the documents they find, simply knowledge of their existence or the context in which they are found can be damaging enough. This master thesis examins different ways to implement a document level security in the search engine Apache Solr. There are two significant ways in which a search engine may protect its information: early binding and late binding. In an early binding the document s security information is stored together with the document in the index. Therefore, access rights can be verified without any involvement from the datasource. (It may however need information about the user s groups) In a late binding no security information is stored in the index and the search engine must instead ask the data source for every document in the search result whether the user is allowed to read it or not. The security solution for Apache Solr should be flexible and should therefore have support for both early and late binding. In order to implement an early binding in Apache Solr it is important to have a deep understanding of how the security works in the underlying data source. It is important that the security solution is able to emulate this security in a correct and effective manner. The solution should also be easily extendable to other systems. Therefore, I introduce the terms security model and security provider as replacable components. The first is used in the search engine to emulate the security model of a data source and the second is used to either collect user information from a data source or to ask a data source if a user can read a certain document. This report will explain how a security model for the file systems NTFS and UFS, and the content management systems Documentum and Polopoly can look like. It will also explain how Documentum, Polopoly and the directory service Active Directory can be used as a security provider.

Bakgrund Det har hänt mycket inom området sökteknologi de senaste åren, men trots detta är det fortfarande ett relativt outvecklat område. Till skillnad från den allmänna uppfattningen är området inte färdigupptäckt bara på grund av Googles väldiga framfart. Framförallt finns det mycket utveckling kvar att göra för att även andra datakällor än World Wide Web ska bli enkla att söka i. Ett exempel är ett företags eller organisations intranät, där det ofta finns stora mängder information. För att göra denna information mer lätthanterlig för användarna är moderna sökteknologilösningar ett bra verktyg. På marknaden finns idag ett antal olika produkter som tillhandahåller söklösningar åt företag och organisationer. För att nämna några IDOL av Autonomy, Fast ESP av Microsoft och Google Search Appliance av Google. Förutom dessa proprietära produkter finns det en sökmotor med öppen källkod kallat Solr som är baserat på det likaså öppna sökmotorbiblioteket Lucene. Båda dessa utvecklas under Apache projektet. Examensarbetet är utfört på Findwise AB i Stockholm. Findwise affärsidé är att tillhandahålla kompetens på sökteknologiområdet. Med hjälp av någon av de sökprodukter som finns på marknaden idag så skapar Findwise anpassade söksystem åt företag och organisationer. Detta examensarbete fungerar som en del i att skapa mer kommersiell nytta kring Apache Solr. Rent konkret behandlar examensarbetet området datasäkerhet, och mer specifikt hur man skyddar dokument från att kunna sökas i Apache Solr av användare som inte har rättigheter att läsa dem i den ursprungliga datakällan. Detta är en väldigt viktig aspekt för många företag då det ofta finns dokument som alla anställda inte får ta del av. Alla proprietära system nämnda ovan har en lösning på detta problem medan Apache Solr förnärvarande saknar detta. Problem Hur säkerställer man att dokument indexerade från en eller flera datakällor inte kan ses vid en sökning av en person som inte har rätt att läsa dessa i den ursprungliga datakällan samt hur kan detta implementeras i Apache Solr. Syfte Detta examensarbete syftar till att undersöka hur en säkerhetslösning för dokumentbaserad säkerhet kan se ut i Apache Solr för innehållshanteringssystemen Documentum och Polopoly samt filsystemen NTFS och UFS. Denna undersökning ska även tillämpas i en prototyp som ska ge dokumentbaserad säkerhet i NTFS med stöd för att hämta användarinformation från Active Directory.

Innehållsförteckning Teoretisk grund... 1 1.1 Sökmotorer... 1 1.1.1 Sökmotorer och säkerhet... 2 1.2 Apache Solr... 4 1.2.1 Apache Lucene... 5 1.2.2 Säkerhet i Solr... 6 1.3 Åtkomstkontroll... 6 1.3.1 Ticket eller Access Control List... 7 1.3.2 Mellanliggande strukturer... 7 1.4 Filsystem... 8 1.4.1 NTFS... 9 1.4.2 UFS... 10 1.5 Innehållshanteringssystem... 11 1.5.1 Polopoly... 11 1.5.2 Documentum... 12 1.6 Katalogtjänster... 14 1.6.1 Active Directory... 14 En säkerhetslösning för Solr... 16 2.1 Säkerhetskomponenten i Solr... 17 2.2 Stöd för olika säkerhetsmodeller... 19 2.2.1 NTFS... 20 2.2.2 UFS... 20 2.2.3 Documentum... 21 2.2.4 Polopoly... 22 2.3 Stöd för olika säkerhetsleverantörer... 22 2.3.1 Active Directory... 22 2.3.2 Documentum... 22 2.3.3 Polopoly... 23 Analys av alternativa lösningar... 24 3.1 SearchComponent... 24 3.2 Tidig och sen bindning... 24 3.3 Säkerhetsleverantör och säkerhetsmodell... 24 Genomgång av prototypen... 25 4.1 Konfiguration av prototypen... 26 4.2 Implementation av prototypen... 28 4.3 ACL-extrahering från NTFS... 29 Slutsatser... 31 Litteraturlista... 32

1. Teoretisk grund Kapitel 1 Teoretisk grund Detta kapitel behandlar alla de olika områden som detta examensarbete berör. Tanken är att den ska ligga som en grund för resten av rapporten och skapa den förståelse som är nödvändig. 1.1 Sökmotorer Sökmotorn är den programvara bakom en söktjänst som möjliggör indexering av och sökning i stora textmassor. En sökmotor är bra på att hantera stora mängder ostrukturerad text. Detta i kontrast till en databas som är byggd för att hantera stora mängder strukturerade data. Figur 1 som är tagen från Konchady (2008) visar skillnaden mellan sökning i en databas och i en sökmotor. Till en databas ställs en SQL-fråga och en lista av rader innehållandes strukturerad data returneras. Medan det till en sökmotor ställs en boolesk fråga och en lista av referenser till dokument som träffats av frågan returneras. SQL fråga Lista av rader TABELLER Databas Student Namn Nummer......... Kurs Namn Nummer......... Sökning Boolesk fråga INDEX... Sökmotor Lista av referenser Figur 1: Sökning i databas och sökning i sökmotor (Konchady, 2008). En sökmotor, som illustreras i figur 2, består av tre komponenter: en spindel, en indexerare och ett sökgränssnitt (Konchady, 2008). Datakälla Spindel Indexerare Sökmotor Index Sökgränssnitt Figur 2: Sökmotorarkitektur. Figur 2 illustrerar hur spindeln hämtar data från en datakälla och skickar dessa vidare till indexeraren. Spindeln kan antingen vara en del av sökmotorapplikationen, en fristående applikation eller en del av datakällan. Som Konchady (2008) beskriver finns det olika sorters 1

1. Teoretisk grund spindlar som till exempel kan traversera ett lokalt filsystem, gå igenom ett intranät/internet eller hämta dokument från ett innehållshanteringssystem. Efter det att spindeln har hämtat data från datakällan skickas de till indexeraren (se figur 2). Dess huvuduppgift är att bygga indexet. Innan texten indexeras extraherar indexeraren den från dokumentet. Textextraheringen måste göras på olika sätt beroende på vilken filtyp dokumentet är. Större delen av texten tillhör oftast dokumentets huvuddel, men beroende på filtyp tillkommer olika metadata till dokumentet, till exempel författarens namn. När texten är extraherad analyseras den för att finna de informationsbärare (tokens) som ska indexeras. I sin enklaste form är varje informationsbärare ett ord, men oftast duger inte det utan man vill till exempel kunna indexera ett företagsnamn som en informationsbärare. Som Hatcher et al (2009) konstaterar kan analysen göras på många sätt: Hur hanteras sammansatta ord? Ska rättstavning på texten tillämpas? Ska synonymer till ord skjutas in i den indexerade texten? Ska orden i texten göras om till sin grundform? Det finns många sådana frågor som måste besvaras innan indexet kan byggas. Indexet i de allra flesta sökmotorer är ett så kallat inverterat index. Det inverterade indexet är en kompakt datastruktur (Konchady, 2008). För att förstå hur säkerheten för de indexerade dokumenten fungerar senare i denna rapport krävs en grundläggande förståelse för hur ett inverterat index fungerar. Det som gör indexet inverterat är att informationsbärarna används som uppslagsord till dokumenten; informationsbäraren istället för dokumentet är alltså den centrala enheten. Hatcher et al (2009) förklarar det så här: istället för att svara på frågan Vilka ord ingår i det här dokumentet? så svarar det inverterade indexet på frågan Vilka dokument innehåller ord X?. Som exemplifieras i tabell 1 och 2 lagrar det inverterade indexet alla informationsbärare med hänvisningar till i vilka dokument de finns. Ett riktigt inverterat index hade förutom dessa referenser även lagrat var i dokumentet de påträffats. Något som kan noteras är att de vanliga orden på och en inte har indexerats. Tabell 1: Lista på dokument och tillhörande text (Konchady, 2008). Dokument Id Text 1 Kalle satt på Nils. 2 Nils såg Kalle. 3 Kalle fick en katt. Tabell 2: Inverterat index över dokumenten i tabell 1 (Konchady, 2008). Ord Dokument Kalle 1, 2, 3 satt 1 Nils 1, 2 fick 3 Katt 3 När indexet är skapat kan det sökas i. Sökning sker genom att sökmotorn tillhandahåller ett gränssnitt (se figur 2). Mycket kan göras för att förbättra utfallet av en sökning, men prestandan för sökningar är oftast väldigt viktigt så allt för tidskrävande operationer bör undvikas. Vilket kommer framgå av denna rapport är dokumentsäkerhet en sådan sak som riskerar att bli alldeles för tidskrävande ifall den görs på fel sätt. 1.1.1 Sökmotorer och säkerhet Sökmotorer som indexerar webben, till exempel Google, undviker att indexera sådan information som allmänheten har begränsad åtkomst till. Detta på grund av att belastningen för 2

1. Teoretisk grund att säkerställa säkerheten för resultaten skulle bli enorm med den mängd dokument och det antal användare som finns på webben (Bailey et al, 2006). En sökmotor som indexerar ett intranät kan dock inte göra det valet. Det finns flera olika säkerhetsaspekter att ta i beaktande för att en sådan sökmotor ska kunna anses säker. Detta examensarbete fokuserar på säkerheten för den indexerade texten vid sökningar. Det vill säga att otillåtna personer inte ska kunna läsa information de inte är behöriga till, eller ens se att den existerar. Textsäkerhet kan implementeras på flera olika nivåer: Datakälla med säkerhet på källnivå får en användare antingen läsa all information från en datakälla eller ingen alls. Dokument med säkerhet på dokumentnivå har användare olika rättigheter till olika dokument. Detta är ett populärt sätt att lösa säkerheten på då många källsystem hanterar säkerheten på detta sätt. Det är också det sätt som detta examensarbete kommer att fokusera på. Fält med säkerhet på fältnivå delas ett dokument upp i flera fält där användare har olika rättigheter till olika fält. Att implementera säkerheten på dokumentnivå betyder att man oftast kan använda de befintliga säkerhetsstrukturerna för filer som finns i datakällan. Det vanligaste är att säkerheten för filerna i datakällan är implementerad med en Access Control List (ACL) för varje fil. Mer om detta under rubriken 1.3 Åtkomstkontroll. Det finns två huvudsakliga strategier att använda vid implementering av säkerhet i en sökmotor: tidig bindning och sen bindning. Tidig bindning Fil rapport.doc ACL kalle: läsa, skriva anställda: läsa Användare: Nils Datakälla Spindel Sökmotor Grupp: anställda Användarinformation Figur 3: Datakälla indexerad med tidig bindning, samt sökning i denna. Figur 3 illustrerar en tidig bindning med två moment som sker vid olika tidpunkter: indexering och sökning. Vid indexering läser spindeln in ACL-informationen tillsammans med filen rapport.doc. Som ACL-informationen visar har användaren kalle rättigheter att läsa och skriva medan gruppen anställda endast har rättigheter att läsa rapport.doc. Texten samt vilka användare och grupper som har läsrättighet till filen skickas vidare till indexeraren för indexering. ACL-informationen lagras alltså som metadata till dokumentet i indexet. När användaren Nils vid en annan tidpunkt söker efter rapport.doc efterfrågar sökmotorn först vilka grupper Nils tillhör och matchar sedan dessa samt Nils användarnamn mot ACL-metadatan till rapport.doc. Matchningen kan ske genom att sökmotorn ovanpå Nils fråga lägger ett filter som filtrerar bort alla dokument som inte har korrekt ACL-metadata. 3

1. Teoretisk grund Sen bindning Sökmotor Sökning Sökresultat Användare: Nils Fil Fil rapport.doc JA text.txt NEJ Filtrering på användare Nils Datakälla Figur 4: Sen bindning använd mot datakälla. I en sen bindning lagras ingen ACL-information i indexet utan istället tillfrågas datakällan om användaren har rättighet att läsa ett visst dokument. I figur 4 visas hur användare Nils gör en sökning. Resultatet på denna sökning måste innan den returneras filtreras genom att datakällan tillfrågas om Nils har rättigheter att läsa dokumenten. Detta måste göras för varje dokument som ska returneras i sökresultatet. I det illustrerade exemplet kommer endast rapport.doc att returneras eftersom Nils inte har rättigheter att läsa text.txt. Det riskerar förstås att bli en kostsam process i de fall då en användare söker på ett ord som förekommer i väldigt många dokument men användaren bara har rättighet att läsa ett fåtal av dessa. 1.2 Apache Solr Apache Solr, eller Solr som jag kommer benämna den i resten av texten, är öppen källkod och utvecklas under Apache Software Foundation. Solr bygger på sökmotorn Lucene och är en sökmotorserver som ska köras i en Java servlet container, till exempel Apache Tomcat (Solr hemsida). 4

1. Teoretisk grund DispatchFilter RequestHandler ResponseWriter Search Search Component Component Solr core Lucene Solr Figur 5: Hantering av sökning och resultat i Solr. I figur 5 visas en förenklad bild av hur en sökning i Solr hanteras. Den innehåller de huvudsakliga aktörerna och visar vilken väg en sökning tar för att producera ett resultat till användaren. 1. En sökning kommer in via HTTP till ett filter (dispatch filter) som bestämmer, beroende på konfiguration eller användarval, vilken Request Handler den ska skicka sökningen till. 2. Vald Request Handler anropar sedan de Search Components som är konfigurerade till den. a. Först prepare i vilken alla Search Components får en chans att ändra sökningen eller göra annat innan den utförs. b. Sedan process där alla får en chans att agera utifrån resultatet på sökningen. 3. När Request Handlern har returnerat anropar filtret vald Response Writer som skriver resultatet i rätt format. 4. Resultatet returneras till användaren. Indexering av dokument i Solr sker genom en XML-syntax som skickas med HTTP POST meddelanden. Sökning sker även det över HTTP, men här i form av HTTP GET förfrågningar. 1.2.1 Apache Lucene Lucene är precis som Solr öppen källkod och ett Apache projekt. Det är ett sökmotorbibliotek som tillhandahåller indexering och sökning åt applikationer som till exempel Solr. Den är i sig alltså inte i första hand en fristående applikation. 5

Administrationsgränssnitt Analyseringsgränssnitt Dokumentsäkerhet i Apache Solr 1. Teoretisk grund Sökgränssnitt Bygg fråga Rendera resultat Utför fråga Index Indexera dokument Analysera dokument Bygg dokument Hämta data Figur 6: En sökmotor med Lucene. Figur 6, från Hatcher et al (2009), visar hur en applikation kan använda sig av Lucene. De grå delarna är sådant som Lucene sköter och de vita delarna sköts av den applikation som använder Lucene, så som Solr. 1.2.2 Säkerhet i Solr Solr har ingen inbyggd säkerhet för text eller kommunikation (Solr hemsida). 1.3 Åtkomstkontroll Åtkomstkontroll är en fundamental del av området datasäkerhet och så också i detta examensarbete, det är faktiskt just det som detta arbete syftar till att implementera i Solr. Som Gollman (2006) berättar används åtkomstkontroll på många olika sätt i en dator eller ett system. Ofta handlar kontrollen om integriteten för data, det vill säga att två samtidiga instanser inte ska få skriva samtidigt till samma minnesområde. Det som menas i denna rapport och som är intressant från en användares perspektiv är dock åtkomstkontroll över vilka filer hon får eller inte får läsa. Användare/ subjekt Operation Referensmonitor Objekt Figur 7: Åtkomstkontroll. Åtkomstkontroll, i den mening som illustreras av figur 7, består enligt Gollman (2006) av två steg, autentisering av användaren och auktorisering av användaren på ett visst objekt. Som visas i figur 7 kan åtkomstkontroll illustreras av att ett subjekt, till exempel en applikation, använder en användares identitet till att utföra en operation på ett objekt. En referensmonitor säger då om detta är tillåtet eller ej. 6

1. Teoretisk grund Det finns olika sätt att lagra de rättigheter en användare har till ett objekt. Det mest elementära sättet är att lagra alla rättigheter i en matris, en så kallad Access Control Matrix, där alla användare i systemet finns längs den vertikala axeln och alla objekt i systemet längs den horisontella. Rättigheterna för en användare till ett visst objekt skulle då ges av den cell som ligger i användarens rad och objektets kolumn. Detta är dock ingen bra modell för ett system som innehåller väldigt många objekt och användare eller då rättigheterna ändras ofta (Gollman, 2006). Istället lagrar man rättigheterna antingen hos användarna eller hos objekten. 1.3.1 Ticket eller Access Control List Då rättigheterna lagras hos användarna talar man om capabilities (förmågor). Som Gollman (2006) skriver finns det problem med att lagra rättigheterna hos användarna. Det är väldigt svårt att få en överblick över vilka användare som har rättigheter till ett visst objekt och det blir således väldigt svårt att dra in eller ändra rättigheterna till ett objekt. I takt med att distribuerade system blir allt vanligare blir emellertid detta sätt att hantera rättigheter vanligare. I distribuerade system sköts detta ofta med hjälp av en ticket som användaren tar med sig mellan systemen. Då rättigheterna lagras hos objekten talar man om Access Control Lists. Detta är det vanligaste sättet att hantera rättigheter i kommersiella operativsystem (Gollman, 2006) men används även flitigt i andra system som behöver hantera rättigheter. Det är således ett centralt begrepp för detta examensarbete. Med en Access Control List (ACL) lagras rättigheterna till ett objekt hos objektet. Detta gör det enkelt att åstadkomma en tidig bindning i Solr. Eftersom ACL-informationen är kopplad till objektet kan systemet tillfrågas om vilka rättigheter som finns på objektet vid indexeringstid och därefter lagra dessa i indexet enligt förfarandet vid tidig bindning. Mapp exempel/ Fil Fil Fil rapport.doc program.exe text.txt ACL kalle: läsa, skriva lisa: läsa ACL kalle: exekvera lisa: exekvera ACL kalle: läsa, skriva lisa: läsa, skriva Figur 8: ACL-information kopplad till filer i ett filsystem. I figur 8 visas hur ACL-informationen kan se ut för filer i ett filsystem. Det finns två användare: Kalle och Lisa. Medan Kalle har rättigheter att både läsa och skriva rapport.doc har Lisa endast rättighet att läsa denna. Båda har rättigheter att exekvera program.exe samt att läsa och skriva text.txt. 1.3.2 Mellanliggande strukturer För att göra det enklare att administrera rättigheterna i stora system finns det ofta en eller flera mellanliggande strukturer. De jag kommer referera till i denna rapport är tre olika strukturer: grupper, roller samt negativa rättigheter. Grupper och roller används för att ge samma rättigheter till flera användare som har något gemensamt. I samband med detta kan negativa rättigheter användas för att ge administratören mer flexibilitet. 7

1. Teoretisk grund Grupper är något som existerar i de flesta av de mer avancerade säkerhetsmodellerna. Antingen så att användaren bara kan vara medlem av en grupp, men oftare att hon kan vara medlem i flera grupper samtidigt. Tanken är att man ska samla de användare som ska ha tillgång till samma information i samma grupp och sedan ge denna grupp rättigheter till de berörda objekten. Grupper förenklar administrationen av rättigheter väsentligt. u 1 u 2 u 3 u 4 u 5 Användare g 1 g 2 Grupper o 1 o 2 o 3 o 4 o 5 o 6 Objekt Figur 9: Användare i grupper. I figur 9, tagen från Gollmans (2006) bok, visas ett system där alla användare är med i en eller två grupper och dessa grupper har sedan tilldelats rättigheter till ett antal objekt. Detta är idealfallet, när endast grupperna behöver tilldelas rättigheter. I verkligheten kan man dock behöva ge enskilda användare speciella rättigheter eller frånta dem rättigheter som gruppen har. För att administrera detta finns det i många säkerhetsmodeller en möjlighet att ge negativa rättigheter till en användare eller en grupp, det vill säga frånta användare rättigheter som de annars skulle haft. u 1 u 2 u 3 Användare g 1 Grupper o 1 o 2 o 3 o 4 o 5 Objekt Figur 10: Negativ rättighet. I figur 10 (Gollman, 2006) visas hur användare u 1 inte har rättigheter till objekt o 1 trots att den grupp användaren är med i har dessa rättigheter. En annan typ av mellanliggande struktur är roller. Role-Based Access Control (RBAC) används inte så flitigt i operativsystem men är vanligare i databaser (Gollman, 2006) och i vissa innehållshanteringssystem. En användare av ett sådant system kan bara befinna sig i en roll i taget och alla användare med samma roll har då samma rättigheter till samma objekt. Alla dessa mellanliggande strukturer är viktiga för utformningen av den säkerhetslösning för Solr som detta examensarbete lägger fram. 1.4 Filsystem Det finns många olika filsystem ute på marknaden. Den säkerhetslösning för Solr som beskrivs i denna rapport påverkas av hur säkerhetsmodellen ser ut i de filsystem den ska stödja. Säkerhetslösningen ska vara så flexibel att det ska vara enkelt att lägga till stöd för olika 8

1. Teoretisk grund filsystem. Prototypen som beskrivs i senare kapitel kommer att ha stöd för NTFS, men jag kommer även redogöra för hur ett stöd för Unix-system som använder POSIX rättigheter kan se ut. 1.4.1 NTFS NTFS (New Technology File System) är det filsystem som har använts i Microsoft Windows sedan versionerna NT/XP. NTFS är ett avancerat filsystem som det kan skrivas åtskilligt om. Det som är relevant för denna rapport är dock bara hur åtkomstkontroll för filerna fungerar. NTFS säkerhetsmodell bygger på en ACL-struktur där varje objekt har en länk till en Security Descriptor som finns lagrad i en metadatafil kallad $Secure. Varje Security Descriptor är unik och delas av de objekt som har likadana rättigheter. Detta leder till effektivare utnyttjande av diskutrymme. Security Descriptorns delar förklaras av tabell 3. Tabell 3: Security Descriptor (NTFS.com). Fält Förklaring Huvud Owner_SID Group_SID DACL SACL Revisionsnummer och kontrollflaggor till security descriptorn. Security Identifier för ägaren av objektet. Security Identifier för ägarens huvudgrupp. Discretionary Access Control List. Kontrollerar åtkomsträttigheter för objektet. System Access Control List. Kontrollerar loggning av åtkomstförsök till objektet. Till varje objekt hör alltså två olika ACL:er: DACL och SACL. DACL kontrollerar vilka användare eller grupper som har rättigheter till objektet medan SACL kontrollerar hur loggning av åtkomster till objektet ska ske för olika användare och grupper. Ägaren till objektet är den som kontrollerar innehållet i DACL:en, medan det är systemadministratörerna som kontrollerar innehållet i SACL:en. För säkerhetslösningen i Solr är endast DACL:en av betydelse. Varje ACL (DACL och SACL) innehåller en ordnad lista av Access Control Entries (ACE). I en ACE definieras vad en användare eller grupp får göra (DACL), inte får göra (DACL) eller loggas när de gör (SACL). Tabell 4: NTFS avancerade och grundläggande rättigheter (NTFS.com). Rättigheter Full kontrol Ändra Läsa & exekvera Lista mappinnehåll Läsa Skriva Traversera mapp/exekvera fil x x x x Lista mapp/läsa data x x x x x Läs attribut x x x x x Läs utökade attribut x x x x x Skapa filer/skriv data x x X Skapa mappar/bifoga data x x X Skriv attribut x x X Skriv utökade attribut x x X Radera undermapp och filer x Radera x x Läs rättigheter x x x x x X Ändra rättigheter x Ta ägarskap x Synkronisera x x x x x X I tabell 4 visas NTFS alla olika rättighetstyper. Raderna innehåller de mer specifika avancerade typerna och kolumnerna visar vilka avancerade rättigheter som hör till vilka grundläggande rättigheter. När ACL:en indexeras i sökmotorn är det intressanta vilka som har rättigheten lista mapp/läsa data. 9

1. Teoretisk grund I NTFS kan ett objekt få rättigheter på två sätt: explicit och genom arv. Explicita rättigheter är sådana som sätts antingen när objektet skapas eller av en användare. Ärvda rättigheter ges till barnobjekt av dess föräldrar, alltså när en fil ärver rättigheter från den mapp den ligger i. NTFS innehåller också negativa rättigheter. En användare eller grupp kan alltså nekas rättigheter till ett objekt som den eller de annars skulle haft. När NTFS ska göra en åtkomstkontroll följer den DACL:ens ACE:er i ordning. Dessa är placerade utefter ett speciellt företrädesschema som ser ut som följer (NTFS.com): 1. Explicit negativ rättighet. 2. Explicit positiv rättighet. 3. Ärvd negativ rättighet. 4. Ärvd positiv rättighet. Även inom de ärvda rättigheterna sker ett företräde, först för ett objekts förälder och därefter dess förförälder och så vidare. När NTFS kalkylerar användarens rättigheter på ett objekt följer den alltså denna ordning och stannar så fort den efterfrågade rättigheten är satt. Om detta är en negativ rättighet så avslås begäran på objektet, om det är en positiv rättighet så godtas det. Hittas inte den rättighet som är efterfrågad så avslås begäran. 1.4.2 UFS UFS (UNIX File System) är standardfilsystemet som kommer med Sun Solaris. Som McDougall et al (2006) berättar har UFS traditionellt sett en ganska enkel filrättighetsmodell där användare ges rättigheter baserat på tre kategorier: 1. Ägare. 2. Ägarens grupp. 3. Världen (alla andra). Figur 11 (McDougall et al, 2006) visar en utskrift av kommandot ls l för filen rapport.doc och exemplifierar hur filer i denna modell kan ha olika rättigheter för ägaren, ägarens UNIX grupp och världen (alla andra). Användare i ägarens grupp kan läsa filen Användare utanför ägarens grupp kan läsa filen -rw-r--r-- 1 kalle anställda 194745 Apr 2 18:29 rapport.doc Ägaren kan läsa och skriva filen Filägarens användarnamn Filägarens grupp Figur 11: Traditionella rättigheter i UNIX. Det finns tre olika rättigheter som kan ges: r för läsning, w för skrivning och x för att kunna exekvera en fil. För att kontrollera en användares åtkomst till en fil används dess uid (user id) och gid (group id) på följande sätt (Gollman, 2006): Om användarens uid sammanfaller med filägarens uid används ägarens rättigheter för att kontrollera åtkomsten. Om användaren inte är ägare till filen men dess gid är samma som gruppen som äger filen används gruppens rättigheter för att kontrollera åtkomsten. Om varken användarens uid eller gid ger rättigheter så används rättigheterna för världen för att kontrollera åtkomsten. 10