[Info-vax] Restrict the use of SUBMIT/USER= to one particular user.

[Stephen Hoffman]

On 2016-11-07 09:52:45 +0000, Joe said:

> We have a set of application users who submit some application batches 
> on a specific user with the command SUBMIT/USER=APP$MGR. To perform 
> this, the application users are provided with CMKRNL privilege. I 
> notice at times some users use this privilege and submit some jobs 
> under SYSTEM user. What would be the best way to restrict this?I'm 
> thinking of a captive menu to get all the required details and validate 
> the user part and then submit in the background, is this a good idea?Do 
> we have any other option to restrict this easily?

OpenVMS is just hilariously bad at this sort of stuff.   There is no 
documentation for this task, and damned little support for this and 
related tasks in the provided APIs, there are no process- and 
job-related scheduling tools (queues stink at this), and multiple 
decades of various folks creating their own tools to deal with this 
task.   With at least some of those tools likely vulnerable to attacks, 
too.   (When auditing a system, always investigate site-local installed 
images and site-local server processes running with privileges, as 
they're quite often vulnerable to attack.   These tools are a great 
spot to audit, as most folks are in a hurry to solve these issues, and 
the resulting source code can be less-than-hardened against unexpected 
input or output.)

Okay, so changing your username can sometimes break some things, 
particularly on the fly.   it just doesn't work very well.    Auditors 
tend to have issues with shared usernames too, due to the issues around 
accountability; around the lack of accountability.   Best not to give 
users a way to change users and to be exceedingly paranoid about what 
data is shared across usernames, as more than a few applications and 
parsers tend to have security bugs in these areas.    Redirecting a log 
file or other such input or output can play havoc with a system, if the 
user can control where the privileged application writes that data or 
where the application reads data from, for instance.   But there are 
tools to change usernames, and the persona system services can be used 
here to avoid some of the problems that older username-changing tools 
tended to have had.

If you really need to change usernames, then there are ways...

What you're doing is one approach; SUBMIT /USER_NAME.   Usual approach 
is either an add-on submission tool — somebody in this thread has 
already commented on one in this thread, and Cerebrus is one package 
that's been posted to the OpenVMS Freeware — or to use a captive login 
with the necessary privileges, or to send a notification to a trusted 
server process — DCL or interpreted or compiled tools all work here — 
to start the server task under the target username, or work to avoid 
needing the user to even start the application under the specified 
username.  Among other approaches.   ssh, for instance, can use 
certificates and can trigger operations on remote hosts on request, and 
avoids exposing parts of your infrastructure communications as happens 
with DECnet or TCP.   Depending on exactly what the task involves, 
sometimes a user-written system service UWSS or a device driver and ACP 
is appropriate, too.

In general, I prefer to send a nudge to a server process to start the 
task, or to have the server task start itself on demand, or to have the 
server poll.   Starting the task can use a captive login, or a mailbox 
message, or a network connection to the server, and I know some OpenVMS 
folks that swear by the use of the Freeware DELIVER tool or the 
execsymb tool.

When looking at the more general problem of access, use of identifiers 
— on the queue in general, or on the queue and then via execsymb or 
otherwise — and on files and directories and mailboxes and such, and 
the use of subsystem identifiers, can variously entirely avoid needing 
to assign privileges and change usernames, too.

I'm not aware of any OpenVMS documentation that particularly covers 
this or related tasks, nor that documents the options and alternatives 
and considerations involved with writing a secure server process, 
either.

Topics related to this at HL:
http://labs.hoffmanlabs.com/node/491
http://labs.hoffmanlabs.com/node/1524
http://labs.hoffmanlabs.com/node/652
http://labs.hoffmanlabs.com/node/502
http://labs.hoffmanlabs.com/node/712
http://labs.hoffmanlabs.com/node/250
http://labs.hoffmanlabs.com/node/78
http://labs.hoffmanlabs.com/node/797 & http://labs.hoffmanlabs.com/node/916
http://labs.hoffmanlabs.com/node/1349  (Some of the official doc looks wrong)

ps: the dollar character is reserved to HPE, VSI and registered 
third-party products and packages.   Unless you've registered APP$ with 
VSI, it's best to avoid using that.   (OpenVMS lacks mechanisms to 
identify and secure and protect and isolate via certificates and GUIDs 
and related mechanisms to support application bundles/containers/jails, 
and thus depends entirely on everybody cooperating with this and other 
guidelines.)

-- 
Pure Personal Opinion | HoffmanLabs LLC