OpenVMS Guide to System Security

Passwords are usually optional for point-to-point connections but are required for dynamic asynchronous connections. To provide for increased security when a remote node requests a dynamic asynchronous connection (which is normally maintained only for the duration of a telephone call), the node requesting the dynamic connection supplies a password, but the node receiving the login request is prevented from revealing a password to the requesting node. The network address, node name, and password of the requesting node has to match the local system's routing authorization data.

12.5.1 Establishing a Dynamic Asynchronous Connection

A dynamic asynchronous DECnet connection is a temporary connection between two nodes, normally over a telephone line through the use of modems. The line at each end of the connection can be switched from a terminal line to a dynamic asynchronous DECnet line. Configuration of dynamic asynchronous lines is performed automatically by DECnet during establishment of a dynamic connection. A dynamic asynchronous connection is normally maintained only for the duration of a telephone call.

Note
A dynamic asynchronous connection to an OpenVMS node can be initiated from any node that supports the DECnet asynchronous DDCMP protocol.

On an OpenVMS node, you have the option of performing steps 1 and 2 of the dynamic asynchronous connection process before you turn on the network at your node (step 3). The later steps of the process (starting with step 4) must occur when the line is being switched to DECnet.

Follow the steps outlined below to establish a dynamic asynchronous DECnet connection. This procedure assumes the local OpenVMS node is originating the connection and switching the terminal line on for DECnet use. The connection must be to an OpenVMS node on which you have an account with NETMBX privilege. The steps also indicate the actions that the system manager at the remote OpenVMS node must perform in order for the dynamic asynchronous DECnet link to be established successfully.

