Introductie
In nagenoeg alle bedrijven wordt aandacht besteed aan het beveiligen van systemen of data, maar dit wordt vaak gezien als een technisch feestje. Het technische deel van de beveiliging is echter slechts een onderdeel van de totale keten. Steeds vaker kiezen bedrijven voor een abstract en onderbouwd beveiligingsmodel, dat van bovenaf wordt opgelegd.
Security Enhanced Linux is hier een goed voorbeeld van. Gebaseerd op een abstract mathematisch model vindt het zijn uiteindelijke toepassing in een technische implementatie. Beveiliging wordt steeds minder gezien als een puur technische aangelegenheid, dat vooral lastig is voor de eindgebruiker. Steeds meer bedrijven kiezen ervoor beveiliging te implementeren als een bedrijfsbrede eis, gebaseerd op een gefundeerde visie van bovenaf en geïmplementeerd volgens de daaruit volgende richtlijnen.
De vraag naar implementaties van theoretisch bewezen beveiligingsmodellen wordt hierdoor ook steeds groter. Een beveiligingsmodel biedt handvatten voor een bedrijf om beveiliging op een structurele manier door te voeren. Administratief kan worden verplicht alles op papier vast te leggen, procedureel kan er voor gezorgd worden dat bijvoorbeeld belangrijke beslissingen nooit door slechts één persoon kunnen worden genomen en technisch kan er voor gekozen worden om een uniforme en sterke vorm van encryptie te implementeren. Een goed voorbeeld hiervan is SE Linux, een implementatie van een zogenaamd trusted model.
SE Linux is een mac-implementatie binnen de Linux-kernel. SE Linux is bedoeld als een consistente access control-implementatie, waarbij het principe van least privilege het uitgangspunt is. SE Linux richt zich hierdoor op vertrouwelijkheid van data binnen een systeem. Uitgangspunt is dat er aan alle objecten een label wordt gekoppeld die de vertrouwelijkheid van het object weergeeft. Binnen deze context is een object een entiteit waar een object of iemand toegang tot vraagt.
De SE Linux-toevoeging zorgt ervoor dat de reeds aanwezige functionaliteit van de kernel niet beïnvloed wordt en is derhalve ook in een korte tijd geaccepteerd als de facto standaard. De toevoeging bestaat uit een centrale autoriteit die bepaalt welk subject toegang heeft tot welk object. Deze vorm van flexibiliteit worden bereikt door gebruik te maken van de flask-architectuur.
Discretionary access control
Op dit moment is dac de meest gebruikte vorm van access control. Dit is een methode waarbij elk bestand en directory wordt voorzien van een eigenaar. Deze eigenaar kan vervolgens bepalen wie wat met de directory of het bestand mag doen, door middel van zogenaamde read/write/execute bits. Het voornaamste punt van dit systeem is flexibiliteit; iedereen kan zijn eigen bestanden beheren en naar wens toegang verlenen en ontnemen.
Een minder sterk punt van dac is de wat gebrekkige controleerbaarheid. Elke gebruiker zal z'n eigen richtlijnen handhaven met betrekking tot toegang van bestanden en daardoor ontbreekt uniformiteit binnen de implementatie veelal. Daarnaast wil een gebruiker meestal niet lastig worden gevallen met te strikte privileges. Hierdoor ontstaat het risico van 'privilege escalation'.
In de praktijk kan privilege escalation bijvoorbeeld voorkomen op een webserver. Deze service draait normaal gesproken onder een speciaal account, zoals op Linux doorgaans de apache- of httpd-user. Het is mogelijk dat een bug of exploit wordt gevonden in Apache die een normale websitegebruiker toegang verschaft tot het systeem. De gebruiker kan dan code uitvoeren onder het systeemaccount van de webserver. Als het systeem onvoldoende beschermd is tegen exploits, kan de gebruiker zich vervolgens de toegang verschaffen tot het root-account of een soortgelijke user met privileges, met alle gevolgen van dien. Ook kan aan een meer horizontale vorm van privilege escalation worden gedacht, waarbij een gebruiker toegang krijgt tot de data van een andere gebruiker.
Bell-Lapadula
Al in de jaren zeventig was de Amerikaanse defensie bezorgd om de beveiliging van de systemen en de vertrouwelijkheid van documenten. Als reactie op deze bezorgdheid werd door de Amerikaanse defensie het Bell-Lapadula-model ontwikkeld. Dit is een mathematisch model dat het concept van een 'secure state machine' en modes van toegang beschrijft in toegangsregels. Dit wordt bereikt door alle objecten te voorzien van labels die omschrijven wie toegang heeft tot wat. Wanneer iets of iemand toegang krijgt tot een object wordt er gesproken van een transition state. Het Bell-Lapadula model waarborgt de secure state van de machine door gebruik te maken van de volgende drie kernregels:
Simple security rule: Deze regel beschrijft dat een subject met een bepaald security level geen leesrechten heeft op objecten met een hoger security level (No read up).
Star property: Deze regel beschrijft dat een subject met een bepaald security level geen schrijfrechten heeft naar objecten met een lager security level (No write down).
Strong star property: Deze regel beschrijft dat een subject alleen lees- en schrijfrechten heeft op objecten van een gelijkwaardig security level. Als een subject dus leesrechten wil tot een object, dan moeten de security levels van beide onderwerpen gelijk zijn.
Mandatory access control
Mandatory access control is de daadwerkelijke implementatie van het Bell-Lapadula-model, Hierbij maakt uiteindelijk het OS de uiteindelijk beslissing of een subject toegang heeft tot een object. Deze beslissing wordt genomen door een centrale autoriteit, wat mac een meer gestructureerd model maakt dan dac.
Zoals in Bell-Lapadula omschreven maakt mac gebruik van labels. Ieder subject en ieder object krijgt een label dat het niveau van vertrouwelijkheid weergeeft. Vervolgens wordt er aan de hand van dit label bepaald of een subject toegang krijgt tot dit object. Dit gebeurt alleen als de vertrouwelijkheidsniveaus van het subject en het object gelijk zijn. Is dit niet het geval, dan wordt er minimaal een van de drie Bell-Lapadula-regels overtreden. Op deze manier wordt er gegarandeerd dat vertrouwelijke informatie niet gelekt wordt naar een minder vertrouwd subject en dat het object niet 'vervuild' raakt met data waarvan de vertrouwelijkheid lager ligt.
Het vertrouwelijkheidsniveau van zowel subjecten als objecten wordt bepaald door de security officer, geconfigureerd door de systeem administrator, afgedwongen in het besturingssysteem en ondersteund door de beveiligingstechnieken.
Flask
Volgend op onderzoeken naar een zo flexibel mogelijke manier om regels te creëren die zich 'on the fly' kunnen aanpassen aan veranderingen in het systeem, is de National Security Agency in de VS begonnen met de ontwikkeling van de Flask-architectuur.
In een systeem waarbij een policy zich direct kan aanpassen zou deze de huidige stand van zaken binnen het systeem kunnen laten meewegen om een beslissing te nemen over de toekomstige stand van zaken. Het is echter zeer twijfelachtig of een systeem zo flexibel kan zijn dat het beslissingen kan nemen over elke staat waarin een systeem zich op dat moment bevindt.
Wat veel realistischer is, is om het deel van het systeem te identificeren dat beveiligingstechnisch relevant is en vervolgens dat deel onder de security policies te laten vallen. Het nadeel daarvan laat zich raden, zodra een deel van het systeem niet compleet in de policy is opgenomen, valt er een gat in de beveiliging.
De architectuur van Flask is gebaseerd op het prototype van het distributed trusted operating system, dat dezelfde doelen nastreefde als de huidige Flask-architectuur. Het nadeel van het dtos-systeem was echter dat deze geen ondersteuning biedt voor dynamische security policies. Op het hoogste niveau is Flask compatibel met het gfac-model, dat ervan uit gaat dat alle operaties op het systeem zich in een autonome ruimte afspelen. Bij moderne computersystemen is dit echter niet het geval en lastig te realiseren. Flask lost deze tekortkoming op.
Flask is een mac-implementatie waarbij met name gelet is op het intrekken van rechten. Normaliter is het binnen een mac-implementatie lastig om uitgereikte rechten in te trekken zolang een proces of gebruiker toegang heeft tot de resource. Binnen de Flask-architectuur is dit probleem opgelost door gebruik te maken van een Security Server die een policy afdwingt.
Policies en voordelen
De SE Linux-configuratie wordt beschreven in modulaire policies. De kern van deze policies wordt tegenwoordig steeds vaker gevormd door de zogenaamde Reference Policy. Dit is een set met universele definities voor de meest voorkomende onderdelen van het systeem, zoals netwerktoegang of toegang tot de kernel. Nieuwe applicaties met nieuwe modules kunnen eenvoudig gebruikmaken van de handvatten die de Reference Policy biedt, waardoor deze modules kort en overzichtelijk blijven. Bovendien wordt voorkomen dat bepaalde stukken in meerdere applicatiespecifieke policies moeten worden gedefinieerd.
Doordat SE Linux weinig tot geen invloed heeft op de bestaande onderdelen van de kernel en de reeds ingeladen modules, kan het activeren van nieuwe modules gebeuren zonder dat een herstart van het systeem noodzakelijk is. Slechts bij de eerste activering en bij zeer grote wijzigingen is het opnieuw opstarten van het systeem noodzakelijk.
De grote kracht van SE Linux is het gecontroleerd toegang kunnen geven tot resources. Hierbij kan een resource zowel data zijn, een stuk hardware of een andere applicatie op het systeem. Het eerder genoemde voorbeeld van privilege escalation op een webserver is niet mogelijk als er gebruik wordt gemaakt van SE Linux. De Security Server zal afdwingen dat Apache binnen zijn eigen context moet blijven, ook al is de applicatie zelf kwetsbaar voor een vulnerability. Naar schatting kan iets meer dan de helft van alle in 2007 door Cert gerapporteerde en van buitenaf te misbruiken lekken in daemons met SE Linux worden geminimaliseerd .
SE Linux kan volledig achteraf worden geïnstalleerd en geconfigureerd. Het schrijven van een policy voor een applicatie begint met het analyseren van de behoeften van onder meer de benodigde resources en netwerktoegang van de applicatie. Aan de hand hiervan kan een basispolicy voor de applicatie worden geschreven, die het uitgangspunt voor de uiteindelijke policy vormt. Hiermee is SE Linux geen extra last voor de ontwikkelaar van de applicatie en is het mogelijk de policy na het ontwikkelen van de applicatie te schrijven.
Wel vereist SE Linux diepgaande kennis van zowel de applicatie als het systeem zelf. Een policyschrijver moet het gedrag van de applicatie, inclusief systemcalls, kunnen verklaren.
Conclusie
SE Linux is geen garantie voor een veilig systeem. Wel is het een belangrijke stap naar een gecontroleerde informatiestroom binnen een systeem of organisatie.
Daarnaast legt SE Linux alleen de focus op de vertrouwelijkheid van informatie. Een ander essentieel onderdeel van een gecontroleerde informatiestroom is de betrouwbaarheid en de integriteit van de informatie. Om de integriteit van informatie te kunnen waarborgen, kan er worden gekeken naar het gebruik van bijvoorbeeld pki. Applicaties en services op een systeem moeten nog steeds zo worden geconfigureerd dat alleen de strikt noodzakelijke functionaliteit aanwezig is. Uiteraard moet ook deze functionaliteit worden voorzien van de maximale beveiliging die de applicatie biedt.
SE Linux is een zeer krachtige toevoeging aan de Linux-kernel en wordt door alle grote Linux-distributies ondersteund. De totale beveiliging van het systeem komt op een hoger niveau te staan, waarbij subjecten alleen toegang hebben tot expliciet benoemde objecten. Toegang tot alle andere informatiestromen is niet mogelijk.
Dankzij het gebruik van de Flask-architectuur kunnen nieuwe policies eenvoudig worden toegevoegd en worden wijzigingen in de actieve policy direct actief, zelfs op reeds actieve processen.
/i/1245426289.png?f=fpa)
/u/13831/icon.png?f=community){kind=icon}
:strip_icc():strip_exif()/u/25814/camus_small.jpg?f=community){kind=small}
, Dit werkt natuurlijk niet als je een encrypt profiel hebt.
:strip_exif()/u/30938/sasame01b.gif?f=community){kind=small}
)
/u/36978/icon.JPG?f=community){kind=icon}
:strip_icc():strip_exif()/u/71766/borg.jpg?f=community){kind=small}
/u/229564/eic.png?f=community){kind=small}
:strip_icc():strip_exif()/u/14853/bluepiSW.jpg?f=community){kind=small}
/u/10064/leuk_he.png?f=community){kind=small}
:strip_icc():strip_exif()/u/39108/shakira-avatar.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/142351/IT_crowd60.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/26692/evil.jpg?f=community){kind=small}