Nadat we vorige maand het model en de inbedding van RSBAC hebben besproken zullen we in deze aflevering dieper in gaan op de vertaling naar het Linux platform.
RSBAC voor Linux bestaat uit patches op de Linux kernel die het raamwerk implementeren alsmede utilities om een beveiligingsmodellen te kunnen definieren/configureren. De code van het raamwerk vangt op de juiste plaatsen kernel-calls af en leidt deze om naar een ketting van beslissingsmodules. Als alle modules toestemming geven om de desbetreffende systemcall uit te voeren, wordt het verzoek gehonoreerd en de systemcall uitgevoerd. Anders wordt het verzoek geweigerd en de systemcall niet uitgevoerd. Dit wordt dan gelogged.
Een individuele module is bedoeld om een bepaald beveiligingsmodel te implementeren. Maar uiteraard is het mogelijk om meerdere modules te gebruiken om uw beveiligingsbeleid te implementeren. De modules worden daartoe binnen het raamwerk achter elkaar geschakeld en allemaal doorlopen. Elke module bekijkt welk proces welk verzoek indiend en voor welk object dat verzoek bedoeld is. Als de module meent dat wat het proces wil niet is toegestaan zal de bewerking niet worden uitgevoerd. Pas als aan het eind van de ketting er geen enkele module was die het verzoek afwees, dan pas wordt de bewerking toegestaan. Daarbij is het zo dat modules een eerdere afwijzing van een verzoek nooit meer ongedaan kunnen maken, dus: eens afgewezen blijft afgewezen (RSBAC kent dus een 'restrictief ontwerp'). RSBAC kent uitgebreide mogelijkheden om te loggen, zowel in de standaard logfiles als ook in een speciale, beveiligde ringbuffer.
Er wordt een set kant-en-klare modules meegeleverd, waarmee u diverse beveiligingsmaatregelen kunt treffen en ook tools om die modules te kunnen configureren. U hoeft slechts die modules te laden die voor een in uw ogen voldoende goede beveiliging noodzakelijk zijn. Het is daarnaast mogelijk om eigen modules te schrijven en binnen het raamwerk op te nemen. RSBAC biedt zo een flexibel, uitbreidbaar systeem, wat uitgebreide afdekking van risico's mogelijk maakt.
Er is bijvoorbeeld een module die zich bezig houdt met het afdwingen van additionele attributen voor delen van het filesystem (FF) - door hier gebruik van te maken kun u er onder meer voor zorgen dat nergens onder een gegeven directory executables uitgevoerd kunnen worden. Een andere module houdt zich bezig met het verifieren of een proces permissie mag gevan aan een ander proces om zijn UID te wijzigen (AUTH) - deze module maakt het mogelijk om processen (een beperkte set van) mogelijkheden te geven om van UID te wisselen. Dus: al heeft een programma de eigenaar 'root' en het setuid bit hoog - u kunt dan met de AUTH module alsnog nauwkeurig specificeren welke ID's aangenomen mogen worden. Dit geheel buiten de controle van het programma/proces wat met het setuid bit loopt, het kan weliswaar nog steeds een verzoek indienen bij de kernel om van ID te wisselen, maar de systemcall mislukt domweg (en wordt als dusdanig gelogged) als RSBAC geen toestemming geeft. Je kunt vele modules laden, waardoor het mogelijk wordt om vele modellen 'tegelijkertijd' te implementeren. Maar in de praktijk voldoen een paar eenvoudige modellen al om tot een significante verbetering te komen van de beveiliging en zijn de complexere modellen (bijvoorbeeld het Privacy Model PM) vooral voor specifiek gebruik bedoeld.