Log in to the SYSTEM account and enter the following commands interactively (or include them in the SYS$MANAGER:SYSTARTUP_VMS.COM command procedure before you boot the system). These commands load the asynchronous driver NODRIVER (NOA0) and install DYNSWITCH software on your system.
```
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN>  CONNECT NOA0/NOADAPTER
SYSGEN>  EXIT
$ INSTALL:=$SYS$SYSTEM:INSTALL
$ INSTALL/COMMAND
INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE - 
_ /PROTECT/HEADER/OPEN
INSTALL> EXIT
```
The system manager of the remote OpenVMS node must also enter these commands.
Additionally, the system manager at the remote OpenVMS node must enter the commands given below. These commands enable the use of virtual terminals for the terminal line that is to be switched, and set the DISCONNECT characteristic for the terminal line. (The virtual terminal capability permits the process to continue running if the physical terminal you are using becomes disconnected.)
```
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN>  CONNECT VTA0/NOADAPTER/DRIVER=TTDRIVER
SYSGEN>  EXIT
$ SET TERMINAL/EIGHT_BIT/PERMANENT/MODEM/DIALUP -
_$ /DISCONNECT device-name:
```
Device-name is the name of the terminal port to which the dynamic asynchronous connection is made.
You must establish the required transmit password at the originating end of the dynamic asynchronous dialup link. The transmit password is the password sent to the remote node during connection startup. Use NCP to enter a command to define the transmit password for the remote node. The password can contain one to eight alphanumeric characters and should not contain any spaces. Specify the following commands:
```
$ RUN SYS$SYSTEM:NCP
NCP> DEFINE NODE node-id TRANSMIT PASSWORD password
NCP> EXIT
```
Node-id is the name of the remote node with which your node is forming a connection.
In the following example, the node name of your local node is LOCALA, the transmit password is PASSA, and the remote node with which you are creating a dynamic asynchronous dialup link is REMOTC:
```
$ RUN SYS$SYSTEM:NCP
NCP> DEFINE NODE REMOTC TRANSMIT PASSWORD PASSA
NCP> EXIT
```
For each remote node with which you will create a dynamic asynchronous DECnet dialup link, you must define a transmit password in a separate command.
The system manager for the node at the other end of the connection must define that same password as a receive password for your node (the password expected to be received from your node). The remote system manager should also specify the parameter INBOUND ROUTER or INBOUND ENDNODE, to indicate the type of node (router or end node) that is expected to initiate the dynamic connection. These are the commands the remote manager should enter:
```
$ RUN SYS$SYSTEM:NCP
NCP> DEFINE NODE node-id - 
_ RECEIVE PASSWORD password INBOUND node-type
NCP> EXIT
```
For example, if your node LOCALA is an end node and your transmit password is PASSA, the manager at REMOTC should issue the following command:
```
$ RUN SYS$SYSTEM:NCP
NCP> DEFINE NODE LOCALA RECEIVE PASSWORD PASSA INBOUND ENDNODE
NCP> EXIT
```
DECnet must be running on both nodes for the remaining steps. If you have not already done so, turn on the network by entering the following command (and request that the remote system manager also do so):
```
$ @SYS$MANAGER:STARTNET
```
If the network was already running before you began the dynamic asynchronous connection procedure, enter these commands to cause the permanent database entry to be entered in the volatile database:
```
$ RUN SYS$SYSTEM:NCP
NCP> SET NODE node-id ALL
NCP> EXIT
```
The remaining steps can be performed by any OpenVMS user with NETMBX privilege. Log in to your local OpenVMS system, and enter the following DCL command on your terminal to cause your process to function as a terminal emulator (which makes the remote terminal appear to be a local terminal connection):
```
SET HOST/DTE device-name: 
```
Device-name is the name of your local terminal port that is connected to the modem. If both systems use modems ) with autodial capabilities, you can optionally include the /DIAL qualifier on the SET HOST/DTE command to cause automatic dialing of the modem on the remote node, as follows:
```
SET HOST/DTE/DIAL=number device-name: 
```
If you are not using automatic dialing, dial in to the remote node manually.
Once the dialup connection is made and you receive the remote OpenVMS system welcome message, log in to your account on the remote node.
While logged in to your account on the remote node, enter the following command to cause the line to be switched to a DECnet line automatically:
```
$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET
```
The following message indicates that the DECnet link is being established:
```
%REM-S-END - control returned to local-nodename:: 
$ 
```
To check whether the communications link has come up, specify the following command on the local system:
```
$ RUN SYS$SYSTEM:NCP
NCP> SHOW KNOWN CIRCUITS
NCP> EXIT
```
The resulting display should list a circuit identified by the mnemonic TT or TX, depending on the asynchronous device installed on the line, and indicate that it is in the ON state.
When the DCL prompt appears on your terminal screen, you can begin to communicate with the remote node over the asynchronous DECnet connection.
As an alternative to switching the terminal line to a DECnet line automatically (as described in previous step 7), you can switch the line manually. If you originate a dynamic connection to an OpenVMS node from a node that is not running OpenVMS software, manual switching is required; from an OpenVMS system, it is optional. If you are originating the connection from a node that is not running OpenVMS software, follow system-specific procedures to log in to the remote OpenVMS node by means of terminal emulation.
Once you are logged in to the remote node, two steps are required to perform manual switching:
1. Using your account on the remote OpenVMS node, specify the SET TERMINAL command described in step 7, but add the /MANUAL qualifier:
```
$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET/MANUAL
```
  You receive the following message from the remote node indicating the remote system is switching its line to DECnet use:
```
%SET-I-SWINPRG The line you are currently logged over is becoming 
               a DECnet line 
```
2. You should exit from the terminal emulator and switch your line manually to a DECnet line. The procedure depends on the specific operating system on which you are logged in.
  The following example shows how an OpenVMS user originating a dynamic connection would perform this procedure:
  - Exit from the terminal emulator by pressing the backslash (\) key and the Ctrl key simultaneously on your OpenVMS system.
  - Enter the following command to switch your terminal line to a DECnet line manually:
```
$ SET TERMINAL/PROTOCOL=DDCMP TTA0:
```
    TTA0 is the name of the terminal port on the local node.
  - Enter NCP commands to turn on the line and circuit connected to your terminal port TTA0 manually, as in the following example:
