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

[Joe]

On Wednesday, November 9, 2016 at 3:50:27 PM UTC+1, Stephen Hoffman wrote:
> 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

Thanks Hoff,
  At this site, most of the application components are running under the user names similar to this ADP$MGR, IPS$MGR, WSI$MGR etc... We have already changed many of then but still quite a few are there.