Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Resticting VMS access to DBAs ?

SOLVED
Go to solution
Thomas Ritter
Respected Contributor

Resticting VMS access to DBAs ?

We are restricting the number of "setprv" users in our environments. Matters are complex because of the different Companies contracted to work for the client. Our Database Administrators operate with all priviledges and have over the years successfully convinced the customer they need the access to meet their contractural obligations.
We run VMS 7.3-2 with RDB V7.1-401

Most objects can be ACLed. However the DBAs claims they need to use SDA to analyse locks. How can one counter this argument or provide limited access to SDA or provide SDA access using an ACL ? We feel the RMU utilites provide all the Lock analysis tools required.


14 REPLIES
John Gillings
Honored Contributor

Re: Resticting VMS access to DBAs ?

Thomas,

You can make a copy of SDA.EXE, put an ACE on it granting EXECUTE access to the DBAs, and INSTALL the copy with CMKRNL privilege. They can then analyse locks without having to have CMKRNL. However, they can also do all the other things SDA comes with, but it's all read only.

You may be able to block access to some of the SDA extensions by putting NOACCESS ACEs on the shareable images (see SYS$SHARE:*$SDA)

Log a case if you need more detail.
A crucible of informative mistakes
Thomas Ritter
Respected Contributor

Re: Resticting VMS access to DBAs ?

John, I attempted to install SDA with privs. Need to also install sys$library:SDA$SHARE.EXE
with privs to complete. SDA$SHARE has been linked with traceback. Installation fails. I will log a call.
John Gillings
Honored Contributor
Solution

Re: Resticting VMS access to DBAs ?

Thomas,

>Need to also install sys$library:SDA$SHARE.EXE
>with privs to complete.

Repeat after me... There is NO SUCH THING as a privileged shareable image! ;-)

What's happening is the activation of the privileged image puts the image activator into "paranoia" mode, which means it will only activate "trusted" images. That means only /SYSTEM/EXEC logical names will be followed, and the target image must be installed. No need for any INSTALL attributes:

$ INSTALL ADD SYS$SHARE:SDA$SHARE

will suffice, but if it's going to be installed, you may as well tack on /OPEN/HEAD/SHARE. This can be done with a traceback image, so it will work.

Added bonus? Only SDA extensions which are INSTALLed can be activated, so you don't need to ACL them, just install any that you want your DBAs to be able to run.

Here's what I did:

$ SET DEF SYS$COMMON:[SYSEXE]
$ COPY SDA.EXE SDAPRIV.EXE
$ SET SECURITY/ACL=(-
(IDENT=DBA_SDA_ALLOW,ACCESS=R+E),-
(IDENT*,ACCESS=NONE)) SDAPRIV.EXE
$ INSTALL ADD SDAPRIV/OPEN/HEAD/SHARE/PRIV=CMK
$ INSTALL ADD SYS$SHARE:SDA$SHARE/OPEN/HEAD/SHARE

Now, for anyone you want to run the privileged image:

$ DEFINE SDA SDAPRIV

Note that this logical name does not need to be trusted.


A crucible of informative mistakes
Robert Gezelter
Honored Contributor

Re: Resticting VMS access to DBAs ?

Thomas,

Also check the Database supplier startup and shutdown procedures.

While there is often little reason, some of the startup/shutdown scripts contain presumptions of privilege.

- Bob Gezelter, http://www.rlgsc.com
Richard J Maher
Trusted Contributor

Re: Resticting VMS access to DBAs ?

Hi Thomas,

It is my firm belief that there are two paths to choose from: -

1) Give the DBAs all the privs in the world so that they can get the job done when the operators call at 2am describing the contents of an RMU bugcheck dump on a corrupt database.

2) Install some Knowledge Base software where every conceivable problem has a matching "Solution Document" that can be seemlessly tied to the Utility that needs executing with all of the appropriate privileges for the job. And just any flying pig will be qualified to push the right button.

I respectfully submit that unless you are an accountant hell-bent on deskilling your workforce to such a level that it can be outsourced to Bangalore (or anywhere else)you will choose option one. If you have staffing issues then take on more reliable DBA support (Preferably in Perth where the 3hr time difference is so useful to the support window :-)