```
$ RUN SYS$SYSTEM:NCP
NCP> SET LINE TT-0-0 RECEIVE BUFFERS 4 - 
_ LINE SPEED 2400 STATE ON
NCP> EXIT
```
    Asynchronous DECnet is then started on the local OpenVMS node.
3. You can terminate the dynamic asynchronous link in one of two ways:
  - Break the telephone connection.
  - Run NCP and turn off either the asynchronous line or circuit. The two commands you can use are as follows:
```
$ RUN SYS$SYSTEM:NCP
NCP> SET LINE dev-c-u STATE OFF
NCP> SET CIRCUIT dev-c-u STATE OFF
NCP> EXIT
```
    If either of the above NCP commands is entered at the remote node, the line returns to terminal mode immediately. If the command is entered at the local (originating) OpenVMS node, the remote line and circuit remain on for approximately four minutes and then the line returns to terminal mode.
  Figure 12-2 shows the establishment of a dynamic asynchronous connection. The commands that must be entered at each end of the connection are shown in Example 12-3.
  Figure 12-2 A Typical Dynamic Asynchronous Connection
  
  Example 12-3 Sample Commands for a Dynamic Asynchronous Connection
```
Commands issued at both the local OpenVMS node (LOCALA) and the remote OpenVMS node 
(REMOTC): 
```
```
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN>  CONNECT NOA0/NOADAPTER
SYSGEN>  EXIT
$ INSTALL:=$SYS$SYSTEM:INSTALL
$ INSTALL/COMMAND
INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE/PROTECT/HEADER/OPEN
INSTALL> EXIT
```
```
Commands issued at the remote node (REMOTC): 
```
```
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN>  CONNECT VTA0/NOADAPTER/DRIVER=TTDRIVER
SYSGEN>  EXIT
$ SET TERMINAL/EIGHT_BIT/PERMANENT/MODEM/DIALUP/DISCONNECT TTB0:
$ RUN SYS$SYSTEM:NCP
NCP> DEFINE NODE LOCALA RECEIVE PASSWORD PASSA INBOUND ENDNODE
NCP> SET NODE LOCALA ALL  
NCP> EXIT
```
```
Commands issued at the local node (LOCALA): 
```
```
$ RUN SYS$SYSTEM:NCP
NCP> DEFINE NODE REMOTC TRANSMIT PASSWORD PASSA
NCP> SET NODE REMOTC ALL  
NCP> EXIT
$ SET HOST/DTE/DIAL=8556543 TTA0:
```
```
! After dialing in automatically to REMOTC, log in to your account on REMOTC. 
```
```
$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET
%REM-S-END - control returned to LOCALA:
$
```
  12.6 Sharing Files in a Network
  
  Discourage users from sharing passwords and changing file and directory protection codes to grant the world category read or execute access. Grant BYPASS or READALL privilege cautiously.
  The easiest way to share files on an occasional basis in a network environment is through the Mail utility. You mail the file to the intended recipient; there is no exposure of passwords, and the file is not made accessible to other users. However, there is the disadvantage of having to ask the file owner and wait for their response every time you want access. For an ongoing activity involving frequent access to shared files, it is better to set up proxy accounts and ACLs on the directories and files.
  12.6.1 Using the Mail Utility
  
  The easiest way for a user to transfer a text file to another user is to invoke the Mail utility (MAIL) and to send the user a copy of the file. This method is reasonably secure, because passwords need not be revealed and the original protection of the file is not changed. The receiving user simply includes a new file name with the MAIL command EXTRACT/NOHEADER to place a copy in the user's own directory. The copy automatically acquires the user's default protection. The user then uses the MAIL command DELETE to remove the copy from the mail file.
  12.6.2 Setting Up Accounts for Local and Remote Users
  
  A network manager may need to admit a number of users from outside nodes into a directory on the local node for a specific task. Therefore, you create a proxy account and add the proxy access to admit the outsiders into that one account (see Section 12.3.2.3). If there are local users who need to share the files in this account's directory, then you provide that access and protect the files from outsiders by placing ACLs on the directory and files.
  Consider a situation where a corporation needs a central repository for sales update information that is accessible to employees throughout the corporation.
  1. The security administrator at the node where the files will reside (BNORD) creates the special account SALES_READER. The SALES_READER account is set up as a captive account with mail disabled. The default directory is [SALESINFO], which has the following default protection code:
