Nu draait ons systeem weer - maar hoe nu verder? Welnu, om ons systeem te beveiligen moeten we alle belangrijke objecten beveiligen, bijvoorbeeld programma's, bibliotheken, configuratie bestanden en kernel modules. Daartoe moeten we deze eerst in kaart brengen.
Om het u een richtlijn te geven volgt een overzicht van object-typen die u zou kunnen onderscheiden:
programma's. Bij een inbraak op uw systeem worden vaak vervangers voor vaak gebruikte programma's (bijvoorbeeld ps) geïnstalleerd, soms om de inbraak te maskeren, soms om meer rechten te verwerven als 'root' deze programma's gebruikt;
dynamische bibliotheken (shared objects). Deze moeten om dezelfde redenen als programma's worden beschermd, maar worden op een andere manier geladen en worden daarom als een afzonderlijke klasse beschouwd.
structuur van het filesysteem. Bepaalde delen mogen nooit worden gewijzigd, e.g. de directory /etc/ mag nooit worden verplaatst of gewist;
configuratiebestanden. Toegang tot deze bestanden kan de werking van programma's beïnvloeden.
kernelobjecten. Dingen als kernel-images, kernelmodules, de directe toegang tot het systeemgeheugen, programma's als modprobe en insmod.
directe toegang tot de devices. Bijvoorbeeld toegang tot partities, waardoor een inbreker om de individuele bescherming op bestandsniveau heen zou kunnen werken.
authorisatiebestanden: het mag slechts mogelijk zijn om met een zeer beperkte groep programma's toegang te krijgen tot dit soort data. Het gaat hier om bestanden met wachtwoorden, persoonlijke data van gebruikers en sommige configuratie bestanden. Zeker root mag niet zo maar bij deze bestanden kunnen komen. Voorbeelden zijn /etc/shadow, de niet publieke sleutelbestanden in .ssh etc.
logfiles: een inbraak moet altijd traceerbaar zijn. Daarom moeten logfile bestanden bijvoorbeeld alleen maar aangevuld kunnen worden, nooit (behalve middels speciale extra beveiligde programma's, bijvoorbeeld programma's die een cryptocard of cryptokey gebruiken) gewist of gewijzigd kunnen worden.
overige: in de dagelijkse praktijk kunt u misschien meer soorten/typen onderscheiden.
Na het in kaart brengen van uw systeemobjecten en het indelen ervan in categorieën kunt u ze met behulp van uw favoriete model beschermen. U kunt daarnaast individuele server programma's nog extra beschermen -- een webserver bijvoorbeeld hoeft alleen maar bestanden te kunnen lezen en hoeft ze niet te kunnen schrijven. Dit alles kunnen we bijvoorbeeld afdwingen door gebruik te maken van het RC model.
In het vorige artikel refereerden we al even aan dat RC (Role Compatibility) model. Ik adviseer u om het deel over dit model nog eens op te zoeken en grondig door te lezen - het zal een beter begrip van de rest van dit artikel helpen bevorderen.
Binnen dit voor Linux speciaal ontworpen beveiligingsmodel wijzen we aan subjecten (gebruikersprogramma's) een abstracte "rol" toe. Die rol bepaald wat het subject mag, op welke objecten welk soort toegang toegestaan wordt. Het RC model maakt gebruik van het AUTH model om gecontroleerde UID wisselingen mogelijk te maken. We focussen in dit artikel op deze modellen.