Als u RSBAC gaat inzetten, zult u slechts die modellen/modules moeten gebruiken die u ook daadwerkelijk behoeft - en vooral ook: waarvan u precies snapt hoe ze werken en hoe ze geconfigureerd moeten worden. De meeste 'gangbare' beveiligingsbehoeften kunnen goed worden afgedekt door gebruik te maken van een combinatie van het AUTH, RC en FF model, die ik daarom in een latere paragraaf nader zal beschrijven.
De overige modellen (ACL, MAC, FC, SIM, PM, MS, CAP en REG) zijn heel specifiek inzetbaar voor speciale toepassingen. Sommige van deze modellen zijn tamelijk theoretisch, van sommige overlapt de functionaliteit met andere, sommige zijn complex of moeilijk beheerbaar, het FC model daarentegen wordt weer gezien als moeilijk inzetbaar omdat het een te beperkte granulariteit kent. Het RSBAC PM model maakt - voor zover mij bekend als enige ter wereld! - een correcte implementatie van de strenge Europese privacy wetgeving binnen een geautomatiseerd systeem mogelijk.
Deze rijkdom aan meegeleverde modellen kan op de nietsvermoedende beginner verwarrend werken. Het is echter een sterk punt van RSBAC. Je kunt vrijelijk kiezen welk(e) model(len) je wilt gebruiken. Modellen die je niet snapt, laat staan gebruikt, compileer je eenvoudigweg niet mee - ze nemen dan ook geen resources in beslag.
Daarbij kent RSBAC de REG module - dat is eigenlijk geen module in de reguliere zin van het woord. Het is een interface/raamwerk waarbinnen u zelf modules kunt schrijven die door de ADF worden aangeroepen. Dergelijke modules kunnen ook dynamisch worden geladen als 'gewone' kernel modules. Bij de broncode worden een aantal voorbeelden meegeleverd. Mocht u dus speciale behoeften hebben die met een bestaand model niet te verwezenlijken zijn kunt u desnoods uw eigen model implementeren. Zeer krachtig.
De AUTH module is een verplicht onderdeel van RSBAC. Haar functionaliteit ondersteund alle andere modellen. AUTH staat subjecten toe om hun identiteit te wijzigen, met andere woorden: zich te AUTHenticeren. De Linux implementatie van de AUTH module behandeld oproepen van een proces om van UID te wisselen. Of aan de oproep gehoor moet worden gegeven wordt bepaald aan de hand van in de ACI opgeslagen gegevens.
De AUTH module kan uiteraard slechts aan een proces permissie geven om van UID te wisselen, maar binnen de RSBAC administratie (ACI) kan ook voor programma's worden bijhouden dat ze permissie hebben om met AUTH rechten te draaien. Als zo'n programma binnen een proces wordt geladen zal een verzoek om wijziging van UID door de AUTH module worden gehonoreerd - het proces 'erft' de rechten die gezet zijn voor het programma. Als een proces/programma geen rechten heeft toegewezen gekregen houdt dit in dat de default opgaat - en dat er dus geen rechten zijn om van UID te wisselen. Dat is trouwens lastig bij het initiele booten van RSBAC: je kunt dan per default NIET inloggen op je systeem, omdat het programma /bin/login de permissies niet heeft om van UID te wisselen... in het volgende artikel geef ik aan hoe je daar tijdelijk omheen kunt werken om je systeem op gang te kunnen krijgen.
AUTH permissies kunnen worden uitgeven op 2 niveau's: ofwel mag een proces/programma elk UID aannemen wat het maar wil (auth_may_setuid) of u geeft expliciet aan naar welke UID's gewisseld mag worden (de zogenaamde 'capabilities', auth_may_set_cap).
Configuratie van de AUTH module wordt gedaan middels de command line utility 'auth_set_cap'. Per default is RSBAC zo geconfigureerd dat alleen een aanroep vanuit een process van de security officer (met default UID 400) wordt gehonoreerd.
Het File Flags model implementeert additionele toegangsattributen voor files, fifo's en directories. Deze attributen zijn generiek, dus: gelden voor alle subjecten (processen) op het systeem. Zoals gewoonlijk wordt de ACI gebruikt om de extra attributen in op te slaan. Per object waarvoor extra attributen worden gezet worden (momenteel) 9 bits gebruikt. De volgende vlaggen worden onderscheiden (de waarde tussen haakjes is de bitwaarde): read_only (1), execute_only (2), search_only (4), write_only (8), secure_delete (16), no_execute (32), no_delete_or_rename (64), add_inherited (128) en append_only (256). Hun betekenis wordt meen ik uit de omschrijving voor de meeste vlaggen voldoende duidelijk, maar een paar verdienen nadere toelichting:
de secure_delete flag zetten houdt in dat bij het wissen van een file de data van het file wordt overschreven door NULL-characters, waarmee het bijna onmogelijk is om te achterhalen wat er ooit in het file heeft gestaan. Deze optie werkt niet op alle filesystems, maar wel bij ext2, msdos/vfat en minix.
de add_inherited flag zetten houdt in dat de attributen die je zet voor dit object worden toegevoegd aan de attributen van de bovenliggende directory. Pas op: dat kan inhouden dat sommige files niet meer toegankelijk zijn, bijvoorbeeld als read_only op het hogere niveau is gezet en write_only en add_inherited op het file zelf.
De meeste rechten erven over naar objecten onder het huidige: dat houdt in dat bijvoorbeeld het zetten van een vlag op een directory ook geldt voor alle objecten (files/directories/fifo's) onder die directory. Dit geldt echter niet voor het add_inherited en secure_delete bit.
Het zetten van fileflags kan worden gedaan via de utility attr_set_fd, bijvoorbeeld:
$ attr_set_fd FD ff_flags 1 /a/b/c |
Het Role Compatibility model sluit nauw aan bij de manier waarop mensen gewend zijn te denken. Mensen zeggen dingen als 'een operator mag alleen maar logfiles lezen'. Een operator is een bepaalde functie, iemand die een bepaalde rol speelt in een proces. Het RC model maakt ook gebruik van het concept 'rollen'. Een rol is vrij vertaald een label wat hoort bij een set van taken die door een gebruiker uit mag worden gevoerd, bijvoorbeeld 'operator' of 'webmaster'. Bij zo'n rol hoort een bepaalde set van bevoegdheden, die zich vertalen naar mogelijkheden om (bepaalde typen van) toegang te krijgen tot bepaalde (klassen van) objecten.
De objecten worden daartoe ingedeeld in typen, die op hun beurt ook weer een naam krijgen, bijvoorbeeld 'logfiles' of 'webdocumenten'. Een rol krijgt een aantal mogelijkheden voor toegang tot bepaalde objecttypen. Bijvoorbeeld: de rol 'operator' mag bij objecten van het type 'logfile' waarbij hij uitsluitend mag lezen. De objecten binnen het RC model zijn van klasse FD (Files/Directories), IPC, DEV, SCD en PROCESS.
Door het RC model te gebruiken kan een subject dus uitsluitend een zekere mate van toegang krijgen tot een object door eerst een bepaalde rol aan te nemen. Daarvoor moet het subject uiteraard eerst zijn geautoriseerd. Als dat zo is, kan het subject het object benaderen, gesteld dat zijn huidige rol 'compatibel' is met dat object. Elk subject krijgt een initiele rol toegewezen - deze rol wordt overgenomen door alle door het subject gegenereerde subjecten. Dus: Jan Schuier logged in als 'schuier', krijgt daarmee een rol toegewezen (e.g. 'rolschuier'), en zijn shell heeft dan ook de rol 'rolschuier'.
Het is binnen het RC model mogelijk om 'van rol te wisselen'. Daartoe moet het subject een speciale systeemaanroep uitvoeren, of een programma laden wat een zogenaamde 'geforceerde rol' heeft, waarover straks meer. Het wisselen van rol mag alleen maar als de beide rollen op hun beurt weer 'compatible' zijn: het wisselen van rol A naar rol B mag alleen maar als dat expliciet door de security officer is aangegeven als een mogelijkheid. Daarbij is het niet noodzakelijkerwijze zo dat je weer terug kunt schakelen naar je oude rol. Dus: rol B kan dus niet compatibel zijn met de rol A, terwijl de rol A wel compatibel is met rol B.
Pas op: het UID van een proces heeft geen noodzakelijke relatie met de rol van een proces. Een proces kan bijvoorbeeld de rol 'operator' hebben en, gesteld dat die rol die bevoegdheid heeft, mag dat proces zonder meer wisselen naar een ander UID - maar houdt dan wel de rol 'operator'. Het is wel mogelijk om van UID te wisselen en dan via een system call te wisselen naar de default rol die bij dat UID hoort.
Programma's kunnen ook een attribuut gezet krijgen wat aan hen een zogenaamde 'geforceerde rol' toebedeeld: als een proces dat programma laadt zal daarbij geforceerd een bepaalde rol aan het proces worden gegeven. Dit is handig, om mensen op gecontroleerde wijze toegang tot bepaalde objecten te geven via programma's. Per default heeft een executable geen geforceerde rol en 'erft' dan de rol die het subject/proces heeft als het het programma laadt. Er is ook een vlag die u kunt zetten om af te dwingen dat de initiele rol die bij een bepaald UID hoort wordt aangenomen als het programma wordt geladen, het programma moet daartoe wel setuid gemaakt zijn en van de AUTH module toestemming krijgen om te wisselen.
Een voorbeeld van gebruik maakt de concepten mogelijk nog duidelijker. Laten we eens kijken naar een anonieme ftp server. Een dergelijke ftp server wordt typisch in een chroot gevangenis gezet, wat op zich al veel beveiligingsproblemen oplost. We kunnen in deze situatie de veiligheid verder vergroten met behulp van het RC model.
We nemen dan een rol 'ftpserver' op en voegen ook een FD-objecttype 'publicfile' toe. De ftp-server geven we als default rol 'ftpserver', zodat alle processen die deze server start met deze rol zullen lopen. De directories waarin we publieke bestanden zetten configureren we zo dat ze van het type 'publicfile' worden - dat zorgt er tevens voor dat alle onderliggende files/directories ook van dit type worden. Vervolgens configureren we de rol 'ftpserver' zo, dat ze uitsluitend lees- en searchrechten krijgt voor objecttype "publicfile". De ftp server moet uiteraard bij het netwerk kunnen, dus moeten we ook nog een IPC object type 'ftpnet' definieren. We geven dan de rol 'ftpserver' het CREATE en DELETE recht op object type 'ftpnet' en we zetten voor de rol 'ftpserver' het default IPC type op 'ftpnet'.
Mocht het nodig zijn om toch bepaalde executables uit te voeren (de kopie van) /bin/ls, bijvoorbeeld) dan kan nog een rol 'ftp-executable' worden gedefinieerd, die een kopie is van de rol 'ftpserver', maar met additionele rechten om executables uit te kunnen voeren. /bin/ls krijgt dan een geforceerde rol 'ftp-executable' en daarmee heeft het proces wat dat programma gaat draaien automatisch de juiste rechten.
De configuratietools zijn rc_copy_role, rc_get_item en rc_set_item. In het volgende artikel geven we een meer gedetailleerd volledig uitgewerkt voorbeeld van het gebruik van deze tools. Een uitgebreid soortgelijk voorbeeld (het beveiligen van een webserver) kan in de RSBAC documentatie worden gevonden.