A VMS sysadmin recently asked us:
This is a perfectly reasonable request, and yes, there's a reasonable way to do this, although it does require the application of Access Control Lists (ACLs) thoroughly across the system's disk volumes. The approach to this problem in VMS is similar to what Linux/Unix sysadmins refer to as a “chroot jail” or “change-root jail.” Here's what we shared with that sysadmin:
In this example, we will use
JAIL for the name of a general rights-list identifier (RID) to prevent access to other restricted directories, and we'll use
JAILBIRD as the username who is being restricted. We're borrowing the terms from
chroot jail as used in Linux/Unix systems.
The first step is to create the
JAIL identifier and grant it to our
$ set default sys$system $ mcr authorize UAF> add /ident jail %UAF-I-RDBADDMSG, identifier JAIL value %X80010380 added to rights database UAF> grant /ident jail jailbird %UAF-I-GRANTMSG, identifier JAIL granted to JAILBIRD UAF> exit %UAF-I-NOMODS, no modifications made to system authorization file %UAF-I-NAFNOMODS, no modifications made to network proxy database %UAF-I-RDBDONEMSG, rights database modified
The purpose of granting the
JAIL RID to this user is to effectively “put him in jail” (makes him a
If you get an error like this when attempting to grant the JAIL RID to JAILBIRD:
UAF> grant /ident jail jailbird %UAF-E-GRANTUSR, user identifier JAILBIRD does not exist; JAIL could not be granted -SYSTEM-F-NOSUCHID, unknown rights identifier
…it very likely means that you've got more than one user account which is assigned (using) the same UIC value as
JAILBIRD has. Since this is a security-domain problem and solution, VMS is very strict about requiring that all users are assigned unique (that is, non-shared) UIC values.
Check for this with:
$ mcr authorize show [12,233] /brief
[12,233] is the UIC assigned to
JAILBIRD. If only one account shows up, then the RID for that user's account itself (that is,
JAILBIRD as a rights identifier) is missing. The simple fix for this is to just add that identifier:
$ mcr authorize add /id jailbird /value=uic=[12,233]
…and then retry the
UAF> grant /id jail jailbird command again – it should now work.
However, if more than one user account (including
JAILBIRD) shows up, then you must reassign one or more of the users' UIC values so that all are unique.
For each user (including
JAILBIRD) who shares a UIC value, assign a new unique UIC value to each of those (except for the first one, who can keep the original UIC
[12,233]) like this:
$ mcr authorize mod jailbird /value=uic=[12,344] ! Note: Create/assign a new, unique UIC value $ set file /owner=jailbird staff:jailbird.dir ! STAFF: is logical name for user's default disk/dir $ set file /owner=jailbird staff:[jailbird...]*.*;* ! So he owns all of his own files again...
Do this for all other user accounts that are sharing that first UIC value, giving each user a new and unique UIC value (e.g.,
[12,346], etc.). Remember that UIC values are expressed in octal notation. One of those users can keep the original UIC
[12,233], as it will now be uniquely assigned to that remaining user.
Once you've got this shared-UIC untangled, and since JAILBIRD will now have a unique UIC of his own, you can retry the
UAF> grant /id jail jailbird command again, and it should work now.
Next we need to block his access from all other disk volumes in the system. In this example, we'll show the application of an appropriate ACL to an example disk
$1$DGA201:, with both before and after displays of that volume's protection status. The same actions are needed on all disk volumes other than the one holding the
JAIL user's default directory.
$ show security $1$dga201: /object_class=volume QUORUM object of class VOLUME Owner: [SYSTEM] Protection: (System: RWCD, Owner: RWCD, Group: RWCD, World: RWCD) Access Control List: <empty> $ set security $1$dga201: /object_class=volume - _$ /acl=(identifier=jail,access=none) $ show security $1$dga201: /object_class=volume QUORUM object of class VOLUME Owner: [SYSTEM] Protection: (System: RWCD, Owner: RWCD, Group: RWCD, World: RWCD) Access Control List: (IDENTIFIER=JAIL,ACCESS=NONE)
The system disk requires special attention. The user will need access to
DCLTABLES.EXE and probably many commands and utilities on the system disk such as
If the VMS system disk only contains the standard OpenVMS files and utilities and you trust the current security, then you can omit it from consideration. If you want to be a bit more cautious, then you can limit the
JAIL user to read only access.
$ set security sys$sysdevice: /object_class=volume - _$ /acl=(identifier=jail,access=READ) $ show security sys$sysdevice: /object_class=volume CLASS8 object of class VOLUME Owner: [SYSTEM] Protection: (System: RWCD, Owner: RWCD, Group: RWCD, World: RWCD) Access Control List: (IDENTIFIER=JAIL,ACCESS=READ)
If there are other directories on the VMS system disk that should be blocked from the user, or if the
JAIL user has their directory on that VMS system disk, then set security on that disk the same as the user's disk. In those cases, the access to system directories should be
READ access (only).
$ set security sys$sysdevice:sys0.dir - _$ /acl=(identifier=jail,access=read) $ set security sys$sysdevice:vms$common.dir - _$ /acl=(identifier=jail,access=read)
If some common shared files are on other disk volumes, then these same considerations must be given to those volumes also. This is common with large layered products such as databases.
Now we can block the
JAIL user's access from all top-level directories on that user's default disk. Do not block him from the Master File Directory. In this case, his default disk is referenced by the logical name
$ set file staff:*.dir;1 /exclude=000000.dir - _$ /acl=(identifier=jail,access=none)
Then make an exception for his own directory tree. In this case, we'll allow
JAILBIRD full access to all files in his directory tree. You may have reason to adjust this for specific files.
$ set file staff:jailbird.dir - _$ /acl=(identifier=jailbird,access=read+write+execute) $ set file staff:[jailbird...]*.dir;1 - _$ /acl=(identifier=jailbird,access=read+write+execute) $ set file staff:[jailbird...]*.*;* /exclude=*.dir;1 - _$ /acl=(identifier=jailbird,access=read+write+execute+delete)
Next, we provide for the security of any files created later in that directory tree:
$ set file staff:jailbird.dir - _$ /acl=(identifier=jailbird,options=default,access=read+write+execute+delete) $ set file staff:[jailbird...]*.dir;1 - _$ /acl=(identifier=jailbird,options=default,access=read+write+execute+delete)
View the results with the SHOW SECURITY command.
$ show security staff:jailbird.dir DSA2:JAILBIRD.DIR;1 object of class FILE Owner: [JAILBIRD] Protection: (System: RWE, Owner: RWE, Group: RE, World: E) Access Control List: (IDENTIFIER=[JAILBIRD],OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=[JAILBIRD],ACCESS=READ+WRITE+EXECUTE) (IDENTIFIER=JAIL,ACCESS=NONE)
Be absolutely sure that
JAILBIRD does not have any privileges which will override the security changes you have made. Basically, any ordinary users, including
JAILBIRD, must have only
NETMBX privileges – if carefully considered, it is possible to add some other privileges. Verify that the group portion of their UIC is greater than the system parameter
MAXSYSGROUP – the typical value for
MAXSYSGROUP is 10(octal) or 8(decimal), so the user's group UIC value must be greater than 8.
As with all changes, the sysadmin (you!) must thoroughly test the results. It's best to do this by building a
TESTER username/account and granting the
JAIL RID to that user (again with the
UAF> grant /id jail tester command), then you can login to that account and test for appropriate “locked-out” system responses and behaviors. If you discover undesired or surprising behavior, go back and look carefully at that disk volume's or directory's ACL protection, and fix it accordingly.
Once you're happy with this behavior with your
TESTER account, you can grant (and/or revoke) that
JAIL RID not only to user
JAILBIRD, but to any other current or future user account as needed – this approach is very general and flexible.