how to maintain 2 separate UIC groups on a single node

[santosh anchan]

I want to maintain 2 separate UIC groups on an OpenVMS system. The UIC groups are such that they are logically on different disks on the same system and accessing separate set of files.

When one UIC group user logs in to the system he has his own process and group of files and do not have access to files of other UIC group.

It is like having two separate systems running at the same time but they are logically separate and totally unaware of other UIC process.

When UIC-1 logs in he sees only process related to that UIC-1. When UIC-2 logs in he sees only process related to that UIC-2.

Dont know whether this is possible in OpenVMS or not. Do let me know if you have some info on the same or any known implementation of similar type.

Thank you.

[Robert Gezelter]

Santosh,

Actually, it is quite common to have many different groups of users all working on a single node. Two groups is a pretty simple example.

Group logical names can easily point to different groups of files for different groups of users. My paper "Inheritance-based Environments for Standalone OpenVMS Systems and OpenVMS clusters" in Volume 3 of the OpenVMS Technical Journal (see http://www.rlgsc.com/publications/vmstechjournal/inheritance.html ) shows how this can be employed.

If you can be more specific as to how your applications is structured, perhaps I can be more specific as to what issues are likely to arise.

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

[Dean McGorrill]

Sure, as bob says its common..

>logically separate and totally unaware of >other UIC process.

>When UIC-1 logs in he sees only process >related to that UIC-1. When UIC-2 logs in

you can always do a show sys or a show user and "see" the other processes of any uic.
but in effect they can be separated work wise. you can
always put in restricted or captive accounts
and code to prevent them from accessing info
about the other uic. Dean

[Andy Bustamante]

OpenVMS was designed to support this configuration.

>>>When UIC-1 logs in he sees only process related to that UIC-1. When UIC-2 logs in he sees only process related to that UIC-2.

How controlled do need to make the environment? Out of the box, unique groups will isolate file access. Users do have the ability to check if other users are logged on. Depending on the application, locking down access is a straight process.

I'd recommend looking at the VMS Guide to Systems Security, http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/aa-q2hlg-te.HTMl and the System Manager's Manual, vol 1 http://h71000.www7.hp.com/doc/82FINAL/aa-pv5mj-tk/aa-pv5mj-tk.HTMl.

You can review the write ups of VMS at DEFON. OpenVMS was banned for being "cool and unhackable" and invited not to return.
http://groups.google.com/group/comp.org.decus/msg/ccf63376f8cb26d1

There are also consulting and training services available to assist in a project or long term system administration depending on your business requirements.


Andy

[Robert Gezelter]

Santosh,

To amplify on Andy's and my earlier comments.

I have run OpenVMS systems with literally hundreds of groups, each operating in isolation from one another. In some cases, these groups were hostile to one another (college environments can be veery political). In other settings, I have run production, quality control, and multiple development environments on the same system, totally protected from each other. All this has been done in ways that are fully auditable, and have been used successfully for three decades.

And yes, the obligatory disclosurem we do consult with clients on their implementation of such enviroments.

- Bob Gezelter, http://www.rlgsc.com
Contributor, "OpenVMS Security", Handbook of Information Security (Wiley, 2005)

[Thomas Ritter]

One of the advantages of organising userids into groups is that you can take advantage of GROUP privileges. Many system services like $getuai allow access if one has GROUP priv to information about members of the same group. This provides the ability to delegate control to those with GROUP priv. Very useful.

[Robert Gezelter]

Santosh,

Thomas Ritter brings out another good point.

At HP World 2004 in Chicago, I taught a seminar around a similar concept. I actually delegated almost all management functions to Group admins, who were, as far as OpenVMS was concerned, non-privileged users. The introduction to this seminar are at http://www.rlgsc.com/hpworld/2004/N227.html (it was a half day seminar, with several scenarios, thus the actual workbook is not on the www).

Attendees were surprised to note that it was possible to run a several hundred user environment with only a handful of privileged administrators. Almost all tasks were delegated to special users within each user group.

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

[John Gillings]

Santosh,

**WARNING - UNSUPPORTED**

Something you may want to try. Note that SHOW.EXE is installed with WORLD privilege. That is what allows commands like SHOW SYSTEM to display information about all processes.

On my system SHOW looks like this:

$ install list/full show

DKA0:.EXE
SHOW;1 Open Hdr SharAddr Prv
Entry access count = 198
Current / Maximum shared = 0 / 0
Global section count = 2
Privileges = CMKRNL WORLD NETMBX AUDIT
Authorized = CMKRNL WORLD NETMBX AUDIT
Resident section count = 0000


You *MAY* find that changing the privilege list to:

CMKRNL, GROUP, NETMBX, AUDIT

may get you closer to what you want, as all the SHOW commands will now be limited to processes within the same GROUP (unless the use holds WORLD privilege, in which case it will behave as normal)

The system startup installs SHOW, but you can replace it with:

$ INSTALL REPLACE SHOW -
/PRIV=(CMKRNL,GROUP,NETMBX,AUDIT) -
/AUTHPRIV=(CMKRNL,GROUP,NETMBX,AUDIT)

You'll need to execute this on system startup.

It may be possible to do similar things with other images installed WORLD.

HOWEVER, things may also break, so make sure you do adequate testing.

[Robert Gezelter]

John,

That is an interesting idea, but I would like to suggest a more nuanced solution (and preserve the existing functionality).

Create separate copies of the images involved and modify their default privileges. Then create a customized DCLTABLES that references the modified copies.

As a further safety, I would also recommend adding ACL entries to prevent non-system manager users from accessing the regular DCLTABLES or images (Belt and suspenders safety).

Over the years, I have seen many variations, it depends on the application. OpenVMS is better at this type of abstraction than many other systems because of the logical name facility. The logical name facility, together with the ability to protect files, names, and other information makes it possible to implement a wide variety of possible environments, all without altering the basic OpenVMS structure.

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

[Hoff]

>>>It is like having two separate systems running at the same time but they are logically separate and totally unaware of other UIC process.<<<

If the usernames or the two environments are in different UIC groups above UIC group 10, then many of the displays and standard mechanisms will effectively keep the users separate, and away from each others.

But what you ask is not possible in the general case. (I'd have written "pedantic case" there, but I've dealt with military-grade security in the past. Military-grade security is, um, very detailed. For a quick overview of discretionary and non-discretionary system security, see http://64.223.189.234/node/356 ) The hole you are seeking to plug here is called information leakage or a "covert channel", and the OpenVMS security model has many areas where covert channels exist. MAIL, SHOW SYSTEM, and a number of other commands can all comprise covert channels.

That channel can be plugged with a VM, with OpenVMS Galaxy, or with multiple nodes. Which is a comparatively heavy-weight solution.

I'm guessing you're doing some sort of server consolidation, and putting each environment from the previous server into a unique group is going to be the easiest, and probably the safest and most maintainable approach.

Stephen Hoffman
HoffmanLabs LLC

[santosh anchan]

Hi everyone,

Thank you for all the valuable solutions.

I thought of making it more clear so that once I start with it I should not get stuck.

Below is what I am planning to do:

I have 2 systems, System_A running on an OpenVMS Alpha machine and System_B running on another OpenVMS alpha machine.

Both the systems where they are running are using MAIL boxes and LOGICALS.
In fact the logical names and mail box names are identical in both the systems.
Also the most of the EXE names are same.

So if I think of bringing both System_A and System_B on one OpenVMS alpha machine without changing much code in either of the systems. Will I be able to do it by having 2 different UIC group?

The only change I am intending to do is making the logicals to point to different disks and renaming the MAILBOX names.

[Hoff · Accepted solution]

I'd be surprised if anyone here would answer your question with certainty.

The UIC is only part of the equation here; mailboxes and logical names can certainly be constrained using group UICs and private or grup logical name tables, but there can be various things that cause applications to conflict.

Can this be done? Yes. Can the UIC groups help? Yes. Is it certain that these two disparate environments won't somehow overlap? No.

Factors ranging from installed images or configuration requirements or version requirements or system parameter expectations or any number of other such details can cause conflicts.

Have at; try it. It'll *probably* work, but I'd certainly expect a few bumps. I've seen cases, however, that would conflict and would require some changes, ranging from trivial to the significant.

The brute-force approach here is to run the systems under Alpha emulation, or in an OpenVMS Galaxy, or in a couple of 1U servers (blades, on Integrity), or other similar scheme. A virtual machine would be ideal.

[Robert Gezelter]

Santosh,

As Hoff has pointed out, running two virtual machines guarantees that even a poorly-behaved application cannot interfere with another poorly-behaved application on the other virtual machine.

That said, I would recommend a careful review of both applications and the way that they interact with the system (Obvious disclosure: We do provide consulting services in this area). It is quite possible that there are no problems, or the problems are of a very discreet nature (e.g., gratuitous use of the system-wide logical name table when a group or other name table is appropriate; we have seen this many times).

I have run OpenVMS systems in extremely uncontrolled environments without any problems where there were many, many separate groups, all doing their own applications with absolutely no coordination between the different groups. It does work. (Which indirectly lead to the 2004 presentation I referenced earlier).

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

[Jan van den Ende]

santosh,

I have to fully agree with Robert.
We run a cluster with > 4000 users, more than a dozen applications, some of them containing VERY sensitive data. Every user must be authorized individually for each app, before he can even see that it exists.
One of those apps consists of many (currently > 2000) separate "projects" for which the same discreteness applies.

All of this is achieved by setting up an identifier for each applic, and for each project; and the selectively granting the relevant identifier(s) to the authorised people.

All of this is just standard VMS, it only needs to be set up consistently.

If you need assistance: in the UK there are also various consulting firms that I think will be happy to give a quote for their help.

(I would offer to do so myself if you wish, but that would also have to include travel and lodging expenses, so probably would not be your most economic choice).

Success.

Proost.

Have one on me.

jpe

[santosh anchan]

Thank you all for confirming that it is possible to keep 2 systems virtually separated on OpenVMS.