Why would a violation show in Warn Mode and not in Fail Mode
Article ID: 100000
Updated On:
Products
Top Secret
Top Secret - LDAP
Issue/Introduction
Sometimes users get violations in Warn mode and actually fail but when in Fail mode they are successful and do not get a violation.
Why would a user get a violation and fail when in Warn Mode?
Why would a user get a violation and fail when in Warn Mode?
Environment
Release: TOPSEC00200-15.0-Top Secret-Security
Component:
Component:
Resolution
There are several times when a violation will show in WARN but not in FAIL. They are not common as most sites don't stay in warn very long and once in Fail don't go back to Warn so these things don't come up often.
Here are reasons why a violation will show in Warn and not Fail:
**The violation message is generated due to the way IBM Catalog search is
performed. There is a two stage security check. The first check is for ALTER
access, which in FAIL mode is not logged because the LOG=NOFAIL bit is set. This is normal and expected in the code. The second check is for READ
access, and is always logged. If the user was in FAIL mode, the check for ALTER access still fails, but is not logged, and is normal. Since the user is in Warn mode he is getting the 08-66 and failing. Put him in Fail mode and and retry the job and it will work.
**The dataset that was being accessed had ACTION(FAIL) on the permit.
If the global mode is WARN, you can force a permit to be treated as if in FAIL mode by putting ACTION(FAIL) on the permit.
**If the security call is made with LOG=NOFAIL would explain why they get the violation in WARN mode but not FAIL mode. Some applications make RACROUTE calls with the LOG=NOFAIL parameter. In WARN mode, these types of calls are written to the Audit File if the check fails, but no message is issued. This procedure is normal, and in FAIL mode, no violation would be recorded.
**Top Secret does not allow a submission under a different acid if the
submitting acid does not have a proper cross-authorization for the submitted
acid, EVEN if the submitting acid is in a mode other than FAIL.
This process is needed to suppress the possibility of an ACID to submit a
job under an authority higher than what it itself possesses.
** TSS/DB2 was developed after TSSMVS was setup in most sites. Rather than force sites to permit users MODE(WARN) to test TSS/DB2, TSS/DB2 was designed to use the mode on the DB2 subsystem facility for calls from
DB2. OPTIONS(40) in the TSS parameter file disables the TSS/DB2 subsystem mode. Setting OPTIONS(40) (and recycling TSS) should cause the security calls from the DB2 subsystems to use the WARN mode permit on the acid.
Here are reasons why a violation will show in Warn and not Fail:
**The violation message is generated due to the way IBM Catalog search is
performed. There is a two stage security check. The first check is for ALTER
access, which in FAIL mode is not logged because the LOG=NOFAIL bit is set. This is normal and expected in the code. The second check is for READ
access, and is always logged. If the user was in FAIL mode, the check for ALTER access still fails, but is not logged, and is normal. Since the user is in Warn mode he is getting the 08-66 and failing. Put him in Fail mode and and retry the job and it will work.
**The dataset that was being accessed had ACTION(FAIL) on the permit.
If the global mode is WARN, you can force a permit to be treated as if in FAIL mode by putting ACTION(FAIL) on the permit.
**If the security call is made with LOG=NOFAIL would explain why they get the violation in WARN mode but not FAIL mode. Some applications make RACROUTE calls with the LOG=NOFAIL parameter. In WARN mode, these types of calls are written to the Audit File if the check fails, but no message is issued. This procedure is normal, and in FAIL mode, no violation would be recorded.
**Top Secret does not allow a submission under a different acid if the
submitting acid does not have a proper cross-authorization for the submitted
acid, EVEN if the submitting acid is in a mode other than FAIL.
This process is needed to suppress the possibility of an ACID to submit a
job under an authority higher than what it itself possesses.
** TSS/DB2 was developed after TSSMVS was setup in most sites. Rather than force sites to permit users MODE(WARN) to test TSS/DB2, TSS/DB2 was designed to use the mode on the DB2 subsystem facility for calls from
DB2. OPTIONS(40) in the TSS parameter file disables the TSS/DB2 subsystem mode. Setting OPTIONS(40) (and recycling TSS) should cause the security calls from the DB2 subsystems to use the WARN mode permit on the acid.
Feedback
Yes
No
Powered by