```
(S:RWED,O:RWED,G:R,W) 
```
    Note that this protection code permits users in the same group as SALES_READER on the home node BNORD to read the files. Furthermore, only the users in the system category or the owner category, or those who have privileges that give them such access, can update the files in the directory. ACLs are used to further define the access, as described in step 3.
  2. The security administrator uses the AUTHORIZE command ADD/PROXY to add the proxy access for the outside users. For example, to extend proxy access to user Jackson on node DEXTER and user Goodwin on node BANGOR, the commands would be as follows:
```
UAF> ADD/PROXY DEXTER::JACKSON  SALES_READER/DEFAULT
UAF> ADD/PROXY BANGOR::GOODWIN  SALES_READER/DEFAULT
```
  3. If later it becomes clear that other users at the home node BNORD need access and they do not belong to the same group as SALES_READER, ACLs could be added to the files in the directory [SALESINFO]. For example, suppose R. Grant needs control access to all the files and J. Martinez needs read access to all the files. The following two DCL commands would define the ACL for the directory and then propagate it to all existing files:
```
$ SET SECURITY/ACL=-
_$ ((IDENTIFIER=R_GRANT,ACCESS=CONTROL),-
_$ (IDENTIFIER=J_MARTINEZ,ACCESS=READ))-
_$ ((IDENTIFIER=R_GRANT,OPTIONS=DEFAULT,ACCESS=CONTROL),-
_$ (IDENTIFIER=J_MARTINEZ,OPTIONS=DEFAULT,ACCESS=READ))-
_$ [000000]SALESINFO.DIR
$ SET SECURITY/DEFAULT *.*;*
```
  12.6.3 Admitting Remote Users to Multiple Accounts
  
  When a small number of outside users need access, for differing reasons, to files requiring special protection, set up access to multiple proxy accounts, and apply extensive ACLs.
  For example, a large corporation with many branch offices might choose to establish several proxy accounts for specific file-sharing purposes. Assume the central office wants to grant two key users from its two nodes in the eastern region read and write access to the project files for code name LEVIGRAY and read-only access to the BETSEYHARLOW project files. At the same time, there are three users from the western region who need read access to those LEVIGRAY files and require read and write access to the BETSEYHARLOW files. Only two users from the central office will have full access rights to the LEVIGRAY files, and two other users from headquarters will have full access rights to the BETSEYHARLOW files. For working purposes, the situation could be represented in tabular form, as shown in Example 12-4.
  Example 12-4 Protected File Sharing in a Network
```
             Access Requirements to CENTRL::PROJ:[DESGN_PROJECTS] 
                       Owned by [DESIGNERS,MGR] 
Users & Nodes 
 
                  Subdirectory LEVI         Subdirectory BETSEY 
                    Project Files             Project Files 
                     LEVIGRAY*.*              BETSEYHARLOW*.* 
 
FRISCO::ALBION            R                        RW 
FRISCO::ELTON             R                        RW 
LA::IRVING                R                        RW 
 
CENTRL::DIANTHA          RWED                     NONE 
CENTRL::BRITTANIA        RWED                     NONE 
CENTRL::ALBERT           NONE                     RWED 
CENTRL::DELIA            NONE                     RWED 
 
BOS::AYLMER               RW                       R 
WASH::LAVINA              RW                       R 
```
  The following solution uses five proxy accounts in addition to the four local accounts on node CENTRL, plus ACLs on the directory, subdirectories, and files:
  1. The security administrator at headquarters uses AUTHORIZE to create new proxy accounts on node CENTRL for the remote users Albion, Elton, Irving, Aylmer, and Lavina. These accounts should be captive, disallow mail, and be restricted to network access only. The accounts are even restricted to a subset of DCL through CLI tables. The default directory should be [DESGN_PROJECTS] for each user. The manager decides it makes sense to put them into the DESIGNERS group to match their proposed uses of the files.
    Presumably, accounts already exist for users Diantha, Brittania, Albert, and Delia. They need not necessarily belong to the same group. They will be informed which device and directory to use for their work.
  2. The next step is to add the proxy records to the network proxy authorization file with the following AUTHORIZE commands:
