psuedo setup on openVMS

[SAMI AHMAD]

like we can psuedo in unix enviornemnt to become another user is there a way to do this in openVMS ?

[Ian Miller. · Accepted solution]

The underlying support exists in VMS but there is not a standard utility shipped to do this with VMS.
Freeware like HGLOGIN does the job
http://vms.process.com/scripts/fileserv/fileserv_search.exe?package=hglogin

and there are commercial packages which include this.

[Hoff]

It's sudo on most Unix and Linux boxes. Not pseudo.

sudo and the ability to swap usernames is one of the banes of auditors and security folks in general. They *really* don't appreciate the lack of accountability here.

While it is possible (using personas, hglogin, wheel or other such) to do this, force-fitting a solution such as sudo can cause more problems than it solves. OpenVMS isn't Unix, and OpenVMS and its applications work differently than Unix. Far more of the process context is tied to the username and the login environment. Which means having a direct sudo analog doesn't necessarily haul over the login environment, the run-time environment (symbols and logical names), the process quotas, etc.

Process management and authentication and security are among the implementation areas of OpenVMS that are most different from Unix and Linux, too.

OpenVMS provides various alternatives to what sudo and such are used for, including ACLs. (ACLs are not as well developed on various Unix platforms.) Most folks use ACLs and identifiers and subsystem identifiers and such, which are techniques which have some similarities to what you can do with sudo and setuid and such. (And folks are getting away from using setuid on Unix, too.)

So. ... What task is it that you really want to do? What problem(s) are you looking to solve that would lead you to consider sudo? And what are the details of the OpenVMS version and platform here?

[SAMI AHMAD]

what I want to achieve is that every user should login in their own accounts and then from there access the oracle account.
this is for auditing purposes so that we know who is using the oracle account and doing what.

regards

the platform is alpha AXP

[Hoff]

What might you mean here by this "oracle account"?

[SAMI AHMAD]

a user account called 'ORACLE'
I dont want people logging into this openVMS account directly but rather login into their own account first lets say 'USER1' and then sudo to ORACLE.

[Richard W Hunt]

We have OpenVMS 7.3-2 running ORACLE 9 here. You have to be VERY careful with what you suggested, as you really DON'T want your users running as ORACLE. Trust me, you don't. No matter WHAT you think you want.

ORACLE is exceptionally privileged. Among other things, it has privileges such as CMKRNL, SYSPRV, MOUNT, LOG_IO, WORLD, OPER, SYSNAM, and SYSGBL - plus a couple of others that aren't that nice either. With those privileges available, your users can shut down your box in seconds by acting like ORACLE.

Far better would be that you relax some of the permissions to allow users to see the ORACLE folders. Then grant the users roles within ORACLE that specify what they can and can't do. Have them run the @ORAUSER script with the instance name as the P1 argument (on ORACLE 9) or @[...instancename]ORAUSER (on earlier ORACLE versions).

Now let ORACLE's internal security protect your database and let OpenVMS security protect the rest of the system.

We were lax with ORACLE a few years ago. Some jerk shut down our entire system by going into ORACLE and inadvertantly dropping a table. "Just seeing what I could do", he said.... Users are like that, which is why "USER" is surely counted among the nastiest of the four-letter words.

Good thing we still had the original transactions used to build that table. Otherwise, about x thousand people wouldn't have gotten paid that week. (Yes, it was a payroll-related system.)

If direct access to ORACLE's powers is required for your application, it is time to redo that application. You might not think that is a productive answer, but I assure you that it is a correct one.

[SAMI AHMAD]

your concern is genuine but I am planning to restrict acceses to oracle account only to the DBAs but through their own login.

[Hoff]

Why have differing privileges and passwords and multiple usernames enabled here?

If there is sensitive data, credit card data, healthcare data, regulatory-related data, business-critical data, or anything related to the current and continued operations of your company, the posited approach could well result in career-level problems at a minimum. For you. Directly.

If you need or want to take this course, disclose what you're doing fully to your manager and to corporate legal (if there is any sensitive data here), and get it all in writing.

[Robert Gezelter]

Sami,

Getting this right requires understanding precisely what is trying to be done.

Managing the ORACLE database has certain requirements, this can be accomplished in some ways other than running things under ORACLE.

ORACLE's management environment has some quirks (I can say this having hit some of them).

I recommend careful review. If needed, get a someone with expertise in in-depth system management to review what the options are [Disclosure: We provide such services, as does Hoff and some other regular contributors].

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

[SAMI AHMAD]

