Endpoint Administration Guide for UNIX › Managing Policy Models › Automatic Rule-based Policy Updates › Dual Control

Dual Control

Dual Control is a way of operation that divides the process of updating the PMDB into two stages:

• Creating a transaction which consists of one or more commands.

  The maker - any user with the ADMIN attribute - enters one or more commands that update the PMDB. The transaction is given a unique ID number and placed in a file, where it waits to be processed before execution.

• Authorizing the transaction for execution.

  The checker - not the same user, but any other user with the ADMIN attribute - locks the commands in the transaction, checks the commands, and authorizes or rejects them. If the transaction is authorized, then the commands are executed in the PMDB. If the transaction is rejected, then the transaction is deleted and the PMDB is not updated. The checker cannot authorize some of the commands in a transaction and reject others; the transaction must be processed as a whole.

  Note: Only the find and show commands do not need the authorization of a checker.

Using the parameters in the sepmd utility, makers can list, retrieve and edit, or delete unprocessed transactions; checkers can lock transactions in order to authorize or reject them, and they can unlock transactions for processing at a later time or by a different checker.

When the sepmdd daemon receives the start_transaction command, it sends the child process a unique number. The child process tags any further commands with this identifying number, and the number is added to the new transaction and kept in the memory of the sepmdd daemon. When sepmdd receives the end_transaction command, the authorization algorithm is invoked. The authorization algorithm checks that none of the commands in the transaction pertain to the maker of the transaction, and none of the objects in the commands are already locked by another transaction that is waiting to be processed prior to execution.

You cannot use the same objects in different transactions before they are processed. If the check passes, then the relevant objects are locked, the transaction is assigned a unique sequential number, and the data is saved in a file. Each transaction is saved in a different file.

Note: For more information about the sepmd utility or the sepmdd daemon, see the Reference Guide.