Why stop at DBAs? Why do System Managers have privs? It's not like they're installing VMS every day. Let's metric what they do during the day and Install a utility for every action they prform that needs privileges? Have you ever noticed how close their eyes are together? Or that they're always whispering?

Cheers Richard

PS. Security should be more worried about who has access to client sensitive data rather policing the police. I've yet to find an equivalent of the UK's data protection act here in Oz. (Apart from the ubiquitous "Check out our privacy document on our website")
Phillip Thayer
Esteemed Contributor

Re: Resticting VMS access to DBAs ?

Thomas,

I have to agree with the what John suggested. Make a copy of the SDA image and set the ACL on it. Then install it with CMKL and it will work fine. I have done this on different images to prevent users from doing very bad things.

Mr. Maher, I am not sure which knowledge base software you would use to do something like this. I have in the past setup problem tracking systems that allowed the knowledge database to grow with the problems reported. It would even generate a new FAQ each week with the most commonly asked questions and post it to the web-site automatically. (That one was a home-grown system written on a MS Windows based system). As for system security, as Thomas mentioned, his systems hold data from a number of client companies so the "brickwall" type of security between the different companies data is crucial to their maintaining the client base. At least that is what I would think, but Thoams would be the better one to answer that one. Your suggestion of limiting system managers is a good idea. You create one account used for VMS upgrades/installs (oh lat's call that account SYSTEM) and create seperate accounts for your system managers that are limited as to what their specific tasks are. I agree with your suggestion of outsourcing to Perth because that would bring jobs to Australia. The three hour time diffence would'nt matter to me if I had a 24x7 helpdesk in the US. The only potential advantage to outsourcing to Perth would be cost of personel and if I was going to outsource to save money I am pretty sure that Bangalore is much cheaper than Perth. So my choice would be for Bangalore, IF I were to suggest outsourcing at all, because of cost savings. Basically, the positives and negatives of outsorucing is all relative to where you are living. For you, if a company is located in Australia and they outsource to Perth then I think that is a good thing. If it is a US based company and they outsource to Perth then personally I think that is no better than outsourcing to India. (Execpt when I would have to go to the outsourcing site then Australia wins hands down because you have the better beer :)).

Phil
Once it's in production it's all bugs after that.
Thomas Ritter
Respected Contributor

Re: Resticting VMS access to DBAs ?

Here we are again. Progess is good. Production is being quarantined from unathorized activities. Last seems to be the RMU functions. From help we have


Required_Privileges

An access control list (ACL) is created by default on the root
file of each Oracle Rdb database. To be able to use a particular
Oracle RMU command for the database, you must be granted
the appropriate Oracle RMU privilege for that command in the
database's root file ACL. For some Oracle RMU commands, you must
have one or more OpenVMS privileges as well as the appropriate
Oracle RMU privilege to be able to use the command.

Has anyone had experience configuring RMU access with identifiers ?


Chris Barratt
Frequent Advisor

Re: Resticting VMS access to DBAs ?

>Has anyone had experience configuring RMU >access with identifiers ?

We use identifiers in our RMU ACLs. Nothing tricky about it, just like for VMS file acls.

In regard to the ACLs themselves, they are stored as an acl on the root file of the database. This means that you can copy them from database to database if you wish and edit them with "$ edit/acl" too.

When you look at them from DCL, the Rdb specific privileges show up as bit1+bit2 etc. When you use the RMU/SHOW PRIVILEGE command, it translates these into rmu$read+rmu$export etc.

Cheers,
chris
Thomas Ritter
Respected Contributor

Re: Resticting VMS access to DBAs ?

Chris, would you be able to provide an example, something which I can use as an example of good security ?

This is our setup

WIZ12> rmu/show priv wizard_data
Object type: file, Object name: WIZ_FOXTST_DB:[000000]WIZARD_DATA.RDB;1, on 18-APR-2006 16:14:38.30
(IDENTIFIER=[*,*],ACCESS=READ+WRITE+CONTROL+RMU$ALL)
Chris Barratt
Frequent Advisor

Re: Resticting VMS access to DBAs ?

