Configuratie van modules wordt gedaan middels (meegeleverde) utilities. Deze mogen normaliter alleen maar gebruikt worden door de security officer, een speciale gebruiker, die per default UID 400 heeft (instelbaar tijdens compilatie van RSBAC).
Merk op dat uiteraard ook root gebruik moet maken van processen om te kunnen wisselen naar UID 400 - en op een RSBAC systeem hebben de processen die rechten per default niet. De enige manier op een standaard RSBAC systeem om security officer te kunnen worden is door als dusdanig aan te loggen. In de praktijk wordt daarvoor vaak alleen een SSH koppeling en/of een console login toegestaan.
Een veelgestelde vraag is "maar wat is dan het verschil? Of je nou root met UID 0 hebt die overal bij kan of een security officer met UID 400 die zichzelf en anderen kan machtigen om overal bij te kunnen komen?". Het verschil zit er in hoe moeilijk het u wordt gemaakt om deze rechten te verkrijgen. Binnen een standaard Unix kernel is hardgecodeerd dat 'root' vrijwel onbeperkt rechten heeft. Daarbij komt dat elk proces dat van UID wil wisselen initieel als 'root' moet draaien. Bijvoorbeeld de eerder genoemde http daemon, die eerst 'root' moet zijn om op poort 80 te kunnen koppelen en dan pas om kon schakelen naar zijn eigenlijke (minder gevaarlijke) identiteit. Legio potientiele mogelijkheden voor crackers dus om via een manke daemon met een of ander exploit daarin 'root' te worden - en dan vervolgens te doen wat men wil.
Op een RSBAC systeem daarentegen is het onmogelijk om security officer te worden via een daemon, als de security officer dat niet zelf heeft toegestaan. Geen enkele daemon heeft het recht om security officer te worden. Geen enkele andere gebruiker heeft dit recht, ook 'root' niet. U moet fysiek aanloggen, via een console, om security officer te worden op een RSBAC systeem. Dan moet u dus fysiek bij het systeem kunnen, en uiteraard het wachtwoord kennen. Niemand - ook 'root' niet - kan het ID van de security officer aannemen, tenzij deze zelf daarvoor toestemming heeft gegeven.
Het is uiteraard mogelijk om het aanloggen van de security officer aan extra beperkingen te binden: op mijn eigen systemen is het bijvoorbeeld onmogelijk om zelfs lokaal als security officer aan te loggen als u niet tevens een speciale hardware key hebt. Er zijn ook installaties waarbij u fysiek moet rebooten in een zogenaamde 'maintenance kernel' (hierover meer in het volgende artikel) voor u de security settings kunt wijzigen.
Merk op dat RSBAC bedoeld is voor het beschermen van een draaiend systeem. Als je fysieke toegang tot een RSBAC systeem hebt, kun je zo'n machine uitzetten en bijvoorbeeld een niet RSBAC kernel booten of de harde schijf onderzoeken door haar in een andere machine te stoppen. Daar kan ook RSBAC u niet tegen beschermen. Ik zet daarom zelf een combinatie van encryptie en RSBAC in om mijn vertrouwelijke data te beschermen.