Document revision date: 19 July 1999

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:

1. Create identifiers for the subsystem, each with the Subsystem attribute. The Subsystem attribute empowers the identifier's holder to manage the subsystem.
2. Grant these subsystem identifiers with Subsystem attributes to the people who will serve as managers of the subsystem. This enables them to assign the subsystem identifier to the images comprising the subsystem.
3. Give the subsystem managers control access to application images. They need control access so they can add Subsystem ACEs to the image ACLs.
4. Give the subsystem managers control access to existing resources that are to be managed by the protected subsystem.
   Although subsystem managers may need control access to key system resources, the ACL on the objects limits their access rights to only those resources. This may not be as dangerous as installing an image with SYSPRV.

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

1. Use AUTHORIZE to create a subsystem identifier called MEMBERS_SUBSYSTEM. Notice that this identifier carries the Subsystem attribute.
2. Make Louis and Wu holders of the identifier so they can manage the subsystem.
3. Give Louis and Wu control access to the subsystem image 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].)

13.6 Building the Subsystem

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:

1. Create a Subsystem ACE containing the subsystem identifier in the ACLs of the application images. A Subsystem ACE has the following format:

   (SUBSYSTEM,{IDENTIFIER=identifier[,ATTRIBUTES=attributes]})

2. Grant access to the objects managed by the subsystem. You need to add an Identifier ACE to the ACL of the various objects belonging to the subsystem. Each Identifier ACE contains one of the subsystem identifiers in the following format:

   (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)

13.7 Enabling Protected Subsystems on a Trusted Volume

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.

13.8 Giving Users Access

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:

• They can create special identifiers for resources belonging to the subsystem that they do not want all members to access and add ACEs to these resources.
• They can use compound expressions in ACEs and thus grant access conditionally. For example, the following ACE grants access to MEMBERS_ADMIN when running MEMBERS_SUBSYSTEM but not to MEMBERS_ADMIN alone nor to other users holding the MEMBERS_SUBSYSTEM identifier:

  (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.

13.9 Example of a Protected Subsystem

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:

• It gives purchasing personnel the right to reference or record purchase orders in the company database, and it gives personnel in the accounts payable department the right to verify suppliers' invoices. Purchasing personnel with these tasks hold the SUPPLIERS_ORDERS identifier. Accounts payable personnel hold the ACCOUNTS_PAYABLE identifier. These employees run ORDERS.EXE to update the supplier information. The program stores data in ORDERS.DAT.
• It gives trusted administrators in the accounts payable department the right to update databases, calculate payments due, and print checks. (One printer, loaded with company checks, is used for this purpose.) These administrators hold the ACCOUNTS_PAYABLE identifier.
  The administrators run PAYMENTS.EXE to perform these tasks. The program records payments made in the data file PAYMENTS.DAT.

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.

1. The directory's protection code gives read, write, and execute access to users in the system and owner categories but no access to group or world users. Therefore, group and world users have to gain access through the ACL.
2. A Creator ACE ensures that users creating files in this directory have no special access to them. (See Section 8.8.1.2 for information on Creator ACEs.)
3. A Default Protection ACE denies group and world users access to files created in directory.
4. McGrey holds the subsystem identifier SUPPLIERS_SUBSYSTEM. This ACE gives her read, write, and control access so she can manage the subsystem directories and images.
5. Holders of the SUPPIERS_ORDERS identifier have execute access so they can access files in subdirectories.
6. Holders of the ACCOUNTS_PAYABLE identifier have execute access so they can access files in subdirectories.
7. Users holding any other identifiers have no access.
8. McGrey added the Default attribute to all Identifier ACEs and includes them here so all Identifier ACEs are propagated to subdirectory ACLs.

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. . . .

1. [SUPPLIERS_SUBSYSTEM.EXE] has the same protection code and ACL as the parent directory shown in Section 13.9.1. Subsystem users need to run programs stored in this directory.
2. [SUPPLIERS_SUBSYSTEM.LIB] has the same protection code but a more restrictive ACL because only the subsystem manager and the subsystem images need access.

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.

1. All subsystem users, those holding the SUPPLIERS_ORDERS or ACCOUNTS_PAYABLE identifier, can run ORDERS.EXE.
2. Only subsystem images and holders of the ACCOUNTS_PAYABLE identifier can run PAYMENTS.EXE.
3. The data files for the subsystem reside in [SUPPLIERS_SUBSYSTEM.LIB]. Only the subsystem images and McGrey can access them.

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)

13.9.5 Command Procedure for Building the Subsystem

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

	privacy and legal statement
6346PRO_030.HTML