GUARDS - protection for objects

GUARDS (Generally Usable Access contRol aDministration System) makes it possible to set up different protection mechanisms for the objects of BS2000. GUARDS provides containers – the guards – in which the required protective mechanisms are entered. Access to the objects is then monitored on the basis of these entries.

To help readers come to a better understanding of GUARDS, the protection mechanisms which are entered in the guards and the way monitoring is performed, it is necessary to differentiate between the following key areas:

1. Administration of the container function of the guards.

2. Administration of the content of guards.

3. Assignment of guards to the objects they protect

Administration of the container function of the guards

This administration is performed independently of the content and purpose of the individual guards. The commands and macros of the guards management system are available for the administration of the individual guards.

For more detailed information, refer to section "Guards administration".

Administration of the content of guards

Independently of the content stored in a guard, a variety of instances are responsible for the administration of this content. For the purposes of this discussion, it is irrelevant which objects are protected by the guards and how this protection is implemented.

The following guard contents exist:

• Access conditions

  These are conditions which globally allow access, globally prohibit access or allow access under certain circumstances to certain subject types (users, groups, all others). There is no limit to the number of guards containing access conditions that can be created.

  • The guards administration system manages these guards under the guard type STDAC.

  • The administration of the data contents of these guards is the responsibility of the default administration system which makes use of the corresponding commands and macros.

  For more detailed information, refer to section "Data access control and system access control".

• Default access rules

  These rules determine which objects should, by default, be supplied with certain protection attributes. There is no limit to the number of guards with default protection rules that can be created.

  • The guards administration system manages these guards under the guard type DEFAULTP.

  • The administration of the data contents of these DEFAULTP guards is the responsibility of the default administration system which makes use of the corresponding commands and macros.

  For more detailed information, refer to " section Default protection".

  • Protection attributes

    Used when it is necessary to define special default protection attributes.

    There is no limit to the number of guards with default values for protection attributes that can be created.

    • The guards administration system manages these guards under the guard type DEFPATTR.

    • The administration of the data contents of these guards is the responsibility of the default administration system which makes use of the corresponding commands and macros.

  For more detailed information, refer to section "Data access control and system access control".

  • User ID and user group lists (for system administration only)

    Here it is possible to specify definitions for unique object name assignment throughout a pubset. For example, the definition: USER-ID=HUGO may permit the unique identification of all objects named $HUGO.OBJ* throughout the entire pubset. Any number of guards can be created with lists of user IDs and user groups.

    • The guards administration system manages these guards under the guard type DEFPUID.

    • The administration of the data contents of these guards is the responsibility of the default administration system which makes use of the corresponding commands and macros.

  For more detailed information, refer to section "Definition of user and group IDs for path names".

  • Co-owner protection rules

    These are rules which define which objects may, under certain conditions, be coadministered by certain subject types (users, groups, all others). There is no limit to the number of guards with co-owner protection rules which can be created.

    • The guards administration system manages these guards under the guard type COOWNERP.

    • The administration of the data contents of these guards is the responsibility of the co-owner administration system which makes use of the corresponding commands and macros.

  For more detailed information, refer to section "Co-owner protection".

• Assignment of guards to the objects they protect

The protection mechanisms are defined in the individual guards independently of the objects which they protect. In order for these to take effect, it is necessary to specify which guards are to be used and what tasks they are to perform. A distinction is made between three different approaches:

• Direct link to the protected object

  The object management system which confers GUARDS protection on its objects provides special command or interface operands. These are used to link the objects which are to be protected with the guards which contain the required protection mechanisms.

  For example, the DMS object management system provides the operand PROTECTION=(GUARDS=()) in the /CREATE-FILE command for the protection of DMS files. This operand can be used to assign guard names for read, write and execute protection.

  For more detailed information on the direct linking of guards and protected objects, refer to section "Data access control and system access control".

• Assignment of a predefined guard name

  A protection mechanism is activated by the existence of a guard with a fixed, predefined name.

  For example, rules concerning the co-ownership of certain DMS files become effective because they are entered in a file named SYS.UCF.

  For more detailed information on the use of predefined guard names, refer to the sections "Default protection" and "Co-owner protection".

• Indirect link to the protected object.

  Guards which contain rules for a protection mechanism also contain a reference to another guard.

  For example, a guard may contain rules defining the objects to which certain protection attributes are to be assigned by default. These rules refer to a further guard in which these attribute values are defined.

  For more detailed information on the indirect linking of guards and protected objects, refer to the sections "Default protection" and "Co-owner protection".

The table below indicates which object management systems offer GUARDS protection for which of their objects and the guard types which are evaluated in order to provide this protection.

Object management	Object	Protection mechanism
		Data access  control	System  access  control	Default  protection	Co-owner  protection
DMS (file management  system)	Files	STDAC		DEFAULTP DEFPATTR DEFPUID	COOWNERP STDAC
	Storage classes	STDAC
LMS (Library  Management System)	Library members	STDAC
	Library with the  protection  mechanism  Coowner protection				COOWNERP STDAC
HSMS (Hierarchical  Storage Management  System)	HSMS management  classes	STDAC
JVS (Job Variable  System)	Job variables	STDAC		DEFAULTP DEFPATTR DEFPUID	COOWNERP STDAC
FITC (Fast Intertask  Communication)	Ports	STDAC
SRPM  (System Resources  and Privileges  Management)	Group assignments		STDAC
	Terminal sets		STDAC
	Interactive access to  a user ID		STDAC
	Batch access to a  user ID		STDAC
	POSIX rlogin access  to a user ID		STDAC
	POSIX remote  access to a user ID		STDAC
	Network dialog  access to a user ID		STDAC

Table 9: Object management systems and the associated objects

The corresponding linkage mechanisms are described in the following sections:

• "System access control" and subsections "Restrictions on access via terminal sets" and "Access control with guards"

•  "Data access control and system access control"

• " Default protection " 

• " Co-owner protection

• For the significance of the guard types, refer to the table "Guard types and their meanings" in "GUARDS protection mechanisms - an overview".

At the technical level, the overall protection functionality which can be specified in the individual guards is distributed across three subsystems

GUARDS

This subsystem comprises the management of the container function of all the guards (GUARDS administration) and the management of the contents of all guards of type STDAC (default condition administration).

GUARDDEF

This subsystem comprises both the default protection administration and support for attribute and object path administration.

GUARDCOO

This subsystem is responsible for co-owner protection administration.

In addition, there is a utility:

GUARDS-SAVE

This utility is used to save all the guards or individual, specified guards by selecting them in the current guards catalog and writing them to a file. The reverse process is also possible: guards can be restored by transferring them from this file back into the current guards catalog.

This description is structured as follows:

• The description of the GUARDS administration can be found in the sections

  • "Guards administration"

  • "GUARDS administration"

• The individual protection mechanisms which can be specified within a guard are described in "GUARDS protection mechanisms - an overview" as well as in the following subsections

  • • "System access control"

  •  "Data access control and system access control"

  • "Default protection" 

  • "Co-owner protection"

  • Notes on the use of the utilities GUARDS-SAVE can be found in the section "GUARDS-SAVE utility routine".

  • The GUARDS commands and macros are discussed as part of the description of the GUARDS functions.

    • The description of the GUARDS commands starts on "Functional overview".

    • The description of the GUARDS macros starts on "Functional overview".

    • Notes on the SDF metasyntax can be found the “Commands” manual [4].