our requirement is for auditing .if two dba's login into oracle account we can't audit who did what, but if a dba first login into his/her own account and then do a sudo to the oracle account then we can audit that usage right?
I am testing the HGLOGIN and will let you know if it gives the complete oracle enviornment or not .

[Robert Gezelter]

Sami,

There may be a variety of ways of accomplishing that particular goal if it is only a documentation requirement.

In that case, the information could possibly be derived from the accounting or login records (in the case of a DECnet login, for example, the ID of the remote session -- DECnet Node ID and Username) is available as a JOB logical and using F$GETDVI, if I recall correctly.

This could be written to the log during the login process.

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

[Willem Grooters]

In advance: I'm not familiarc with Oracle on VMS and it's requirements (and quirks) (though I've done DBA work on other platforms) so I may be completely wrong in my views as a "system manager".

I severely doubt it is needed that the DBA needs acces to the Oracle account for the work to be done.
When the Oracle and user accounts are set up with the right identifiers and privileges, the DBA should be able to login into his own account, and stay there. Be sure to have the privileges, required to access the database, be set as authorized privs, not default, so the DBA will have to SET PRIV before accessing the database environment. You could even think of a captive, or resticted account for this type of access, which disallows the DBA extending the high-privilege situation outside the environment.

[Karl Rohwedder]

Sami,

another useful tool would be JUMP. It allows for fine-grained control, who could JUMP to which user and provides e.g. mail notification and recording sessions.
You find it on the freeware CD.

regards Kalle

[Hein van den Heuvel]

Sami>> if a dba first login into his/her own account and then do a sudo to the oracle account then we can audit that usage right?

NO. WRONG.

Sami, you are looking entirely in the wrong direction. Forget about sudo or anyting like that. And forget about havign your DBA's do "connect / as sysdba" and such.

Create proper Oracle user accounts for each DBA, identified by passwords or by OS username (my preference).

OpenVMS + Oracle has all the features needed for full accountability.

Re-read Richard Hunt's advice very carefully. He hits on most problems and has the workaround suggestions.

Good luck!
Hein.

[SAMI AHMAD]

hi Karl!

where can I find this 'freeware CD' containing JUMP utility ?

[Hoff]

SAMI, if you don't know where the OpenVMS Freeware is located, then please read the OpenVMS Frequently Asked Questions (FAQ). Or work with Google. Or both.

http://www.google.com/search?q=openvms+freeware+jump

http://mvb.saic.com

http://www.hoffmanlabs.com/vmsfaq

[SAMI AHMAD]

thanks!
I found the source code and binaries but the binaries are for 7.1 , does any one have compiled binaries for JUMP for vms alpha
7.3-2 ?

[Richard W Hunt]

I will be more specific. In our environment, we created a special user group for each major product that had separate administrators. I.e. ORACLE has its own OpenVMS group number. Then we added individual user accounts in the same group with ORACLE but different member numbers.

We then gave each user the same privs as ORACLE. Within ORACLE, we defined each user to have the DBA role and all the other accessory roles that go with that. We relaxed the ORACLE directory permissions so that GROUP had the same permissions as owner. We assured that each user logged in as ORA_SAM or ORA_JACK or ORA_SALLY, etc.

ORACLE will REPEAT will work just fine and yet everyone has distinct logins. By making ORACLE its own group that isn't within the boundaries of MAXSYSGROUP, you can run the utilities you need from any of the ORAxxx accounts described above, because the ORACLE warnings about "SYSTEM not allowed to issue this command" don't ever kick in. You might have SYSPRV when you do your work as ORAxxx, but you aren't a "true" member of SYSTEM.

If you think YOU have auditing issues, just imagine what I have with a Dept. of Defense system. Yet because of our design and the care we exhibit in splitting out our users as described above, we have a 3-year Authority To Operate on a Dept. of Defense network. That's as much as anyone ever gets. You haven't SEEN auditing until you've had to provide DoD auditing reports.

Sami, I most strongly urge you to consider the above line of thinking, even if you don't do it exactly like I described. Just come close and you won't have an issue.

Another trick we played was that the ORAxxx accounts come up with all the ORACLE privileges but not by default. They are authorized but not enabled. The ORACLE DBAs have to issue a second command to enable their privileges, just to sort of force them to pay attention to what they are doing. AND they know I've got auditing turned on and operator logging wide open. So anything they do, I'll know about.

[Robert Gezelter]

Sami,

I would agree with what Richard said in his post. Assuming another persona is always FAR less preferable than granting access. Additionally, the audit log records will always contain the correct ID, something that is not always true otherwise.

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