Submit

[Mulder_1]

I'm having a problem while submitting a job in batch with /user qualifier.

The user who is submits the job is holding the following privileges :

Authorized Privileges:
CMKRNL GRPNAM NETMBX OPER TMPMBX
Default Privileges:
CMEXEC CMKRNL GRPNAM NETMBX OPER TMPMBX

Whenever I submit the job I receive the following error :
%SUBMIT-F-INVQUAVAL, value 'APB123' invalid for /USER qualifier
-RMS-E-PRV, insufficient privilege or file protection violation

What privilege do I need to set so that the job can be submitted ?

[Jan van den Ende]

Fox,

you (also) need to be able to READ the autorisation file.

SYSPRV is one way to achieve that.

Proost.

Have one on me.

jpe

[Mulder_1]

Thanks for your reply...

But,the user is an operator,SYSPRIV would not get approved.

Any other way ?

Thanks

[labadie_1]

Help submit/user

Requires CMKRNL (change mode to kernel) privilege and read (R)
and write (W) access to the user authorization file (UAF).

If you can do a submit/user=privileged_user, then why not submit a .com file doing
$ mc authorize copy system xxx/pass=yyy

Doing this is the same as giving full privileges.

[Joseph Huber_1]

"SYSPRV" would not be approved"

But if a user has CMEXEC CMKRNL, then he can always get SYSPRV with a little programming.
So what kind of security policy is this ? Ignorant ?

[Jan van den Ende · Accepted solution]

Fox,

well, _SYSPRV_ would not be approved for users that have _CMKRNL_ ??
That is like a bow-and-arrow are considered too dangerous for someone who usually only carries an AK47....

But, since you are su=tuck with this, you could also set an ACL on SYSUAF that grants READ access to the operator(s).

hth

Proost.

Have one on me.

jpe

[Robert Gezelter]

FOX2,

Note: As Labadie has noted, the HELP text indicates that Read AND Write Access are needed to the UAF.

The policy that operators do not have SYSPRV is all well and good, BUT giving them Write access to the UAF is "SYSPRV in one extra step" (A reference to chess terminology is appropriate: "Mate in one").

There are several better options for implementing this:

- set up a captive account that can be logged in and submit the job.
- use a daemon process/batch job that executes on a regular basis and checks for the presence of a work request in a file.
- (more complex) create an image that only is able to submit that task, and install that image with CMKRNL. Protect that image with an ACL, and have it automatically log its use to the audit and accounting files.

- Bob Gezelter, http://www.rlgsc.com

[Joseph Huber_1]

Another possibility, which enables You also to remove the CMKRNL privilege from operator account:

SUBMIT/HOLD the job from a privileged account once.
Insert a resubmit itself as the first action of the job.
Then let the operator SET ENTRY/RELEASE the job when needed. (set the necessary protection on the job or queue, by default OPERATOR privilege allows it.)

If the operator is not skilled enough to find the entry number, put the /release command into another command-file, which searches for the particular job/entry number first.

[Hein van den Heuvel]

Run this program just before the submit:

int sys$setprv(), sys$cmexec();
main(int argc, char *argv[]) {
__int64 privs = 1 << 28;
int args[] = { 4, 1, (int) &privs , 1, 0 };
return sys$cmexec (&sys$setprv, args);
}


No C compiler on the production box?

$create tmp.mar
.entry start, 0
callg args1, g^sys$cmexec
ret
.psect data,noexe
args1: .long 2, sys$setprv, args2
args2: .long 4, 1, privs, 1, 0
privs: .long 1@28, 0
.end start
$macro tmp
$link tmp
$run tmp
$delete tmp.*;

Best regards,
Hein.

[Joseph Huber_1]

... continuing suggestions,
if You need more than a few specific privileged jobs to be executed from a less privileged operator, You could setup a privileged "worker" job, doing:

1.create a system-/cluster-wide mailbox, where it receives commands from operators/users.

2.loop on reading commands from the mailbox.

3. verify/dispatch/execute the actions requested in the message.

Since mailboxes allow to get also the sender identification, all kind of protection can be established here.

(3a. notify the sender about success/error)

4. loop at 2.

(Almost) all this can be programmed in DCL.

[Joseph Huber_1]

Hein's program shows why CMKRNL+"a little bit of programming" puts all CM* privileged users in the SYSUAF "ALL" category.

[Robert Gezelter]

FOX2,

I thought that I had gotten the confirmation notice on my last post, but it appears not to have actually posted. Strange.

I must disagree with the proposal to use CMKRNL to grant the process SYSPRV. As is demonstrated, CMKRNL gives one SYSPRV in one move (Chess reference: "Mate in one"). WADR, sneaking an enabling of SYSPRV could have serious repercussions if (more accurately, when) it is discovered during an audit or other security review.

The better path is to review why the operator account was granted CMKRNL and CMEXEC, and resolve that issue, then removing both of those DEVOUR-class privileges from the operator account. One of the solutions I commented on earlier, or the one Joseph Huber mentioned in his post address the problem.

A thorough reading of the "OpenVMS Guide to System Security", particularly the sections relating to privileges, is highly recommended. The manual is available from the OpenVMS www site in HTML at http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/aa-q2hlg-te.HTMl or in PDF at http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/aa-q2hlg-te.PDF .

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

FOX2,

As others have pointed out, CMKRNL gives easy access to all privileges (which should be blindlingly obvious as it allows SUBMIT/USER of an arbirtary user, including SYSTEM, so they user effectively IS SYSTEM)

If the set of SUBMIT/USER commands this user needs to issue is relatively small, write a program which hard codes all possible variants as calls to $SNDJBC. The program can be installed with CMKRNL and SYSPRV, protected to only be executable by authorized persons. Use a menu or similar mechanism to restrict what the user can do with the privileged program. You can then remove CMKRNL from the privileges of this (obviously untrusted!) user.

If your auditors are worried about SYSPRV, but aren't already unhappy about CMKRNL, you should get yourself some auditors who have a clue.

[Hoff]

Set all the passwords to blank and issue full privileges to everybody. That's at least being intellectually honest about the security and operational problems that clearly exist with this server.

[Jess Goodman]

I think many of you are being too tough on the OP's security policy. His system operators are probably fully trusted not to DELIBERATELY attack the system. For these type of users CMKRNL is safe since they can will not use it give themselves full privs.

However with SYSPRV or BYPASS priv. these users might ACCIDENTALLY delete critical files due to lack of (pick one) training,
experience, typing skills, brains...

I am the system administrator but I do not give even myself BYPASS as a default priv. (I can of course enable it if I wish). I have a few critical files set to no delete access from S,O,G,W just so a mistyped wildcard delete won't get them. If I really want to delete them it takes me an extra step. Most files have S:D access so SYSPRV let's me delete them in one step.

[Jess Goodman]

Fox2,

I just realized that no one mentioned READALL privilge. If your operators can be trusted with it then they will be able to SUBMIT jobs using /USER= (along with CMKRNL that they already have).

If they can't be trusted with READALL priv. then I would say they can't be trusted with CMKRNL priv either. You can't accidentally or even deliberately destroy anything with READALL. And if they can't be trusted not to look at stuff they're not supposed to look at, then they can't be trusted not to deliberately attack the system either.

[Paul Jerrom]

Before we go giving everyone in the world full access to this server, can we see the submit command please?

PJ