Enable/Disable dynamic identifiers in C.

[Oscar van Eijk]

Hi guys,

Thanks all ye for your help.
The answer I was hoping for was: "Use this system service: [...]", but at least now I know why I couldn't find one.

I didn't bother to check further on SET RIGHTS, but it turns out that image is installed w/ privs also.

I'm not quite sure which solution I'll go for yet, but you provided me with enough info to pick one.

[Wim Van den Wyngaert]

John,

I never used shareable images with privs so sorry for my bad advise.

Can I use repeat in tpu to write my punishment ?

Wim

[John Gillings]

Oscar,

>I didn't bother to check further on
>SET RIGHTS, but it turns out that
>image is installed w/ privs also.

That doesn't necessarily mean that privilege is required for this particular operation. It's definitely worth checking out the source to see how the /ENABLE/DISABLE is done, and determine if privilege is required. (When you find out, please post it here so it's documented somewhere! ;-)

Note that with appropriate privilege (CMKRNL) you can do SET RIGHT/[EN|DIS]ABLE/ID= to affect the rights list of another process. You could therefore use SPAWN or system() to do the enable or disable.

Since you don't want the caller to be privileged, this will get a bit ugly... you could write a program installed with CMKRNL privilege that accepts three parameters - a PID, the target identifier name and an enable/disable flag. That program would confirm that the target PID is in the ancestral chain of the current process - something like:

pid=selfpid
master=$GETJPI(pid,"MASTER_PID")
ok=false
do while NOT ok AND pid <> master
ok= targetpid==pid
pid=$GETJPI(pid,"OWNER")
end while

If the target PID checks out, SPAWN a privileged subprocess to execute the SET RIGHTS command.

As long as this isn't something you're doing thousands of times an hour, spawning two processes to flip one rights identifier isn't pretty, but it's not too much of an issue. The same code should run on VAX, Alpha and IA64. (Oh, and note that on older versions of OpenVMS "IMPERSONATE" privilege is called "DETACH")

[John Gillings]

re Wim,

> Can I use repeat in tpu to write
>my punishment ?

:-) As long as it makes you remember!

Unfortunately "privileged shareable image" is a widespread OpenVMS myth. They do not, and cannot exist (some cursory analysis will show that if they existed, OpenVMS security would not!)

To try and stem the spread of the myth, it's necessary to counter any claim of existence with a proximal statement "There is NO SUCH THING as a privileged shareable image!"

You can achieve the effect with a User Written System Service (UWSS), but they're very tricky to write and tend to generate bugchecks during development. See the Linker Manual for details.

[Jon Pinkley]

Oscar,

Can you tell us if everything done while in the "role" is done by the C program, or was the plan to run the program which will enable extra access and then return to DCL leaving the enhanced capability in place until it is specifically disabled by running a program to change role back to "normal".

You specifically mentioned CMS. I believe there is an API for CMS. If that is the case, then at least in theory it would be possible to write a program to do the authentication of role, and then the CMS tasks, all under control of the program. If that is the case, then protected subsystems will work. On the other hand, if you want to return to the DCL prompt and still have the enhanced capabilities, I am not aware of any way to do that using protected subsystem identifiers.

So, if you plan to do everything inside the program, then we can provide more details about protected subsystem identifiers, and how they are setup and used.

Jon

[Oscar van Eijk]

@John; If SETRIGHTS uses $GRANTID, CMKRNL is required; it's installed with that, so I don't expect any surprises there :-S
I'll see what more I can found out and keep you updated.

@Jon; The software will return control to DCL. It must setup an environment for the developer (or whatever the selected role) to work on, including target system (CPU, VMS version, layered products to build with), proper CMS library (or CVS server and root for some projects), and a lot more.
The software does have an own CLI (of course supporting all exected cmd, including SPAWN), so I don't simply wanna install it with privs :-/

[Jon Pinkley]

Oscar,

Given your requirements to return control to DCL, I know of no way to use protected subsystem identifiers, which have the effect of "granting an identifier to an image", much like privileges are granted to an image when it is installed with privs.

