Account for login and read privilege

[Feige]

Because the system account is very dangerous for average operator, so I want to create a account just ownes login,read, can't write,delete and modify files, which privilege is necessary? NETMBX,OPER, is ok? Thanks!

[Hein van den Heuvel]

For my work I tend not to be too converned with privs, so this is not going to be the best answer for you, just a start.

Be sure to carefully check Table 2 "OpenVMS Privileges" in the OpenVMS security manual.

http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/aa-q2hlg-te.HTMl

Pay close attention to the 'categories' :
normal, group, devour, system, objects, all.

Seems to me you want to avoid 'all' but may tolerate as much as 'objects'.

I kinda like 'readall', I hate 'bypass'.
I do NOT want BYPASS in any default priv mask. SYSPRV is almost as dangerous, but useful. Be careful with the UIC group you assign for the average accounts.
Pick it ABOVE the SYSGEN value for MAXSYSGROUP, to prevent exessive object privs.

Read a lot, go carefully!

Good luck!

Hein.

[Robert Gezelter]

Feige,

I concur with Hein. A careful read of the Guide to System Security is in order.

However, some notes, many of which appeared in my presentation "OpenVMS User Environments" (notes at http://www.rlgsc.com/hpworld/2004/N227.html ), where I discussed managing large environments without corresponding numbers of privileged users.

In particular, one wants to look at using the ownership of different queues and devices to allow otherwise non-privileged users to do operator level tasks. Just because a user/operator is authorized to reset the print queue for finance does not mean that they should automatically have the authorization to work with another group's printer.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

And if the operations staff has specific and more privileged tasks that need be performed in response to various stimuli, consider setting up a DCL menu and a CAPTIVE environment, and generally keeping an operator away from the $ prompt when the ALL-class privileges are lit.

There can and will be exceptional cases, when DCL access is required, and with full privilege bits lit. But the run-of-the-mill stuff is where the usual "oops" problems creep in.

And yes, do check the manuals and do check your tasks for which privileges are required.

I had included examples and information on CAPTIVE and security-related tasks in the 2nd Ed. of the Writing Real Programs in DCL book, if you can find a copy of it. The book is reportedly out of print.

Stephen Hoffman
HoffmanLabs LLC

[DECxchange]

Hello,
You probably want to setup some kind of menu system and provide the operators with specific commands or programs they can execute by picking a menu choice. If you need to provide them with DCL command line access, you can modify their DCL tables to eliminate such commands as DELETE, OPEN, COPY, EDIT, etc. That would leave them with TYPE, SHOW, etc. There are a lot of DCL commands, so you might want to look at the DCL Commands Reference and determine which commands you want them to be able to use.

You can also set file owerships and file protections to allow particular operators access to certain files. E.g., $ set file/prot=(w:r) and set file/own=. This would require setting up the file ownerships in the AUTHORIZE utility.

So there are a number of options including making the account CAPTIVE, disabling CTRL-C and CTRL-Y so they can't break out of the menu system and so forth.

You might want to come up with a set of requirements so you can determine what approach to take and what all you want certain operators to be able to do and be responsible for. You might have to hire somebody who can do all of this type of work for you if you can't do it or don't have anybody on your staff that can do it.

[Hakan Zanderau ( Anders]

Let's look at your problem from another angle.

An Operator is still an operator, not a user.

Wouldn't it be better to trust the operators and send them to OpenVMS training instead of putting effort and $$ on restricting their accounts ?

[Robert Gezelter]

Feige,

Captive menus are a good solution to operators having accidents, but they are not an answer to security issues. Protection via the RWED or ACL mechanisms is.

The problem is that it is a challenge to correctly implement a menu system that does the equivalent of what the security mechanisms do without having any loopholes.

A good philosophy is: Menus for usability; Protection for security and control.

- Bob Gezelter, http://www.rlgsc.com

[Willem Grooters]

ONE of the possibilities is to create a non-system UIC-group "operator", and add an account for each operator. The default privs for these users should be TMPMBX,NETMBX,READALL, add OPEN and VOLPRO (if needed) as authorized privs. Do NO give them BYPASS privilege - it would allow them to do all you want to prevent. They would then be able to read every file on the system.
If this is not wanted, define an identifier like "operread", put an ACL with this identifier on each file that needs to be accessed by this group, and give ir READ access - READ+EXECUTE of directories - and no more. Grant this identifier to each member of this group and you can omit READALL privilege. It gives you more control on what files can be acessed: If a file lacks this ACL, access is blocked (assuming you left out UIC-based access W:R)

As an extra, creating a captive account for these users would limit them to just that what they are allowed to do and nothing else.

In a previous life, I've seen a method using a CLI-table (derived from DCLTABLES.EXE but very much limited) that was sepcified as CLI in UAF for limietd users. Commands like COPY, DELETE, PURGE and such were removed. All they could do from the command line was looking for, and viewing files, and run a few programs.