Here is a typical sample, slightly changed for posting purposes....

Object type: file, Object name: SAN$03:[IMSPRODN.RDB]IMS_MST_DATABASE.RDB;2, on 19-APR-2006 13:22:21.24

(IDENTIFIER=[USER,SPECIALUSER1],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)
(IDENTIFIER=[USER,SPECIALUSER2],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)
(IDENTIFIER=[USER,SPECIALUSER3],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)
(IDENTIFIER=IMS_READ,ACCESS=READ+EXECUTE)
(IDENTIFIER=IMS_UPDATE,ACCESS=READ+WRITE+EXECUTE)
(IDENTIFIER=IMS_MANAGER,ACCESS=READ+WRITE+EXECUTE+CONTROL)
(IDENTIFIER=[OPERS,*],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)
(IDENTIFIER=[1,*],ACCESS=READ+WRITE+RMU$ALTER+RMU$ANALYZE+RMU$BACKUP+RMU$CONVERT+RMU$COPY+RMU$DUMP+RMU$LOAD+RMU$MOVE+RMU$OPEN+RMU$RESTORE+RMU$SHOW+RMU$UNLOAD+RMU$VERIFY)

The special users accounts are used by IT support staff or batch jobs. The ims_read and ims_update are gratned to user accounts that access the database. ims_update is for support users that need to change metadata in database (but mostly not used at the moment). The [opers,*] entry is for our operators who initiate backups. The [1,*] is for system manager/DBA type accounts who need access - but we don't always have a clear delineage here between the 2 roles.

You will have to use your own judgement on whether this is good security or not, but it seems to work for us. :-)
Chris Barratt
Frequent Advisor

Re: Resticting VMS access to DBAs ?

oops !

>ims_update is for support users that need >to change metadata in database (but mostly >not used at the moment).

this should have said ims_manager not ims_update !
Robert Gezelter
Honored Contributor

Re: Resticting VMS access to DBAs ?

Chris and Thomas,

A (strong) suggestion concerning the ACLs that were posted in an earlier posting. Do not use ACLs with individual or group UICs (e.g., [1,*]).

It is far superior, from both an auditing and control perspective, to express the access in terms of roles, which can be granted to (and/or revoked from) individuals. Both of the cases cited above fall into this category.

Authorizing an individual UIC for a category of access prevents tasking another individual from being tasked with those function without violating important tennets of security policy and auditing, to wit:
- giving them access to either the account (creating a situation where two people have access to the same account) OR
- granting access (and then removing access) every affected ACL to add the temporary access, an extremely time consuming and error prone operation.

Group permissions pose a similar problem. Granting access to an entire group makes it impossible to revoke access for an individual within that group without:
- revoking access for the entire group
- editing each and every ACL to insert a DENY access for the affected member of the group
- removing the affected individual(s) from the group in question (which has cascading issues)

It is far more efficient, safer, and auditable to grant access rights based upon non-UIC rights identifiers, and then grant those identifiers to user accounts. This is quite efficient (computers make excellent clerks) and it is emminently auditable.

- Bob Gezelter, http://www.rlgsc.com
Robert Gezelter
Honored Contributor

Re: Resticting VMS access to DBAs ?

Thomas and Chris,

My apologies for omission from my preceding posting.

I have used this precise approach at clients without a problem (performance, management, or auditor-caused) on multiple occasions. Those experiences formed the backdrop to my hands on workshop at HP World 2004 on OpenVMS User Environments. The summary notes (alas, not the workbook) for that workshop can be found at http://www.rlgsc.com/hpworld/2004/N227.html.

- Bob Gezelter, http://www.rlgsc.com
Robert Gezelter
Honored Contributor

Re: Resticting VMS access to DBAs ?

Thomas and Chris,

My apologies for omission from my preceding posting.

I have used this precise approach at clients without a problem (performance, management, or auditor-caused) on multiple occasions. Those experiences formed the backdrop to my hands on workshop at HP World 2004 on "OpenVMS User Environments". The summary notes (alas, not the workbook) for that workshop can be found at http://www.rlgsc.com/hpworld/2004/N227.html.

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