So, you could use $GRANTID/$REVOKID from an image installed with CMKRNL privilege to do what you originally asked (granting/revoking a dynamic id), or $GRANTID to turn off and on the noaccess attribute.

However, here's another possibility that may allow you to get the control you want, without all the hassle of writing a safe version of a program to be installed with CMKRNL privilege (which is an ALL class priv).

On Hunter Goatley's VMS freeware archives is a program, JUMP, which allows specified users to login to another username and have a logfile created. This is controlled by a text file that specifies what users can jump and to what username(s) they can jump to. It does this by creating a pseudo terminal (FT device), and then creating a process, and as such the user does not need to know the password of the account being jumped to; in fact the target username can have interactive access disabled in UAF and the account can still be used via JUMP. This is actually a useful attribute, as even if someone guesses the password, they will not be able to log into the account in the normal manner.

The idea would be to create a username for each role/real person and set this username up with the privileges/identifiers needed for the role. Then the user from their normal non-privileged account would jump to the role account to do the work, and logout when they were done with the role specific duties. A log file can be created that is inaccessible from the "jumped from" or "jumped to" users, given neither of those username has privileges that would allow them to see the files for another user, i.e. if they don't have SYSPRV (and are not a member of a UIC group <= MAXSYSGRP), READALL or BYPASS priv.

While this doesn't specifically answer your question about enabling/disabling dynamic identifiers, I think it would be a possible solution for your problem, with the side benefit of having the option to create a logfile of what was done while in the role, although that is not a requirement.

The downside is that you will need to have multiple accounts for your users. And from a user standpoint it isn't all happening from the same process, so things like command recall, process logicals and symbols, access to their own non-privileged directory (unless allowed either by ACL or privilege in the "jumped to" username.

We use it, and it works. I would recommend at least taking a look at it.

Example:

Non-Prived user | CM role username | Admin role username

TEST1 [26,253] | TEST1_CM [31,67] | TEST1_ADMIN [32,302]

Create JUMP_ACCESS identifier (when JUMP installed)

Grant JUMP_ACCCESS to TEST1

Add a line to JUMP_ACCESS.DAT file (which is protected)

test1 : test1_cm,test1_admin : sen!i # secure, exact, all notification, don't include log in mail

Now the user test1 can enter the command

$ jump test1_admin

and they will be logged into the test1_admin username with all its access rights, go through its login.com etc, And the session will be logged (secure) and when the session is complete a message will be sent to a specified jump administrator. Optionally (we don't do this) the complete logfile can be sent with the message.

Where to get JUMP:

ftp://ftp.process.com/vms-freeware/fileserv/jump.zip
http://ftp.process.com/ftp/vms-freeware/fileserv/jump.zip

Good luck,

Jon

[Oscar van Eijk]

Jon,

Thanks for your detailed answer. I'm sure this might work for others with a similar problem (and searching this forum :), but not for me :-/

I know JUMP, but it does not offer the option to combine environments; e.g. when a developer works on a product and needs to compile/link with a library that is not yet released, he/she needs access to the environment where that library is developed; 1 role for multiple environments....

I never said the problem is simple.... I just want a simple solution :)

Oscar

[Jon Pinkley]

Oscar,

I fail to see how the ability to turn on/off an identifier on one system will help control access on another. I am specifically referring to your mention of "CVS" and "root", which at least sound like unix to me. So if that is the case, how will an identifier on a VMS system mean anything to the unix system?

I am trying to understand the unspecified build environment you are speaking about. Is it something you have developed in-house, or is it a commercial package to has callouts to user written software (possibly the "C software" you were referring to)?

Jon

[Oscar van Eijk]

The CVS runs on a Linux box indeed, that's not secured by de development environment, but just as the proper CMS$LIB is set when the user selects an environment, so is the correct CVS environment defined is the selected project happens to be in CVS; that's the case with Java projects.

Security is not the main issue; the dynamic identifiers are used just to create a transparent environment and prevent mistakes (not all developers are familiair with VMS).

All software is built in-house; we build and maintain it for Dutch Railways that needs to run on several VMS version, even on some good old VAXes.
"C" is just my personal choice :)