Auditing/reporting usage of DCL procedures

[jeremybegg]

Hi,

We have added the following ACE to many .EXE files and .COM files to see what is being run:

Code: Select all

          (AUDIT=SECURITY,ACCESS=EXECUTE+SUCCESS)

and the security audit server is set up to log security auditing events triggered by that ACE.

Analysing the audit log we see our .EXE files being reported in the logs in various fields.
However the reporting of .COM files seems to be less reliable: some are logged, and some are not, even though we know they are being run (e.g. as regular batch jobs).

I'm guessing that the above ACE triggers an audit event when the image activator loads an image.

But what causes the equivalent event for a .COM file? Or to put it another way, how could a .COM file be run without creating an audit record?

Thanks
Jeremy Begg

[dgordon]

Can you be a little more specific about the circumstances under which the alarms get generated for command procedures and for which cases they don't? I note you mentioned batch jobs.

The image activator is not involved with command procedures.

I'm willing to take a look, but need to narrow down what you're seeing.

--Doug

[jeremybegg]

Hi Doug,

I thought I had replied to this, but it's not showing up, so here's attempt 2.

This cluster does most of its processing in batch jobs and network services but there are some interactive users as well.

I have asked the application developers to investigate how the .COM files are being run, and if they can correlate the activation method to the (non-)appearance of the files in the audit logs.

I'll post again when I have some answers.

Thanks,
Jeremy Begg

[jonesd]

Hi,

We have added the following ACE to many .EXE files and .COM files to see what is being run:

Code: Select all

          (AUDIT=SECURITY,ACCESS=EXECUTE+SUCCESS)

and the security audit server is set up to log security auditing events triggered by that ACE.

Analysing the audit log we see our .EXE files being reported in the logs in various fields.
However the reporting of .COM files seems to be less reliable: some are logged, and some are not, even though we know they are being run (e.g. as regular batch jobs).

I'm guessing that the above ACE triggers an audit event when the image activator loads an image.

I thought the alarms were triggered by the XQP based upon the FIB$V_EXECUTE flag being set the FIB's FIB$L_ACCTL field.
The docs say FIB$V_EXECUTE is supported in supervisor mode, so theoretically DCL could set that flag when it opens a command procedure. If it doesn't and they changed it now, it could surpise a lot of people when ,com files with read access but not execute protection stopped working.

[sodjan]

What about just marking sure that all COM files start with running an "audit" EXE to log the activation of that COM file?
The EXE do not have to "do" anything apart from being started and then exit.

[cct]

We had a logging routne that was simply called at te start of every DCL routine. All run from captive accounts (menu driven) so we logged all.

Also had the same under Unix for shell scripts

Chris

[jeremybegg]

Hi all, I have an update on my situation.

First of all, thank you for the suggestions to add logging to the DCL procedures, in some form or another. For the purposes of this exercise it will not be possible to modify the procedures. (There are several hundred.)

I have spent some time running tests on my rx2660 server running VSI OpenVMS V8.4-2L3 with interesting results.

If the DCL procedure has the ACE (AUDIT_JOURNAL=SECURITY, ACCESS=READ+EXECUTE+SUCCESS), I see the following behaviour:

• if the procedure is submitted as a batch job, e.g. $ SUBMIT X.COM, the audit log records entries for images SUBMIT.EXE and LOGINOUT.EXE, both referring to the command procedure.

• if the procedure is invoked using @X.COM the audit log records one entry for the procedure, with no image name.
  This is as expected.

Things go strange if the procedure has the ACE (AUDIT_JOURNAL=SECURITY, ACCESS=EXECUTE+SUCCESS):

• if the procedure is submitted as a batch job, NO audit log entry is generated

• if the procedure is invoked using @X.COM, one entry is generated. If the procedure invokes another procedure, TWO entries are generated (both referring to X.COM).

This is not the behaviour I would expect - especially the generation of two audit log records if the procedure invokes another procedure.

Thanks,
Jeremy Begg

[dgordon]

Things go strange if the procedure has the ACE (AUDIT_JOURNAL=SECURITY, ACCESS=EXECUTE+SUCCESS):

if the procedure is submitted as a batch job, NO audit log entry is generated

if the procedure is invoked using @X.COM, one entry is generated. If the procedure invokes another procedure, TWO entries are generated (both referring to X.COM).

This is not the behaviour I would expect - especially the generation of two audit log records if the procedure invokes another procedure.

This doesn't seem correct to me either. If you have a support contract, please open a formal problem report.

--Doug