```
UAF> ADD/PROXY FRISCO::ALBION ALBION/DEFAULT
UAF> ADD/PROXY FRISCO::ELTON ELTON/DEFAULT
UAF> ADD/PROXY LA::IRVING IRVING/DEFAULT
UAF> ADD/PROXY BOS::AYLMER AYLMER/DEFAULT
UAF> ADD/PROXY WASH::LAVINA LAVINA/DEFAULT
```
  3. The security administrator at node CENTRL places an ACL on the top-level directory for [DESGN_PROJECTS] with the following DCL command:
```
$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O,G,W) -
_$ [000000]DESGN_PROJECTS.DIR
```
    This ensures that no one outside of the system category of users can gain any UIC-based access to the files in the directory or any of the subdirectories unless they possess the BYPASS privilege. In fact, this restriction applies to those five users in the group DESIGNERS as well. The plan is for all files to possess ACLs that will admit the select group of users. It is desirable to propagate this protection code to all the files in this directory and its subdirectories. (The ACLs that will be placed on the files for further protection will take precedence when one of these users actually seeks access to a file.)
  4. Two subdirectories are created in [DESGN_PROJECTS]:
    - [DESGN_PROJECTS.LEVI]
    - [DESGN_PROJECTS.BETSEY]
  5. The security administrator uses the ACL editor to place the following additional ACEs in the ACL for the top-level directory:
```
 
DESGN_PROJECTS.DIR 
 
(IDENTIFIER=DIANTHA,OPTIONS=PROTECTED,ACCESS=EXECUTE) 
(IDENTIFIER=BRITTANIA,OPTIONS=PROTECTED,ACCESS=EXECUTE) 
(IDENTIFIER=ALBERT,OPTIONS=PROTECTED,ACCESS=EXECUTE) 
(IDENTIFIER=DELIA,OPTIONS=PROTECTED,ACCESS=EXECUTE) 
(IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACESS=EXECUTE) 
(IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=EXECUTE) 
(IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=EXECUTE) 
(IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=EXECUTE) 
(IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=EXECUTE) 
 
```
    These protected ACEs ensure that only the select nine users can access the top-level directory. Because no one receives write or delete access to the top directory through the ACL, the directory and subdirectories are generally protected from deletion and renaming of files. (Of course, the system category of user obtains write and delete access through the UIC-based protection.)
  6. Next, the security administrator creates ACLs on the subdirectories. The ACEs that are required are shown for their respective subdirectories:
```
 
[DESGN_PROJECTS]LEVI.DIR 
 
(IDENTIFIER=DIANTHA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL) 
(IDENTIFIER=DIANTHA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=BRITTANIA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL) 
(IDENTIFIER=BRITTANIA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=AYLMER,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=LAVINA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=READ) 
(IDENTIFIER=ALBION,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ) 
(IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=READ) 
(IDENTIFIER=ELTON,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ) 
(IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=READ) 
(IDENTIFIER=IRVING,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ) 
 
 
 
[DESGN_PROJECTS]BETSEY.DIR 
 
(IDENTIFIER=ALBERT,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL) 
(IDENTIFIER=ALBERT,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=DELIA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL) 
(IDENTIFIER=DELIA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) 
(IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=ALBION,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=ELTON,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=IRVING,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) 
(IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACCESS=READ) 
(IDENTIFIER=AYLMER,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ) 
(IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=READ) 
(IDENTIFIER=LAVINA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ) 
 
```
    Note that both preceding ACLs include two ACEs for each identifier. The first ACE controls the access to the subdirectory. It denies delete access for the protection of the subdirectory and is not propagated to all the files created in the subdirectory. The second ACE for each identifier will automatically propagate to all files added to their respective subdirectories because of the inclusion of the Default attribute. Furthermore, the Protected attribute ensures that all the ACEs are protected from deletion except by specific action.
    At this point, all the groundwork has been completed. Over time, files are added to the subdirectories. Thus, when the user Lavina in Washington enters the following DCL command, the file LEVIGRAYMEM3.MEM is printed at node WASH:
