Track changes to Audit file
Article ID: 268105
Updated On:
Products
Issue/Introduction
We use auditing on all systems. We pull the audit file entries in real time using syslogd in vmoper. That works great. We also have a routine that checks to make sure syslogd is running (via qpcb) and restarts it in the event we choked somewhere.
A couple questions recently came up:
1. Does VM:Secure monitor for changes to the Audit File?
2. Does it monitor that the auditing is actual working? Can someone turn it off, and if so, is there an alert?
Environment
Release : 3.2
Resolution
VM:Secure auditing is "turned on" by including ACCESS AUDIT record in the PRODUCT CONFIG file, for example:
ACCESS AUDT 1D0 T
When the ACCESS AUDIT record is processed AUDITING is initiated. Thereafter, virtually every VM:Secure request independently issue AUDITLOG WRITE commands to audit activity.
If the AUDIT disk fills up, VMSECURE will issue nag messages (VMXSYS0481W The VM:Secure AUDT database disk is 99% full.) and begin accumulating the audit records in PUNCH so they are not lost. When AUDITEXT is run it will process the AUDIT disk and any "OVERFLOW" in PUNCH if that has occurred.
Otherwise, if VMSECURE loses access to the AUDIT disk message 1275E "There is no AUDIT disk accessed" for every attempt to AUDIT.
If there is some other error that is not "disk full" then message 1120S will be issued.
Again, you would receive these error messages for almost every VM:Secure command or request, anyone logging on, linking to disks, etc.
Perhaps you could key on the VM:Secure message numbers to do something if you are not already tracking those.
Additional Information
You can also put VM:Secure Rules in place to REJECT a R/W link to the Audit disk and and to override anything allowed via SYSTEM or other RULEs, use the POSTRULE exit.
Also noting that VM:Secure will complain if someone has the AUDIT and/or other VM:Secure MIDISKs accessed for more than one minute and issues the VMXSYS0483W warning message to the user who has the link and also records this on the VMSECURE console:
<<< snip >>>
vmlink vmsecure 1b0
DMSVML2060I VMSECURE 1B0 linked as 0120 file mode X
Ready; T=0.01/0.01 12:50:30
12:50:36 * WNG FROM VMSECURE: VMXSYS0483W Warning! You have linked VM:Secure
DRCT disk R/O as 0120.
det 120
DASD 0120 DETACHED
Ready; T=0.01/0.01 12:50:38
vmlink vmsecure 1d0
DMSVML2060I VMSECURE 1D0 linked as 0120 file mode X
Ready; T=0.01/0.01 12:50:47
12:51:36 * WNG FROM VMSECURE: VMXSYS0483W Warning! You have linked VM:Secure
AUDT disk R/O as 0120.
<<< snip >>>
However, this is not really a reliable way to know for sure that someone linked to the AUDIT (1D0) MDISK because it relies on the LINK being active at the particular interval that the VMSECURE SYSTEM process checks. Of course these links are always recorded in the AUDIT file.
The POSTRULE User Exit looks like it can be used to either override anything allowed via SYSTEM or other RULEs. You could also add special code to do definitive things like send a message or email, force the user off, whatever. The only drawback to the POSTRULE User Exit is that it must be coded in assembler and the reasons for that are included in its documentation, but basically for performance.
Feedback
