Submit

[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