- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Custom DCL tables
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-12-2006 05:33 PM
тАО07-12-2006 05:33 PM
Custom DCL tables
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-12-2006 06:07 PM
тАО07-12-2006 06:07 PM
Re: Custom DCL tables
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-12-2006 06:43 PM
тАО07-12-2006 06:43 PM
Re: Custom DCL tables
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2006 06:12 PM
тАО07-13-2006 06:12 PM
Re: Custom DCL tables
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-13-2006 09:10 PM
тАО07-13-2006 09:10 PM
Re: Custom DCL tables
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-14-2006 07:08 AM
тАО07-14-2006 07:08 AM
Re: Custom DCL tables
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.