submit with /user qualifier

[Anthony Silverman]

We have some privileged users who can submit batch jobs with the /user qualifier.

We would like to know which user submitted the job but the show queue command only shows us the username taken from the /user qualifier.

How can we find out which privileged user submitted the job?

[David Jones_21]

Set audit /enable=privi=cmkrnl/alarm, then
look for the "CMKRNL used to process SJC$_USERNAME item code" events and match the source PID in the accounting file (or live system if they haven't logged out) to get the submiting process.

[Hoff]

There are various ways. Enable and configure the security on the queue via SET SECURITY command; add an alarm or an audit entry onto the queue's ACL. You can catch the PID of the submitter in the alarm or audit, and work from there.

$ set security /class=queue /acl=((alarm=security, access=submit+success)) sys$batch

will get the PID logged, and you can trace from there.

If you're working with cooperating users (as differentiated from a question involving auditing privileged users) (and simply looking for a "who do I talk to"), then you can use the SUBMIT /NOTE from within your local DCL for the submit (most folks have some form of DCL procedure wrappers for this stuff) or the analog available in the $sndjbc itemlist from within executable images.

Having submissions like this and use of DETACH can be quite problematic from the perspective of auditing, too, It can be better to have user-specific entries and usernames or ACLs or such, rather than having some number of folks able to submit to SYSTEM or any user. SUBMIT /USER and DETACH privilege are both very big hammers. Generic accounts are usually bad. And DETACH privilege is a gigantic generic account.

[John Gillings · Accepted solution]

Anthony,

If SUBMIT/USER is the only reason users have CMKRNL privilege, and you don't need too much flexibility in combinations of qualifiers for the SUBMIT, you can write a program to do the submit with $SNDJBC, which could be installed with CMKRNL, thereby allowing you to remove the privilege from the user accounts.

Your program could keep a (protected) audit log of who submitted what on behalf of whom. It could also limit which users can be the target of the submission.

If there's a very limited set of specific jobs and user combinations that need to be submitted, it's even easier. Just can the whole lot into a privileged image and give the users an interface to select jobs from a menu.

Other than that, as David and Hoff have mentioned, you can enable audits which will record these events, BUT since these users have an ALL class privilege, it's feasible they could modify the audit journals to erase the records of events.

It's all a matter of how much they are trusted. Bottom line, if this is a case of users who are not completely trusted, they should not have CMKRNL or IMPERSONATE privilege.

General principle... if you want to control how a privilege is used, you cannot grant it to a user account. You need to write a program to be installed which limits the operations which can be performed.

[Anthony Silverman]

I am going to try the $sndjbc option. It will take more time but it will give me a more complete solution.

I have also just discovered my REAL problem. The submit command has been installed with CMKRNL to allow captive end users to submit jobs under operator usernames. If I write a $sndjbc program I should be able to solve both problems and remove CMRKNL from users and the installed SUBMIT command.

[Jess Goodman]

Or you could do this:

* Copy SUBMIT.EXE to SUBMIT_CMKRNL.EXE
* Set an ACL on SUBMIT_CMKRNL.EXE to restrict access to only the users you trust for this.
* Install SUBMIT_CMKRNL.EXE with CMKRNL priv.

Then the users you gave access to it can do:
$ DEFINE /USER SUBMIT SUBMIT_CMKRNL
$ SUBMIT /USER=...

[Hoff]

I'd probably look to use ACLs first, both on the queue as needed and particularly the addition of identifiers and resource identifiers and ACLs in the context of the target environment.

From an auditing perspective, that approach is usually easier and cleaner as it avoids swapping user contexts. Identifiers and subsystem identifiers and resource identifiers can be very targeted, or can be set up for broad access.