To configure your modules you can use the utilities provided in the RSBAC distribution. By default these utilities can only be executed by a special user - the security officer. By default UID 400 is used for the security officer but you can opt for another UID during RSBAC installation/compilation.
Note that even 'root' needs processes to change its UID to 400 - and on a RSBAC system a process does not have these rights by default, not even the processes that run with UID 0. The only way to become security officer is to log in as such. In practice this is implemented by offering an SSH connection to the security officer and/or by allowing him to log in over the console.
Many people will start wondering now: 'what's the difference? Whether one has a Superuser with UID 0 who can acccess anything or a security officer with UID 400 who can configure access for anything to anybody, including himself?' The difference lies in the amount of effort needed to obtain these rights. The standard Unix kernel contains code that gives the user with UID 0 almost unlimited access to system resources. And any process that needs to run under an alternate UID needs 'root' rights to do so - like the http daemon we mentioned before, which needs root rights to access port 80 before (non mandatorily!) switching to a less dangereous UID. If there exists a security hole in a setuid binary which communicates with the outside world it may be exploited by a cracker to manipulate your system at will. Once he has root rights, he can do whatever he wants. And a firewall will not protect you against that.
On a RSBAC system it is impossible to become the security officer via a hole in a daemon (unless the security officer allowed it, of course). No daemon should ever run setuid 'security officer'. No deamon is allowed to change to that UID, regardless whether or not it has 'root' privileges. Not one user has the right to switch to UID 400. Not even 'root'. On a properly configured RSBAC system the only way to become security officer is by logging in as such using a console or secure encrypted connection. To become security officer on a tightly secured RSBAC system you need physical access to the system. Of course you need to know the password. Nobody - not even root - can become security officer, unless that same security officer allowed it.
You may observe that even on a RSBAC system 'root' might change the security officers password and log in as security officer himself. Yes, that would be a possibility, given of course that 'root' is allowed to change the password and shadow files. You can take additional measures, for example use additional authentication methods. Or can forbid write access to the password- and shadow files except for special programs, that are accesible only to (non-root) system administrators. On some of my own systems it is impossible to access the security officers account, unless you have a special hardware key plugged into the system. And not even 'root' is permitted to change the software that checks for the key. The point here is: you should be careful not to create the illusion of security. A badly configured RSBAC system does not really add much to your security.
On some systems you might even need to resolve to the situation in which the security officer is not allowed to work at all on the system. To alter the configuration on such systems you need to physically reboot and start up a special maintenance kernel to reconfigure the system.
Take good notice of the fact that RSBAC was designed to protect a running system. When you have physical access to a system such a system can not be properly secured unless additional measurements are taken. By simply unplugging the power cord, for example, even your RSBAC protected system will suffer from a denial of service attack (sic). For example, on a laptop, you really should make sure that you take additional provisions to protect your data, for example encrypted filesystems and hardware protection schemes.