1748104 Members
4593 Online
108758 Solutions
New Discussion юеВ

Re: Custom DCL tables

 
Thomas Ritter
Respected Contributor

Custom DCL tables

Some support staff must be provided with DCL access. The primary reason is to examine log files. Creating a CAPTIVE account with a MENU is not palatable and has meet resistance :(

At my last site we introduced customized DCL tables. Basically we took copies of the existing dcl table and removed or modified verbs. "Monitor" was removed and "show" was modified, just to name two examples.
We also want to restrict information about the workings of the system, memory, cpu and I/O and all ability to view batch processing.

What are your views ?

5 REPLIES 5
Karl Rohwedder
Honored Contributor

Re: Custom DCL tables

At the end, it depends on wether you can trust your staff or not.
It may become very difficult to secure such an account (remove the SET COMMAND 1st, or the rest is worthless) and not to forget something.
If the staff needs privileges I would be VERY carefull.

regards Kalle
Robert Gezelter
Honored Contributor

Re: Custom DCL tables

Thomas,

Removing verbs from the command tables is only half of the problem (For example, removing the SHOW QUEUE commands DOES NOT do anything about the lexical functions that can produce the equivalent display). Also, removing the commands does not eliminate the ways to invoke the images.

The better approach to this involves ACLs and identifiers. Put ACLs preventing access to the images involved and related information (e.g., the batch queues).

Done properly, this is highly effective at limiting access.

- Bob Gezelter, http://www.rlgsc.com
John Gillings
Honored Contributor

Re: Custom DCL tables

In general, this is not a good idea.

First of all, anyone with moderate DCL skills can reactivate any command they like using SET COMMAND and the appropriate CLD. This becomes especially easy in V7.2 or higher as the CLD files for all of DCL live in SYS$UPDATE with W:RE access. It may as simple as

$ SET COMMAND/TABLE=DCLTABLES

and you're back to the system default.

Even if you manage to remove SET COMMAND (not that easy!) all you really do is make things a bit harder. A good DCL hacker will still be able to get past you.

If users have any means for copying files onto your target system, that makes things easier (prepare whatever you like on your home OpenVMS hobby system...)

Second issue is maintenance. Potentially any time you upgrade OpenVMS or even install a patch, you will need to at least review your customised table to make sure you won't get ENTNF errors (ie: new images are now expecting parameters or qualifiers to be in the command tables). You have to make sure you have a script to generate your modified table from the standard one, because you're likely to be doing it fairly frequently.

As Bob has pointed out, you can't remove lexical functions which return the information you want to hide. Even if there aren't any lexical functions to read whatever you want to protect, many system data structures are UR (user read), and at fairly easily determinable locations.

For example, on an V8.2 system, the following DCL will give a reasonable approximation to SHOW MEMORY/PHYSICAL. No privilege required:

$ p=F$CVUI(0,32,F$FAO("!AD",4,%x8180A6E0))
$ m=F$CVUI(0,32,F$FAO("!AD",4,%x81808084))
$ f=F$CVUI(0,32,F$FAO("!AD",4,%x81808080))
$ u=p-f
$ WRITE SYS$OUTPUT "''p' ''f' ''u' ''m'"

Even easier to anyone with access to a compiler.

As they say, security by obscurity isn't security. Please don't give yourself a false sense of security, on top of giving yourself a maintenance burden.

Some of the things you may want to hide may be controlled with ACLs and/or changes to default security templates. Please log a case with your local customer support centre for more details.
A crucible of informative mistakes
John Abbott_2
Esteemed Contributor

Re: Custom DCL tables

We ended up creating a command file to mimic a cut down version of DCL. The users could not escape the DCL routine, nor could they spawm. In conjunction with vms priv and file security protection this allows us to give a restrictive access. For example many $ SHOW commands work but the /SYMBOL qualifer doesn't, nor can they set up symbols or logicals. Any dcl routines that are '@'d are actually open/read and each command is executed - this limits what dcl can be used to what is allowable at the restricted command prompt. We do not allow any lexicals and prevent $ SET DEFAULT to anywhere outside of their sys$login and below (including checking for logicals and symbols). EDIT, TYPE (of a real file, again not symbols or logical translations allowed) $ DIR $ COPY $ DELETE/RENAME/PURGE (file) were sufficient to allow them to do their work. We were lucky that only a limited number of commands were needed.

For the TPU editor we created a section file which restrict them too. (no spawn, reading or writing files outside of their sys$login [...])

J.
Don't do what Donny Dont does
Jess Goodman
Esteemed Contributor

Re: Custom DCL tables

We use a modified version of DCLTABLES for some or our clients that need command line access to our systems. We feel that this approach gives us an added layer of security.

It is, or couse, not enough for us to just remove the verbs that they don't need at all (examples: ACCOUNTING,LINK,MONITOR). We must also edit the definions of some verbs to remove specific verb syntaxes we don't want them to use.

For example we remove syntaxes SET_COMMAND (obviously) and SET_DEVICE from SET.CLD but keep SET_DEFAULT and SET_PROCESS. Note that since SET_DEVICE and SET_PROCESS both invoke SET.EXE there is no way to restrict access to only one of them using ACLs.

The downside of this is that we must manually re-edit these .CLD files when we upgrade VMS and occasionally when a VMS patch updates one of our modified verb definitions.

I have one, but it's personal.