VMS- Read only User Account?

[shrloc]

We have a three node cluster. V8.3-1h1. Two nodes are production and one is being modified for use as a development only node. Nodes A and B have their own “disk1: and disk2: (volume label User_1 and User_2”, that only A and B can see. Node C also has its own “disk1: and disk2: (Volume label Dev_1 and Dev_2)” that only C can see. All nodes have access to “disk3: (volume label User_3). The files on Node C are copies of those on Node A and B.

Nodes A and B use one SYSUAF and Node C uses its own. The developers only have active accounts in the Node C SYSUAF and the Users only have accounts in the one being used by Nodes A and B.

What we would like to be able to do is use something like WS-FTP to allow developers to get the most recent files off one of the other nodes and bring it to the development Node, but not be able to write back. In other words: FTP files from Node A or B to Node C, but not the other way (Node C to Node A or B). The programmers have to be able to touch any file in any user directory.

My plan had been to create a User account that could only read and not write. I created a restricted account in Node C’s SYSUAF with authorized and default privileges of NETMBX, READALL and TMPMBX and a LOCKPWD flag. I set up an identical user account in the SYSUAF for Nodes A and B. The thought was that the programmers could then use the accounts to connect to the Nodes with WS-FTP and move the files from production to development, but not back again.

After testing I find that the transfer can happen in both directions.

Our goal is to prevent programmers from placing modified files back on the production Nodes without going through the Project and System Managers’ review. Once approved the System Manager would then place the files onto the production Nodes.

I am open to any suggestions.

[Hoff]

1: you should have your production files under source code control.

1a: That means you can rebuild your configuration.
1b: you have change control and change tracking
1c: you can revert.
1d: you can easily use (for instance) Mercurial (Hg) to pull the files to a development system.

2: you should not have developers loose in the production environment.

2a: developers make changes, and (with simple errors) that can render production unstable.

2b: it is fairly common practice to have a completely separate development cluster, so that (for instance) locks don't collide and developers running with privilege don't (for instance) nuke the wrong files.


3: multiple SYSUAF files within a cluster requires UIC coordination, or unexpected access or unexpected access denials can arise.


Now as for your question, that's easy. Create a user that has an identifier granted that allows (only) read access to the target files, and add that identifier to ACLs on the files and directories you're interested in in your production pool. That'll involve creating the identifier, granting it to the ftp user or (since you're in a cluster, you needn't use ftp or DECnet FAL at all) just grant the identifier to the developers and let them go directly at production area (for read).

See the OpenVMS system security manual for details on ACLs and identifiers.

[Andy Bustamante]

Given that you're already in a cluster environment, mount the source disk on Node C and grant read only access to your developers to the appropriate directories. skip the issues with FTP and simply copy file.

One of the advantages to a cluster is a single SYSUAF and RIGHTSLIST files. Seriously consider merging these.

[Shriniketan Bhagwat]

Hi,

How about alocating ACls for files on node A and B. Refere the chapter System security services from Open VMS programming concepts manual, Volume 2 for more details.

Regards,
Ketan

[Robert Gezelter]

shrloc,

There are better ways to do this. The cleanest is to properly protect the files, and then it does not matter if it is on the same disk.

If there are political issues, then I would agree with Andy: Mount the disk /NOWRITE on the development machine. However, as noted, this is not necessary unless the files are:
- not ACL'ed correctly
- the developers have privileges (in which nothing short of a separate copy will work in any event).

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

[shrloc]

One thing I should have noted it that the progammers are only allowed to log on to the node C. Everyone else logs on to the other noded via load balancing.

Also these system was well establed before I got here and the Manager who created it did not use ACL or bother to establish unique UICs. (I can hear the collective gasp).

[Hoff]

And if you go the ACL route as all three previous posts suggest, you must also coordinate the identifier values across your two lobes of this cluster. Which you should do anyway. This in addition to coordinating the user UIC values.

if you don't coordinate these values, you can and often will get unexpected denials or unexpected access.

If you want to clean off all of the ACLs on a target device (which can be part of merging a cluster, or when otherwise resolving disparate identifiers), I've posted a tool here:

http://labs.hoffmanlabs./com/node/426

[Jan van den Ende]

shrloc.

>>>
... it did not use ACL or bother to establish unique UICs.
<<<
Firsth thing: CORRECT THIS!!!

And then:

DO take the other suggestions:

- make well-considered identifiers & rights for them
- MERGE (but with proper safeguards!) SYSUAF & RIGHTSLIST.
- (if you still feel the need) rstrict the develloppers to node-c. (straight-forward DECnet-access, or well-chosen FTP-(or similar)-alias.
Prevent any devellopment activity access with (nodename based, special IDENT based?) ACLs.
Been there, done that. 1% inspiration or copying ideas), 99% just plain, simple work.

hth

Proost.

Have one on me.

jpe

[John Gillings]

shrloc,

>created a restricted account in Node Câ s
>SYSUAF with authorized and default
>privileges of NETMBX, READALL and TMPMBX
>and a LOCKPWD flag

It's not entirely clear... are you allowing these "restricted" users to login to a DCL prompt? If so, remember that READALL is a class ALL privilege. It's actually misnamed, it should be called READANDCONTROLALL. That means READALL can trivially be converted into any privilege, so such users are definitely NOT restricted. Even in a CAPTIVE account, READALL can be tricky to pin down.

Having multiple SYSUAFs in a single cluster is a very, very BAD idea. Unless you have very tight coordination between changes across SYSUAFs, you have a significant potential to create "invisible" security holes.

Rather than tinkering with suggestions from strangers, I would STRONGLY recommend you sit down and read the Guide to OpenVMS System Security and design a workable security model for your system that satisfies all your requirements and minimises risks.

This is not something you can do with a wave of a magic command. You need to plan it carefully. If in doubt, hire a consultant with experience in the field.

[P Muralidhar Kini]

Hi Shrloc,

>> What we would like to be able to do is use something like WS-FTP to allow
>> developers to get the most recent files off one of the other nodes and bring
>> it to the development Node, but not be able to write back.

* MOUNT/NOWRITE on Node C
The disk can be mounted on the Node C with /NOWRITE qualifier.
The developers who log in to Node C will now be able to access the contents
of the disk. Because the disk is mounted "/NOWRITE", they would have only
read access to the disk and not write access.

Note that the entire disk would be available for Read access. If your original
plan was to share only directories "A" and "B" then this method may not be
suited. This is because as the disk is mounted with "/NOWRITE", the users on
Node C would have read access to all files/directories on the disk.

* User Account on NODE A/B with Read Access
User accounts would be created in Node A/B with limited access to limited
directories.

In this case, if your original plan was to shared only say directories "A" and "B"
then you can make use of the ACL's to have the user get access only to
directories "A" and "B". I guess this would be more suited to you.

Check the "OpenVMS Guide to System Security" Manual for more information
on the rights Identifier and ACL's.

Regards,
Murali

[Lester Dreckow]

Hi John,

>> remember that READALL is a class ALL privilege. It's actually misnamed, it should be called READANDCONTROLALL. That means READALL can trivially be converted into any privilege

I've heard that READALL should really be called BACKUPANDRESTORE due to its write access during a restore. But what is the above risk?

Cheers,
Lester

[Shriniketan Bhagwat]

Hi,

Yes, the READALL privilege lets the process bypass existing restrictions that would otherwise prevent the process from reading an object. It is intended to be an adequate privilege for backing up volumes.

Regards,
Ketan

[Jon Pinkley]

Shrloc,

First, if these three nodes are in a single VMS cluster, the suggestion to "Mount the disk /NOWRITE on the development machine" will not work if the disk is mounted for write access on another node in the cluster.

If you try, you will get the following message:

%MOUNT-F-INCONWRITE, inconsistent /(NO)WRITE option. Cluster mounted /WRITE

------------------

As said by others, all members of a single VMSCluster should share the same SYSUAF and RIGHTSLIST files (actually many more files should be shared; if you have a common system disk that is the default condition). While you can get it to "work" with multiple files, there are many opportunities for security problems. And there is little benefit to be gained by separate SYSUAF and RIGHTSLIST files.

The cluster is the security domain. There is no way to contain privileges to a single node. You may have the illusion of granting privilege on a single node of a cluster, but you will be fooling yourself.

What did you mean by "the Manager who created it did not use ACL or bother to establish unique UICs."? If multiple users have the same UIC, they will be treated identically from an object protection standpoint. When you have multiple SYSUAF files, coordinating them becomes much more work than it is worth.

If your developers need privilege, and you want to make it impossible for them to affect production, then they should not be in the same cluster. In that case, pull the third node out of the cluster and use DECnet or FTP to copy the files between the two security domains.

That said, for many environments, development can be done within the same cluster as production.

John Gillings warned about READALL being an class ALL privilege. That used to be true, but I don't believe READALL privilege is as dangerous as it used to be, I don't believe it still implies CONTROL privilege. At least I am not able to modify protection on a file owned by another user from a process with only TMPMBX, NETMBX and READALL privilege. (VMS 8.3 Alpha)

READALL does not give any special ability to restore files that I can find. If someone has an example of a READALL granting write or control access to files, please provide an example. It does allow the backup dates to be written (at least by backup when the backup/record operation is used). I was not able to modify the backup date of a file owned by another user using DFU set file/backup= when my process had only READALL.

Here's what the latest OpenVMS Version 7.3-2 (2003) security manual says:

-----------------------------
READALL Privilege (Objects)

The READALL privilege lets the process bypass existing restrictions that would otherwise prevent the process from reading an object. However, unlike the BYPASS privilege, which permits writing and deleting, READALL permits only the reading of objects and allows updating of such backup-related file characteristics as the backup date. See the HP OpenVMS System Management Utilities Reference Manual and the HP OpenVMS System Manager's Manual for a discussion of backup operations.

READALL is intended to be an adequate privilege for backing up volumes, so grant this privilege to operators so they can perform system backups.
-----------------------------

But there is no reason or need to give developers READALL privilege. Create an identifier, for example DEVELOPER, and then grant READ access to the directories you want the developers to have read-only access to with an ACL. Then grant the DEVELOPER identifier to the developers.

Hoff, Andy Bustamante, Jan van den Ende and John Gillings had good info.

Heed the advice to read the fine manuals.

http://h71000.www7.hp.com/doc/731final/6489/6489pro.html OpenVMS User's Manual

http://h71000.www7.hp.com/doc/82final/aa-pv5mj-tk/aa-pv5mj-tk.html HP OpenVMS System Manager's Manual, Volume 1: Essentials

http://h71000.www7.hp.com/doc/732final/aa-q2hlg-te/aa-q2hlg-te.html HP OpenVMS Guide to System Security

Jon

P.S. see attachment for an example of a possible way to set up a directory that can be updated by an otherwise non-privileged user that has a resource identifier PROD_REL granted (with the RESOURCE attribute). The files will be readable for process that is granted the DEVELOPER identifier.

[Robert Gezelter]

shrloc,

As has been noted, what really needs to be done here will most likely be:
- unifying identifiers
- unifying SYSUAF and RIGHTSLIST
- restricting logins to certain nodes by acount
- adding ACLs and/or properly configured UIC/GROUP protection to various files

The other solutions (I will plead guilty to suggesting /NOWRITE be tried; then again, Murali concurs (and he would seem to have some knowledge in the area, see http://www.openvms.org/stories.php?story=10/05/13/4458693 ), however, I did not mean it as a long-term solution.

I have cleaned up this type of thing for clients in the past with success, and it is not a high-risk activity, but one does need to thoroughly understand the OpenVMS security model and all of the implications. Restricting accounts requires a whole different password regime, and often the restrictions do not accomplish the desired goal.

John's comment that "This is not something you can do with a wave of a magic command. You need to plan it carefully. If in doubt, hire a consultant with experience in the field." is well-considered and good advice [Disclosure: We do provide consulting services in this area].

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

[Hein van den Heuvel]

shrloc,

How about PROXY access?

Everyone is right of course with the suggestions about really needing a single security domain, unique UICs and so on. But you knew that. You might not realize that this could be relatively easy to accomplish with a couple of scripts. It may well be worth the effort.

But if you end up with an 'it is what it is, deal with it situation' for the right or the wrong reasons, then consider using PROXY access? Check.
$ mcr authorize help add /proxy

You would need to protect the files with world:re of course. Create a local proxy user 'readonlyhack' in the node A/B sysuaf.
Give that proxy user a 'world' UIC (that is probably a new UIC group.).
Possibly give that user the data disk as default device for conveniency. Give it its writable directory there for logs.
Now 'map' the developers accounts onto the proxy either one-by-one, or the whole node: A> mcr authorize add /proxy C::* readonlyhack

From there on the developers can use commands like:
$ COPY A::[prod-dir]prod-file.idx []/log

- Nobody needs to know the passwordfor readonlyhack
- ACCOUNTING gives a simple access log.
- DECNET logging can give full access logs.

Good luck!
Hein

[Jim_McKinney]

FWIW...

In the event that you're using the MultiNet IP stack at version 5.2 or greater, SFTP permits restriction on access that is controllable via logical name.

MULTINET_SFTP__CONTROL

This logical can be defined /SYSTEM to any combination of NOLIST, NOREAD,
NOWRITE, NODELETE, NORENAME, NOMKDIR, NORMDIR to restrict the operations
that the user can perform with the SFTP server. NOWRITE will disable PUT,
DELETE, RENAME, MKDIR, RMDIR; NOREAD will disable GET and LIST.

MULTINET_SFTP__ROOT

This logical can be defined /SYSTEM to restrict the user to the directory
path specified. Subdirectories below the specified directory are allowed.