Unix is indertijd niet echt ontworpen met veiligheid in het achterhoofd. Dat het toch een goede reputatie heeft opgebouwd als 'veilig' systeem is meer te wijten aan de notoire onveiligheid van andere besturingssystemen dan aan de kwaliteiten van het 'standaard' Unix beveiligingsmodel. En aan de flexibiliteit van het Unix systeem, waardoor je tamelijk eenvoudig extensies en work-arounds kunt implementeren.
Hoe veilig wilt u zijn? Deze artikelreeks kan u helpen om te beoordelen wat de mogelijkheden van RSBAC zijn. Kennis van de mogelijkheden om risico's te beperken is echter maar een stukje van uw beveiligingspuzzel. U dient zich vooral bewust te zijn welke risico's u loopt en welke tegenmaatregelen u wilt nemen om deze risico's te beperken. Als particulier mag u menen dat er op uw systemen niet veel te halen valt voor een buitenstaander, maar denkt u eens aan uw lokale Netscape cache in combinatie met telebankieren of uw on-line bestellingen per creditcard. Of aan bedrijfskritische gegevens in uw (Open)Office bestanden, en/of vertrouwelijke stukken, uw post, uw belastingaangifte en wat er allemaal nog meer op uw systemen te vinden is. Voor een kwaadwillende een ideale visvijver. En dan hebben we het nog niet over volk wat er behagen in schept om 'voor de lol' uw systeem onderuit te helpen, of uw systeem als afzender voor dubieuze mail te gebruiken. Het aanvaarden van deze risico's kan (hoge) kosten met zich meebrengen - maar een tegenmaatregel ook, bijvoorbeeld omdat uw systeem moeilijker toegankelijk wordt voor normaal gebruik, of trager wordt, of omdat de kosten voor (de installatie van) de software hoog zijn. U dient daarom, voor u enthousiast RSBAC (of andere security extensies) gaat installeren eerst een beveilingsbeleid op te stellen. Hoe formeel u dat doet hangt af van uw context: in een bedrijf dient dit beveiligingsbeleid te worden vastgelegd en continue bijgesteld te worden als de bedrijfsprocessen en/of hun context wijzigen. Als particulier gebruiker is het tenminste nodig er eens goed over na te hebben gedacht en kan het geen kwaad om een soortgelijke strategie te voeren als een bedrijf. Het valt buiten de strekking van dit artikel om uitgebreid in te gaan op 'beveiligingsbeleid' - mogelijk iets voor een later artikel. Ik noem voor de liefhebber RFC1244 (http://www.faqs.org/rfcs/rfc1244.html), wat u een aardige leidraad geeft over het opstellen en raffineren van een beveiligingsbeleid. Hierin worden ook vuistregels gegeven om tot een beveiligingsbeleid te komen:
RSBAC kan vooral helpen bij het beveiligen van data en systeembronnen op uw systeem tegen ongeautoriseerde toegang. RSBAC is dus een middel om restricties op te kunnen leggen aan het gebruik van uw systeem. Daarmee beperkt u bepaalde risico's, maar restricties zijn ook hinderlijk. U moet zich daarom altijd eerst afvragen "Waarom zou ik mezelf deze beperkingen opleggen - wat staat daar voor mij aan nuttigs tegenover?" Ervaring leert me dat de prijs die u betaalt voor installatie van RSBAC laag is in verhouding met de risico's die u er mee kunt beperken. Maar soms gaat op dat zelfs het gemankeerde Unix beveiligingsmodel voldoende veiligheid biedt voor uw gebruik - dan is RSBAC voor u dus overbodig. |
Op een Unix (Linux) systeem worden toegangen tot systeemobjecten zoals bestanden en geheugen middels processen verricht. Dergelijke processen worden geinitieerd door of namens (systeem)gebruikers en maken gebruik van programma's om bepaalde taken te kunnen verrichten.
De taken op een computersysteem kunnen veilig worden uitgevoerd als het proces juist voldoende rechten heeft. Als een proces meer rechten krijgt dan strikt noodzakelijk wordt een mogelijkheid geschapen voor het programma binnen het proces om toegang te krijgen tot objecten waar het niets te zoeken heeft. Via bugs in de code of zelfs opzettelijk als dusdanig geschreven programma's kunnen dan objecten worden benaderd waarvan dat niet de bedoeling was. Dat kan resulteren in verlies van data en/of slechtere prestaties van het systeem.
Je zou dus verwachten dat er op Unix systemen veel zorg was besteed aan het kunnen toekennen van de juiste rechten. Dat is maar beperkt waar: op de meeste Unix systemen hebben processen veel te veel rechten en worden veel beveilingszaken derhalve op applicatieniveau geregeld. De oorzaak ligt in de grove granulariteit van het standaard beveiligings mechanisme. Daarnaast is configuratie van de beveiliging vaak een probleem.
Toegang tot systeemobjecten (geheugen, diskdrives etc.) wordt door de kernel geregeld. Om te kunnen bepalen of een proces toegang heeft hangen er aan sommige objecten lijsten waarin permissies worden gedefinieerd. Deze worden door de kernel gecontroleerd. De granulariteit van deze permissies is, zoals gezegd, grof. Voor bestanden bijvoorbeeld kennen we lijsten die op basis van 1 gebruiker of een groep van gebruikers lees- schrijf- of uitvoertoegang geven. Meer typen permissies zijn standaard niet gedefinieerd, en individuele rechten toewijzen aan meer dan 1 gebruiker is slechts beperkt mogelijk, door gebruik te maken van een groepenmechanisme. Elke gebruiker in zo'n groep krijgt dan wel exact dezelfde rechten als een andere gebruiker in die groep.
De systeemgebruiker 'root' is nog een verhaal apart. 'root' is een uitermate gevaarlijke gebruiker: een proces wat eenmaal 'root' rechten heeft gekregen kan op een gemiddeld Unix systeem in feite alles doen wat het wil, inclusief het wissen van lokale logfile data. Sommige systeemobjecten kunnen echter alleen worden benaderd door een proces met de rechten van de systeemgebruiker 'root' - bijvoorbeeld de toegang tot een laag poortnummer. Dat is voor bijvoorbeeld webservers (poort 80) of mail transport agents (poort 25) nodig. Dus: de http daemon moet draaien als 'root', tenminste initieel, zelfs als er verder geen enkele andere reden voor is dan het kunnen luisteren op een laag poortnummer.
Maar ook een 'gewone' gebruiker krijgt per default op een Unix systeem vaak veel te veel rechten. Zo kan iemand in zijn HOME directory allerhande bestanden aanmaken en zelf besluiten ze aan andere systeemgebruikers beschikbaar te stellen. Dat klinkt plausibel, maar denkt u eens aan een personeelsfunctionaris, die in zijn directory vertrouwelijke rapportage bijhoudt. Hij kan (zelfs onbewust) zijn bestanden voor derden leesbaar aanbieden en in ieder geval kan 'root' er altijd bij. Dat hij bij zijn eigen bestanden mag, is 1 ding - maar dat hij ook zelf mag bepalen wie er naast hem bij zijn bestanden mogen is niet altijd zijn recht. Als we het over het afdwingen van beveiliging hebben op het niveau wat nodig is om Europese regelgeving in verband met de privacy af te dwingen staat standaard Unix helemaal in zijn hemd. RSBAC beschikt over een module waarmee u deze regels kunt implementeren.