```
$ COPY CENTRL::LEVIGRAYMEM3.MEM LP: 
```
    However, if user Lavina tries to edit this file, the attempt fails because user Lavina is denied write access through the ACL.
    If there were many users involved in this scheme, it would soon become worthwhile to grant additional identifiers to the users. For example, each user who would be allowed read access to the files in the LEVI subdirectory might be given the identifier LEVI_READER, and so forth. The ACLs could then be shortened.
    
    Chapter 13
    Using Protected Subsystems
    
    For the most part, the OpenVMS operating system bases its security controls on user identity. Protected objects, such as files and devices, are accessible to individual users or groups of users. If an object's ACL or protection code allows a user the necessary access, then the user can make use of that object by using any available software. (See Chapter 4 for a description of OpenVMS object protection.)
    In a protected subsystem, an application protected by normal access controls serves as a gatekeeper to objects belonging to the subsystem. Users have no access to the subsystem's objects unless they execute the application serving as gatekeeper. Once users run the application, their process rights list acquires identifiers giving them access to objects owned by the subsystem. As soon as they exit from the application, these identifiers and, therefore, the users' access rights to objects are taken away.
    This chapter describes protected subsystems and explains how to build them.
    13.1 Advantages of Protected Subsystems
    
    Using protected subsystems offers several advantages:
    - With protected subsystems, you have a mechanism to provide conditional access to data that is not available with traditional OpenVMS access controls. Traditionally, you give users privileges to bypass protection codes or access control lists (ACLs). In giving these privileges, however, you grant users a wide class of access. (Refer to Appendix A for information on the power different privileges carry.) Protected subsystems avoid extensive privilege use by individual users.
    - Protected subsystems give you an alternative to installing images with privilege. Writing a secure privileged image requires skill, and failures can compromise system security.
    - Protected subsystems give you an alternative to creating protected shareable images (also called user-written system services).
    - Protected subsystems make system management easier because unprivileged users can manage them without much assistance from you. See Section 13.5 for details on system management requirements.
    13.2 Applications for Protected Subsystems
    
    Protected subsystems have many applications, from databases to common system management situations.
    One use for a protected subsystem might be a group membership list that you want to make available to all group members. The list contains the names, addresses, personnel numbers, and interests of group members. When the membership list is set up as a protected subsystem, all members of the group can read selected information and update specific types of information.
    A protected subsystem might also solve the problem of confidential information being sent to printers in public areas. You could write an application to filter data for sensitive information. Confidential files would be sent to printers in restricted areas, while public files would be sent to any available printer. Any user with execute access to the application could use the restricted printers, but only through the protected subsystem.
    13.3 How Protected Subsystems Work
    
    A protected subsystem is an application that, when run, causes the process running the application to be granted one or more identifiers. For as long as a user runs the subsystem, the user's process rights list carries these additional identifiers. Figure 13-1 shows how a protected subsystem adds a second level of access control to traditional controls.
    Figure 13-1 How Protected Subsystems Differ from Normal Access Control
    
    Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]
```
  6346P022.HTM
  OSSG Documentation
  22-NOV-1996 13:05:24.63
```
    Copyright © Digital Equipment Corporation 1996. All Rights Reserved.
    
    Legal

OpenVMS Guide to System Security

12.5.1 Establishing a Dynamic Asynchronous Connection

12.6 Sharing Files in a Network

12.6.1 Using the Mail Utility

12.6.2 Setting Up Accounts for Local and Remote Users

12.6.3 Admitting Remote Users to Multiple Accounts

Chapter 13Using Protected Subsystems

13.1 Advantages of Protected Subsystems

13.2 Applications for Protected Subsystems

13.3 How Protected Subsystems Work

Chapter 13
Using Protected Subsystems