Resolution
NetIQ Security Solutions for iSeries 8.0
fact
VigilEnt Security Agent for iSeries 7.5
fact
Remote Request Management (RRM)
symptom
The rule that passes the DBSQL_EXECIMM operation also seems to be passing other DBSQL_EXECIMM operations, such as DBSQL_EXECIMM_ALTER and DBSQL_EXECIMM_UPDATE.
symptom
Rules for the DBSQL_PRPDESC operation seem to apply to other DBSQL_PRPDESC operations.
symptom
The RRM decision making algorithm is not behaving in accordance with the documentation for the DBSQL_EXECIMM, DBSQL_PREPARE, DBSQL_PRPDESC and DBSQL_PRPEXEC actions.
fix
When you allow the following actions, the RRM decision making algorithm will also approve these actions when they include commands:
DBSQL_EXECIMM
DBSQL_PREPARE
DBSQL_PRPDESC
DBSQL_PRPEXEC
For example, if you have rules created to allow DBSQL_PRPEXEC, DBSQL_PRPDESC, and DBSQL_EXECIMM RRM will also allow DBSQL_PRPEXEC_UPDATE, DBSQL_PRPDESC_INSERT and DBSQL_EXECIMM_UPDATE.
If you do not want to allow the actions when they include commands, you must set up a *FAIL rule for all the transactions that you do not want public to access, such as DBSQL_EXECIMM_UPDATE. You can put all of those transactions in an operation group, such as :NOTPUBLIC. Then you create a user group with the users you want to access the various SQL statements. You can create an operation group with the statement you want them to access and create a rule with those transactions for *PASS.
Since the decision making algorithm looks at more specific rules first (user profile, then operation group, then public) this works. This way you only have to administer the group of users you want to allow access, not the other way around.
Example of how the RRM *PASS/*FAIL determination works:
*PUBLIC :Operation group Userprofile Result
*FAIL *FAIL *PASS *PASS
*FAIL *PASS Not enabled *PASS
*FAIL Not enabled Not enabled *FAIL