Updated: 11 December 1998 |
OpenVMS Guide to System Security
Previous | Contents | Index |
$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET/MANUAL |
%SET-I-SWINPRG The line you are currently logged over is becoming a DECnet line |
$ SET TERMINAL/PROTOCOL=DDCMP TTA0: |
$ RUN SYS$SYSTEM:NCP NCP> SET LINE TT-0-0 RECEIVE BUFFERS 4 - _ LINE SPEED 2400 STATE ON NCP> EXIT |
$ RUN SYS$SYSTEM:NCP NCP> SET LINE dev-c-u STATE OFF NCP> SET CIRCUIT dev-c-u STATE OFF NCP> EXIT |
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: $ |
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.
(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.
UAF> ADD/PROXY DEXTER::JACKSON SALES_READER/DEFAULT UAF> ADD/PROXY BANGOR::GOODWIN SALES_READER/DEFAULT |
$ 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 *.*;* |
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:
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 |
$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O,G,W) - _$ [000000]DESGN_PROJECTS.DIR |
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) |
[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) |
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.
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:
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
Users with execute access to the application gain access to the subsystem. Once in the subsystem, users can work with the data files and other resources of the subsystem.
A subsystem can have several identifiers because the resources consumed by the subsystem (the files, printers, and so forth) can be protected differently.
Possession of subsystem identifiers is limited to the period users are executing the application. Once the users exit from the application, the identifiers are removed from their process rights lists. Subsystem identifiers are also removed from the rights list whenever users enter a Ctrl/Y sequence or attempt to create a subprocess with the DCL command SPAWN. (In this respect, use of the subsystem identifiers is identical to the operation of images installed with privileges.)
The following identifiers are reserved for use in the security subsystem and should not be granted to any user:
Someone developing an application for a protected subsystem must link the application images without the /DEBUG or /TRACEBACK qualifiers.
Although this kind of subsystem often precludes the need for privilege, applications can be installed with privilege. For example, some applications may need the PRMGBL privilege to create permanent global sections, or they may need the AUDIT privilege to send security audit records to the system security audit log file. Compaq does discourage the installation of a protected subsystem application with privileges in the All category. This category includes such privileges as BYPASS, CMKRNL, and SYSPRV---privileges that allow a user to subvert OpenVMS access controls. See Table 8-2 for a list of OpenVMS privileges and Appendix A for a description of the privileges.
Subsystem designers need to generate a list of identifiers that are necessary for it to operate as intended. Then the designers approach you, as the security administrator, to make the preparations described in Section 13.5.
Previous | Next | Contents | Index |
Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal |
6346PRO_029.HTML
|