![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
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. Digital 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.
Although an unprivileged user can build and manage a protected subsystem, you need to be involved at two points in the process: at the beginning to create the necessary identifiers for the subsystem and at the end to mount the volume with the protected subsystem.
You need to perform the following tasks:
The following example shows how you can set up identifiers and the necessary application access so that users can manage a membership list:
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/IDENTIFIER MEMBERS_SUBSYSTEM- (1) _UAF> /ATTRIBUTES=(SUBSYSTEM,RESOURCE) UAF> GRANT/IDENTIFIER MEMBERS_SUBSYSTEM - (2) _UAF> /ATTRIBUTES=(SUBSYSTEM,RESOURCE) LOUIS UAF> GRANT/IDENTIFIER MEMBERS_SUBSYSTEM - _UAF> /ATTRIBUTES=(SUBSYSTEM,RESOURCE) WU $ SET SECURITY/ACL=(IDENTIFIER=MEMBERS_SUBSYSTEM,- (3) _$ ACCESS=CONTROL) MEMBER_LIST.EXE
Note that you create the subsystem identifier MEMBERS_SUBSYSTEM with the Resource attribute. This allows disk space to be charged to the identifier MEMBERS_SUBSYSTEM and not the individuals accessing the subsystem. (When using the Resource attribute, be careful to set the appropriate ACLs on directories [see Section 8.8.1.2.3].)
Once managers of the subsystem have the appropriate identifiers and access rights as described in Section 13.5, they can add the necessary ACEs to a subsystem image. Two kinds of ACEs are necessary to construct a subsystem: the application image receives a Subsystem ACE, and the objects managed by the subsystem receive Identifier ACEs. Therefore, building a subsystem requires the following steps:
(SUBSYSTEM,{IDENTIFIER=identifier[,ATTRIBUTES=attributes]})
(IDENTIFIER=identifier, ACCESS=access-type[+...])
In the following example, the subsystem manager uses the DCL command SET SECURITY to associate the subsystem identifier with the images comprising the subsystem. First, the subsystem manager adds a Subsystem ACE with the identifier MEMBERS_SUBSYSTEM to the ACL of the application image MEMBER_LIST.EXE:
$ SET SECURITY/ACL=(SUBSYSTEM,IDENTIFIER=MEMBERS_SUBSYSTEM,- _$ ATTRIBUTES=RESOURCE) MEMBER_LIST.EXE
Then the subsystem manager adds an Identifier ACE with the subsystem identifier MEMBERS_SUBSYSTEM to the data files managed by the subsystem:
$ SET SECURITY/ACL=(IDENTIFIER=MEMBERS_SUBSYSTEM,- _$ ACCESS=READ+WRITE) MEMBER_DATA*.DAT
The DCL command SHOW SECURITY displays the security attributes of the files. For example:
$ SHOW SECURITY MEMBER_LIST.EXE
MEMBER_LIST.EXE object of class FILE
Owner: [STAFF]
Protection: (System: RWED, Owner: RWED, Group, World: RE)
Access Control List: (SUBSYSTEM,IDENTIFIER=MEMBERS_SUBSYSTEM,ATTRIBUTES=RESOURCE)
$ SHOW SECURITY MEMBER_DATA*.DAT
MEMBER_DATA_1.DAT object of class FILE
Owner: MEMBERS_SUBSYSTEM
Protection: (System: RWED, Owner: RWED, Group, World)
Access Control List: (IDENTIFIER=MEMBERS_SUBSYSTEM,ACCESS=READ+WRITE)
MEMBER_DATA_2.DAT object of class FILE
Owner: MEMBERS_SUBSYSTEM
Protection: (System: RWED, Owner: RWED, Group, World)
Access Control List: (IDENTIFIER=MEMBERS_SUBSYSTEM, ACCESS=READ+WRITE)
A person with the SECURITY privilege can enable subsystems on a volume by using the /SUBSYSTEM qualifier on the MOUNT command. By default, subsystems are enabled only on the system disk. For other disks, you need to enable subsystems every time a volume is mounted.
In the following example, a security administrator uses the MOUNT command with the /SUBSYSTEM qualifier to enable the processing of Subsystem ACEs on device DUA0. Assume that this disk contains the subsystem with the identifier MEMBERS_SUBSYSTEM.
$ MOUNT /SUBSYSTEM /SYSTEM DUA0: DOC WORK8
The processing of Subsystem ACEs can be turned on and off dynamically with the DCL command SET VOLUME /SUBSYSTEM. This command is especially useful for the system disk, which is not mounted using the MOUNT command.
Any person mounting a subsystem is responsible for knowing what is on the volume being mounted. Without this knowledge, an operator or system manager can inadvertently subvert system security. For example, it is easy for a user with privileges on one cluster to put an application holding a subsystem identifier on a volume and then take the volume to a naive operator on another cluster and request that it be mounted. Because the application holds an appropriate subsystem identifier, it feigns membership in a subsystem for which it is unauthorized. Therefore, mount volumes of only those users whom you trust, or thoroughly search a volume for Subsystem ACEs before you mount it with subsystems enabled.
All users with execute access to the main application image of the subsystem can use the data files and other objects under control of the subsystem if the subsystem allows the access. However, managers of the subsystem can restrict access to objects of the subsystem in the following ways:
(ID=MEMBERS_SUBSYSTEM+MEMBERS_ADMIN, ACCESS=READ+WRITE)
Remember that as long as users are executing the application image for the subsystem, their process rights list contains the subsystem identifier as well as their normal identifiers. However, as soon as users interrupt or exit from the application, their process rights list loses the subsystem identifier, and they lose access rights to the objects in the subsystem. Subsystem identifiers are not propagated by default when subprocesses are spawned.
R. D. Taylor Inc., a company specializing in building supplies, decides to set up a protected subsystem for its purchasing and accounts payable departments. Although the departments are in different parts of the company, they share a common database for recording purchases from suppliers.
When the company's inventory drops below the desired level, the purchasing department is directed to order required supplies. Purchasing personnel find suppliers (if necessary), assign purchase order numbers, and issue a purchase orders.
When the goods arrive, the receiving and quality control departments check the contents against what was ordered, ensure the goods meet quality standards, and put the goods into inventory. Once the shipment is processed, the information goes to the accounts payable department, which settles the invoices.
Administrators in the accounts payable department check the invoices against purchase orders and run a payments program to calculate the monies due to suppliers each week. Payments are recorded in a database, and checks are printed on a printer loaded with company checks.
Using the subsystem lets the company meet two objectives:
The company appoints one employee, McGrey, to design and manage the subsystem. Figure 13-2 illustrates the directory structure of the Taylor subsystem, and Example 13-1 shows the command procedure she wrote to implement it.
Figure 13-2 Directory Structure of the Taylor Company's Subsystem
McGrey implements a directory structure in which users can gain access to the subsystem only by holding an appropriate identifier: purchasing personnel hold the identifier SUPPLIERS_ORDERS, and the accounts payable administrators hold the identifier ACCOUNTS_PAYABLE. As subsystem manager, McGrey holds the identifier SUPPLIERS_SUBSYSTEM.
The top-level directory SUPPLIERS_SUBSYSTEM.DIR has the following protection:
$ DIRECTORY/SECURITY SYS$SYSDEVICE:[000000]SUPPLIERS_SUBSYSTEM.DIR
Directory SYS$SYSDEVICE:[000000]
SUPPLIERS_SUBSYSTEM.DIR;1
SUPPLIERS_SUBSYSTEM (RWE,RWE,,) (1)
(CREATOR,ACCESS=NONE) (2)
(DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:) (3)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL) (4)
(IDENTIFIER=SUPPLIERS_ORDERS,ACCESS=EXECUTE) (5)
(IDENTIFIER=ACCOUNTS_PAYABLE,ACCESS=EXECUTE) (6)
(IDENTIFIER=*,ACCESS=NONE) (7)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,OPTIONS=DEFAULT,ACCESS=READ+WRITE+CONTROL) (8)
(IDENTIFIER=SUPPLIERS_ORDERS,OPTIONS=DEFAULT,ACCESS=EXECUTE)
(IDENTIFIER=ACCOUNTS_PAYABLE,OPTIONS=DEFAULT,ACCESS=EXECUTE)
(IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE)
Total of 1 file.
The directory EXE.DIR has the same protection as the top-level directory because subsystem users need to access the subsystem images: ORDERS.EXE and PAYMENTS.EXE. The other directory, LIB.DIR, is more restricted because only the subsystem images and McGrey need access.
$ DIRECTORY/SECURITY SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM...]
Directory SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM]
EXE.DIR;1 SUPPLIERS_SUBSYSTEM (RWE,RWE,,) (1)
(CREATOR,ACCESS=NONE)
(DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=SUPPLIERS_ORDERS,ACCESS=EXECUTE)
(IDENTIFIER=ACCOUNTS_PAYABLE,ACCESS=EXECUTE)
(IDENTIFIER=*,ACCESS=NONE)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,OPTIONS=DEFAULT,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=SUPPLIERS_ORDERS,OPTIONS=DEFAULT,ACCESS=EXECUTE)
(IDENTIFIER=ACCOUNTS_PAYABLE,OPTIONS=DEFAULT,ACCESS=EXECUTE)
(IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE)
LIB.DIR;1 SUPPLIERS_SUBSYSTEM (RWE,RWE,,) (2)
(CREATOR,ACCESS=NONE)
(DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=*,ACCESS=NONE)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,OPTIONS=DEFAULT,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE)
Total of 2 files.
.
.
.
As the following listing shows, the necessary company personnel can access the subsystem's images, ORDERS.EXE and PAYMENTS.EXE, but only the images can update the data files:
Directory SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM.EXE]
ORDERS.EXE;1 SUPPLIERS_SUBSYSTEM (RWED,RWED,,) (1)
(SUBSYSTEM,IDENTIFIER=SUPPLIERS_SUBSYSTEM,ATTRIBUTES=RESOURCE)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=SUPPLIERS_ORDERS,ACCESS=EXECUTE)
(IDENTIFIER=ACCOUNTS_PAYABLE,ACCESS=EXECUTE)
(IDENTIFIER=*,ACCESS=NONE)
PAYMENTS.EXE;1 SUPPLIERS_SUBSYSTEM (RWED,RWED,,) (2)
(SUBSYSTEM,IDENTIFIER=SUPPLIERS_SUBSYSTEM,ATTRIBUTES=RESOURCE)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=ACCOUNTS_PAYABLE,ACCESS=EXECUTE)
(IDENTIFIER=*,ACCESS=NONE)
Total of 2 files.
Directory SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM.LIB] (3)
ORDERS.DAT;1 SUPPLIERS_SUBSYSTEM (RWED,RWED,,)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE)
(IDENTIFIER=*,ACCESS=NONE)
PAYMENTS.DAT;1 SUPPLIERS_SUBSYSTEM (RWED,RWED,,)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE)
(IDENTIFIER=*,ACCESS=NONE)
Total of 2 files.
Grand total of 3 directories, 6 files.
The print queue for checks needs equal protection. Access is restricted to trusted administrators because they are the only ones who hold both the subsystem and the ACCOUNTS_PAYABLE identifiers. The following display shows that the queue is protected in such a way that only the trusted administrators can queue jobs to the printer:
$ SHOW SECURITY/CLASS=QUEUE TTA1
TTA1 object of class QUEUE
Owner: [SYSTEM]
Protection: (System: M, Owner: D, Group, World)
Access Control List:
(IDENTIFIER=SUPPLIERS_SUBSYSTEM+ACCOUNTS_PAYABLE,-
ACCESS=READ+SUBMIT+MANAGE+DELETE)
(IDENTIFIER=*,ACCESS=NONE)
Example 13-1 shows the command procedure used to create the R. D. Taylor subsystem.
Example 13-1 Subsystem Command Procedure
$ SET NOON
$ OLD_PRIV = F$SETPRV("NOALL,SYSPRV,CMKRNL,OPER")
$ OLD_DEFAULT = F$ENVIRONMENT("DEFAULT")
$
$ ON CONTROL_Y THEN GOTO LEAVE
$
$ IF P1 .EQS. "REMOVE" THEN GOTO CLEANUP
$ IF P1 .EQS. "VERIFY" THEN SET VERIFY
$!
$! Create the subsystem identifier and the identifiers for personnel
$! performing two different tasks.
$!
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
ADD/IDENTIFIER SUPPLIERS_SUBSYSTEM/ATTRIBUTES=(RESOURCE,SUBSYSTEM)
ADD/IDENTIFIER SUPPLIERS_ORDERS
ADD/IDENTIFIER ACCOUNTS_PAYABLE
!
! Grant the subsystem identifier to the subsystem manager: McGrey.
!
GRANT/IDENTIFIER SUPPLIERS_SUBSYSTEM MCGREY/ATTRIBUTE=(RESOURCE,SUBSYSTEM)
$!
$! Set up the print queue.
$!
$ INITIALIZE/QUEUE/START TTA1
$ SET SECURITY/ACL=(-
(ID=SUPPLIERS_SUBSYSTEM+ACCOUNTS_PAYABLE,ACCESS=READ+SUBMIT+MANAGE+DELETE), -
(ID=*,ACCESS=NONE))/PROTECTION=(G,W)/CLASS=QUEUE TTA1:
$!
$! Create the directory root to hold the subsystem.
$!
$!
$! Assume that we logged in as McGrey.
$!
$ SET RIGHTS_LIST/ENABLE SUPPLIERS_SUBSYSTEM/ATTRIBUTE=(RESOURCE,SUBSYSTEM)
$ SET DEFAULT SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM]
$!
$! Create the directories for the images and the data files.
$!
$ CREATE/DIR [SUPPLIERS_SUBSYSTEM.EXE]/PROTECTION=(G,W)
$ CREATE/DIR [SUPPLIERS_SUBSYSTEM.LIB]/PROTECTION=(G,W)
$ SET SECURITY/ACL=((ID=SUPPLIERS_ORDERS,ACCESS=EXECUTE), -
(ID=ACCOUNTS_PAYABLE,ACCESS=EXECUTE), -
(ID=SUPPLIERS_ORDERS,OPTIONS=DEFAULT,ACCESS=EXECUTE), -
(ID=ACCOUNTS_PAYABLE,OPTIONS=DEFAULT,ACCESS=EXECUTE))/DELETE -
[SUPPLIERS_SUBSYSTEM]LIB.DIR
$!
$! Emulate the creation of the subsystem images.
$!
$ SET DEFAULT [.EXE]
$ CREATE ORDERS.MAR
.ENTRY START,0
$setpri_s pri=#0
10$: BRB 10$
ret
.END START
$ MACRO ORDERS
$ LINK ORDERS
$ SET SECURITY/PROTECTION=(W:RWED) ORDERS.MAR;*,.OBJ;*
$ DELETE ORDERS.MAR;*,.OBJ;*
$ COPY ORDERS.EXE PAYMENTS.EXE
$!
$! Apply the appropriate protection to the images.
$!
$ SET SECURITY/ACL=(ID=SUPPLIERS_ORDERS,ACCESS=EXECUTE)/DELETE PAYMENTS.EXE
$ SET SECURITY/ACL=(SUBSYSTEM,ID=SUPPLIERS_SUBSYSTEM,ATTRIBUTES=RESOURCE) ORDERS.EXE
$ SET SECURITY/ACL=(SUBSYSTEM,ID=SUPPLIERS_SUBSYSTEM,ATTRIBUTES=RESOURCE) PAYMENTS.EXE
$!
$! Create and protect the data files used by the applications.
$!
$ SET DEFAULT [-.LIB]
$ CREATE ORDERS.DAT
$ CREATE PAYMENTS.DAT
$ SET SECURITY/ACL=((ID=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE), -
(ID=*,ACCESS=NONE)) ORDERS.DAT
$ SET SECURITY/LIKE=(NAME=ORDERS.DAT) PAYMENTS.DAT
$!
$! Show the directory structure and the queue protection.
$!
$ SET DEFAULT 'OLD_DEFAULT'
$ DEFINE SYS$OUTPUT SUBSYS.LIS
$ DIRECTORY/SECURITY SYS$SYSDEVICE:[000000]SUPPLIERS_SUBSYSTEM.DIR
$ DIRECTORY/SECURITY SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM...]
$ SHOW SECURITY/CLASS=QUEUE TTA1
$ DEASSIGN SYS$OUTPUT
$
$ LEAVE:
$ IF P1 .EQS. "VERIFY" THEN SET NOVERIFY
$ SET DEFAULT 'OLD_DEFAULT'
$ SET PROC/PRIV=('OLD_PRIV')
$ EXIT
$
$ CLEANUP:
$ SET PROC/PRIV=BYPASS
$ SET DEFAULT SYS$SYSDEVICE:[000000]
$ DELETE [SUPPLIERS_SUBSYSTEM...]*.*.*
$ DELETE [SUPPLIERS_SUBSYSTEM]EXE.DIR;
$ DELETE [SUPPLIERS_SUBSYSTEM]LIB.DIR;
$ DELETE SUPPLIERS_SUBSYSTEM.DIR;
$ STOP/QUE/NEXT TTA1
$ DELETE/QUEUE TTA1
$ GOTO LEAVE
Privileges restrict the use of certain system functions to processes created on behalf of authorized users. These restrictions protect the integrity of the operating system's code, data, and resources and thus, the integrity of user service. Grant privileges to individual users only after carefully considering the following two factors:
Privileges fall into the following seven categories according to the damage that the user possessing them could cause the system:
A user's privileges are recorded in the user's UAF record in a 64-bit privilege mask. When a user logs in to the system, the user's privileges are stored in the header of the user's process. In this way, the user's privileges are passed on to the process created for the user. Users can use the DCL command SET PROCESS/PRIVILEGES to enable and disable privileges for which they are authorized and to further control the privileges available to the images they run. Moreover, any user with the SETPRV privilege can enable any privilege.
Table 8-2 lists the privileges by category and gives brief, general definitions of them. The following sections describe all privileges available on OpenVMS systems in detail; each section title identifies the privilege category (Normal, Devour, and so on). For each privilege, the appendix describes the capabilities granted by the privilege and the users who should receive them.
The ACNT privilege lets a process use the RUN (Process) command and the Create Process ($CREPRC) system service to create processes in which accounting is disabled. A process in which accounting is disabled is one whose resource usage is not logged in the current accounting file.
The ALLSPOOL privilege lets the user's process allocate a spooled device by executing the Allocate Device ($ALLOC) system service or by using the DCL command ALLOCATE.
The $ALLOC system service lets a process allocate or reserve a device for its exclusive use. A shareable mounted device cannot be allocated.
Grant this privilege only to users who need to perform logical or physical I/O operations to a spooled device. Ordinarily, the privilege of allocating a spooled device is granted only to symbionts.
The ALTPRI privilege allows the user's process to:
The base priority is increased by executing the Set Priority ($SETPRI) system service or the DCL command SET PROCESS/PRIORITY. As a rule, this system service lets a process set its own base priority or the base priority of another process. However, one process can set the priority of a second process only if one of the following conditions applies:
6346P023.HTM OSSG Documentation 22-NOV-1996 13:05:26.45
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.