Multi-Tier security Utility

Due to the Unix security model, certain kernel calls can only be used when the process is run by, or with the permissions of, the root user.

One of these function calls was needed for the PingWatchDog protocol (deprecated since UDA Release 4.x). Database security considerations, including the OpSysLogin feature, can also lead to this need. In both case, the Request Broker must be run as root.

This can be accomplished in two ways:

1. The user logs in as root before launching the Request Broker.
   
2. The Request Broker is flagged to run under root privileges, and the user enabled to launch it from any normally privileged account.

The first option requires that all the user(s) who launch the Broker must know the root password, which should not generally be given to ordinary users.

Therefore we have built a solution which enables the second option, without all user(s) needing to know the root password. The system administrator or other user who does know the root password can activate this solution by executing the following commands as root (adjusting the file path as needed for the local installation):

$ cd /opt/openlink/bin
$ ./security -s 

This will have the following effects --

1. The permissions of the oplrqb executable are changed so it takes on the identity of "root" when launched.
   
2. The Broker now knows the filesystem location of the Rulebook file, oplrqb.ini, and will not accept certain startup flags so it cannot be tricked to read in a different Rulebook file at launch.
   
3. The Rulebook file can now only be written to by the "root" account; other accounts will only be able to read this file.

Any time a user tries to launch or terminate the broker, the StartupBy or ShutdownBy value within the [Security] section of the Rulebook is checked to see whether the user is allowed to do so. To have full effect, the default wildcard values for these keywords should be replaced with relevant specific username(s).

As noted above, the Rulebook can now only be written to by the "root" user. This means that ordinary users cannot modify this file, which often seems like an unpleasant side effect. To overcome this, some system administrators are temped to modify the mode of the Rulebook file, reopening security risks. This should be avoided. Instead, the IncludeRuleBook parameter within the [Security] section should be used to divide the Rulebook into parts which others can manage as appropriate. The system administrator can split up the Rulebook into different files which than can be included from the master Rulebook. This makes specific sections available to normal users, but allows the system administrator to decide which sections can (or cannot!) be overruled by normal users. The included Rulebooks cannot overrule any section within the master Rulebook. This is a very powerful way of dealing with high security installations within large companies.