Rasising Security Level within a DCL Scripts

[HarrinG]

I have a DCL that will allow a selected set of users to reset passwords, but I do not want those users to have the rights to actually run authorize. Is there a way within the DCL to allow access to authorize then remove it when the DCL is completed?

[Craig A Berry]

The following sequence is what I do to temporarily *downgrade* privs to only the ones I need for a particular operation and then restore them to what they were after I'm done. You could do something similar to temporarily elevate privs (assuming the user has SETPRV), but be sure you are trapping interrupts and there are no unhandled errors that could drop people out to the command prompt in an elevated privilege state, and be sure you have no other reason to disallow SETPRV. In other words, this procedure only makes sense as a way to automate what a privileged user should already be doing manually.

$ oldpriv = F$SetPrv("NOALL") ! downgrade privs for safety
$ discard = F$SetPrv("NETMBX,TMPMBX") ! only need these

. . . do stuff


$ If f$type(oldpriv) .nes. "" Then discard = F$SetPrv(oldpriv)

[John Gillings]

HarrinG,

There are ways to do this (ie: turn privileges on or off) in DCL using installed images, but typically they open some fairly serious security holes in the system itself.

You can do precisely what you want with a program which calls $SETUAI to reset the password of a given username. Install it with SYSPRV privilege and protect it with an ACL which grants EXECUTE access only to holders of a specific identifier. The code should also have an exclusion list of some type to prevent the user from changing passwords for critical accounts (eg: SYSTEM). A more generic mechanism might be to take the target username, use $GETUAI to check the privileges of the username and refuse to change the password of anyone with more privileges than the user.

[Jan van den Ende]

HarrinG,

To start with:

WELCOME to the VMS Forum!

What we have for this (although I guess John will have some objections) is a very small program, which essentially does:
TRNLNM from execmode in LNM$SYSTEM (covers both LNM$SYSTEM_TABLE and LNM$SYSCLUSTER_TABLE, but no more)

CALL LIB$SPAWN with the translated value (but only IF it translates!)

For each DCL script we need to activate with additional privs, we create a new LNM and a corresponding .EXE.

Instal the image with the required privs, and put the script in a W:(noaccess) environment.
Create an identifier dedicated to this script, and set an ACL on image & script to allow EXECUTE access.

In the .COM do the validations that can be done unpriv'd, f$priv the privs that are now authorised by inheritance from the image, perform any validations that require privs, execute the intended privd action, and Logout from the subprocess.

It LOOKS quite complicated, but actually, it is VERY convenient, and at least has MUCH tighter security than other options I have met so far.

BTW: kudos for this AFAIK go to my compatriot Frits Storms.

hth,

Proost.

Have one on me.

jpe

[HarrinG]

These are all good answers, but let me explain what I am trying to do and perhaps someone can suggest an alternative.

I will be responsible for an OpenVMS system that is being run in an ASP environment. I want to give customer users access to perform certain basic administrative tasks (so I do not have to do them) such as reset passwords.

The problem is I do not want these users to have any more rights than necessary and I do not want them to have access to the system prompt. I am working to create a menu system to allow these customer users to perform certain basic admin functions but I would like to keep them at a minimal security level.

This is why I wanted to know if there was a way to reaise security level within a DCL. However, if someone has a better alternative I am all ears.

[Dave Lennon · Accepted solution]

HarrinG,
I've used (and like a lot) a tool called PRIVDCL.
It does almost exactly what you are asking, after installing the tool's main executable with privilege, it lets you flexibly (via config file) control who gets the ability to run a certain DCL command procedure with the specified elevated privileges (albeit in a subprocess).
Provided you are careful writing the command procedure I believe it leads to a more secure system than without it, as you can allow people to do very specific tasks and not just grant them SYSPRV all the time, for instance.
It can be found at your favorite VMS public domain software ftp site, such as:

http://www.tmk.com/ftp/vms-freeware/fileserv/privdcl.zip


It is originally at:

ftp://ftp.lawrence.edu/public/UTILITIES/PRIVDCL.ZIP

Later,
Dave

[HarrinG]

PRIVDCL might be the answer I am looking for. As I indicated the key is to give the users the right to do things within the DCL menu but not once they leave.

[HarrinG]

Thanks all for the comments and suggestions. There were some good ideas here, Appreciate the assistance