guide to logical security

Guide to LogicalSecurity

DPS

7000/XTA

NO

VASC

ALE

7000

Security

REFERENCE47 A2 17UG 00

DPS7000/XTANOVASCALE 7000

Guide to LogicalSecurity

Security

February 1996

BULL CEDOC

357 AVENUE PATTON

B.P.20845

49008 ANGERS CEDEX 01

FRANCE

REFERENCE47 A2 17UG 00

The following copyright notice protects this book under Copyright laws which prohibit such actions as, but notlimited to, copying, distributing, modifying, and making derivative works.

Copyright Bull SAS 1996

Printed in France

Suggestions and criticisms concerning the form, content, and presentation of thisbook are invited. A form is provided at the end of this book for this purpose.

To order additional copies of this book or other Bull Technical Publications, youare invited to use the Ordering Form also provided at the end of this book.

Trademarks and Acknowledgements

We acknowledge the right of proprietors of trademarks mentioned in this book.

Intel® and Itanium® are registered trademarks of Intel Corporation.

Windows® and Microsoft® software are registered trademarks of Microsoft Corporation.

UNIX® is a registered trademark in the United States of America and other countries licensed exclusively throughthe Open Group.

Linux® is a registered trademark of Linus Torvalds.

The information in this document is subject to change without notice. Bull will not be liable for errors containedherein, or for incidental or consequential damages in connection with the use of this material.

47 A2 17UG Rev00 iii

Preface

PURPOSE OF THIS MANUAL

This document provides a synthesis of the rules (Implementation and Operations) toadopt in order that the security level of a GCOS 7 site corresponds as closely as possibleto the needs of each GCOS 7 customer.

The system considered for this synthesis is:

GCOS 7-V7 TS 7254 (Transactional TDS + IOF +...), on which the productSECUR'ACCESS V2.2 may be operational.

The following type of presentation is used in this document to summarize and highlightimportant advice concerning security:

You are advised to:

Take precaution XXX in order to avoid problem YYY.

Utilities, products and commands used to implement GCOS 7 security are mentionedbriefly in this document, in the form of references to other GCOS 7 documents. (In anIOF environment, Help texts can also be consulted.) The bibliography in this Prefacecontains a list of the documents referred to.

Organizational Aspects

The practical application of the security rules described in this document implies efficientcoordination between the various contributors to security implementation. The rules witha global scope (that apply to a site, to all the users, to all the applications) must be appliedin a coherent manner.

GCOS 7 Guide to Logical Security

iv 47 A2 17UG Rev00

It is important that human means are used to verify that security rules are appliedcorrectly. The techniques involved in verification by human means are not described inthis document, as they are not specific to GCOS 7. They consist mainly of a priori ora posteriori checks on all operations.

A priori checks A program, a command (or a similar element) is re-read by atleast one person, other than the author, before beingintroduced into the system.

A posteriori checks The consequences of a program, a command (or a similarelement), are analyzed by at least one person, other than theauthor, (by consulting traces, listings, the system status, etc.).

Limits Of This Document

This document covers only 'logical security', which prevents deliberate damage frombeing perpetrated when information processing tools are used (for example: usurping theidentity of a database administrator and altering the database).

The following aspects are not dealt with in this document:

• Physical protection of GCOS 7 sites against deliberate or natural damage (for example,a bomb attack or an earthquake)

• Prevention of errors that are not a result of a deliberate attempt to damage the system(for example: a programming error, a manipulation error, a hardware failure)

• Methods to adopt if the protective measures have failed (for example: a strategy forsaving and restoring data).

However, the rules described in this document may, of course, go beyond 'logical security'and apply to the above-mentioned contexts. For example, the file tracing actions relatingto security can be used to find the origin of a manipulation error and facilitate itscorrection.

INTENDED READERS

This document directly concerns the persons responsible for the security of a GCOS 7site. It also concerns, indirectly, the following persons (for the rules that apply to eachprofile):

• Those who are responsible for the installation, maintenance and administration of thesystem

• Those who are responsible for the creation, validation, installation, maintenance andadministration of the applications

• End users of the applications.

GCOS 7 functions, and the persons responsible for them, are presented in tabular form inChapter 2.

Preface

47 A2 17UG Rev00 v

Sound knowledge of the general concepts of GCOS 7 is required of the readers , as wellas basic notions of 'logical security' (see Chapter 1).

STRUCTURE OF THIS DOCUMENT

Chapter 1 Logical Security - A RecallA brief overview of security concepts that are standard ininformation technology.

Chapter 2 Description of Security Functions in a GCOS 7 Contex tStandard security concepts applied to GCOS 7.

Chapter 3 Installation of GCOS 7 and Basic Security ComponentsInstalling: security controls at configuration, file accesscontrols, AUDIT 7, SECUR'ACCESS.

Chapter 4 GCOS 7 Access Controls (Without SECUR'ACCESS)Identification and authentication of the user, passwordmanagement, the catalog security base.

Chapter 5 GCOS 7 Access Controls (With SECUR'ACCESS)Identification and authentication of the user, passwordmanagement, relationship between the catalog security baseand the SECUR'ACCESS security base.

Chapter 6 Protection of Data in a GCOS 7 ContextChecking access rights to files and volumes.


vi 47 A2 17UG Rev00

BIBLIOGRAPHY

Security Evaluation

The following documents can be referred to for security evaluation of operating systems:

Trusted Computer Systems Evaluation CriteriaDOD 5200.28-STD, Department of Defense, U.S.A. December 1985

Information Technology Security Evaluation CriteriaISBN 92-826-3005-6, ITSEC V1.2, June 1991

GCOS 7 Documents

ARM User's Guide............................................................................................47 A2 11USSystem Installation Configuration and Updating Guide....................................47 A2 18USAUDIT 7 Administrator's Manual ......................................................................47 A2 40USSystem Administrator's Manual........................................................................47 A2 41USSystem Operator's Guide.................................................................................47 A2 47US

UFT User's Guide ........................................................................................... 47 A2 13UCDJP User's Guide............................................................................................ 47 A2 14UCNetworks Overview ......................................................................................... 47 A2 92UCNetworks Generation ...................................................................................... 47 A2 93UC

Data Management Utilities User's Guide .........................................................47 A2 26UFCatalog Management User's Guide .................................................................47 A2 35UFAdministering the Storage Manager.................................................................47 A2 36UF

GCL Programmer's Manual.............................................................................. 47 A2 36UJIOF Terminal User's Reference Manual (Part 1).............................................. 47 A2 38UJIOF Terminal User's Reference Manual (Part 2).............................................. 47 A2 39UJIOF Terminal User's Reference Manual (Part 3).............................................. 47 A2 40UJ

SECUR'ACCESS Security Administrator's Guide............................................47 A3 01BDSECUR'ACCESS Delegate Administrator's Manual ........................................47 A3 02BDSECUR'ACCESS Programming and Implementation Guide ...........................47 A3 04BDSECUR'ACCESS Customer Service Bulletin......................................................94-017EN

TDS COBOL Programmer's Guide ..................................................................47 A2 21UTTDS Administrator's Guide...............................................................................47 A2 32UT

47 A2 17UG Rev00 vii

Table of Contents

1. Logical Security - A Recall .............................................................................. 1-1

2. Description of Security Functions in a GCOS 7 Context ................... 2-1

2.1 IDENTIFICATION AND AUTHENTICATION .............................................................. 2-3

2.1.1 Description of Identification and Authentication in a GCOS 7 Context ............... 2-32.1.1.1 GCOS 7 Authentication Without SECUR'ACCESS .................................................... 2-52.1.1.2 GCOS 7 Authentication With SECUR'ACCESS, But Without a Smart Card

(Using a Password) ..................................................................................................... 2-52.1.1.3 GCOS 7 Authentication With SECUR'ACCESS and a Smart Card ............................ 2-7

2.1.2 GCOS 7 Authentication for Services Other Than IOF and TDS ............................ 2-82.1.3 Identification and Authentication in the Case of Delegated Identity

(Batch Processing) ................................................................................................... 2-9

2.2 ACCESS CONTROLS ................................................................................................ 2-10

2.2.1 Control on Access to Cataloged Applications ....................................................... 2-112.2.2 Control on Access to Transactions (Authority Mask) ........................................... 2-122.2.3 Access Control Through a SECUR'ACCESS Control Point .................................. 2-132.2.4 Control on Access to Files ....................................................................................... 2-132.2.5 Control on Access to Memory Resources and CPU (ARM) .................................. 2-142.2.6 Control on Access to Available Disk or Tape Space

(QUOTA, 'Volume OWNER' and 'Volume Name OWNER') .................................... 2-142.2.7 Control on Access to GCL and JCL Commands .................................................... 2-152.2.7.1 The Mandatory Startup Mechanism ............................................................................ 2-152.2.7.2 Checks on the Type of IOF User................................................................................. 2-152.2.7.3 Control on Access to GCL Commands ....................................................................... 2-15

2.2.8 Other Types of Access Control ................................................................................ 2-16

Logical Security in GCOS 7

viii 47 A2 17UG Rev00

2.3 OBJECT REUSE ........................................................................................................ 2-17

2.3.1 Object Reuse Related to a TDS Application ........................................................... 2-172.3.2 Object Reuse Related to a Disk File ........................................................................ 2-182.3.3 Reuse of a Disk Volume ........................................................................................... 2-192.3.4 Reuse of a Tape File or Volume ............................................................................... 2-19

2.4 ACCOUNTABILITY AND AUDIT ................................................................................ 2-20

2.4.1 Accountability for Events ......................................................................................... 2-202.4.2 Security Audit ............................................................................................................ 2-21

3. Installation of GCOS 7 and Basic Security Components .................. 3-1

3.1 INSTALLATION OF GCOS 7 ..................................................................................... 3-2

3.2 INSTALLATION OF GCOS 7 SECURITY FUNCTIONS ............................................ 3-2

3.2.1 Installation of Configuration Controls .................................................................... 3-23.2.2 Installation of File Access Controls ........................................................................ 3-33.2.3 Creation, Deletion, or Modification of 'Standard' Users ........................................ 3-43.2.4 Control on Access to Debugging Transactions ..................................................... 3-5

3.3 INSTALLATION OF AUDIT 7 ..................................................................................... 3-6

3.4 STARTING TELECOMMUNICATIONS ...................................................................... 3-7

3.5 INSTALLATION OF SECUR'ACCESS ....................................................................... 3-7

3.6 VERIFICATION OF THE BASIC SECURITY FUNCTIONS ....................................... 3-8

3.7 CREATION AND ADMINISTRATION OF A TDS APPLICATION .............................. 3-9

3.7.1 Preparation of TDS (TP7PREP) ................................................................................ 3-93.7.2 TDS Generation Options (TP7GEN) ........................................................................ 3-103.7.2.1 Contents of the "TDS SECTION" ................................................................................ 3-103.7.2.2 Contents of the "TRANSACTION SECTION" ............................................................. 3-11

3.7.3 Contents of Transactions ......................................................................................... 3-113.7.4 Security Audit of the Application ............................................................................. 3-113.7.5 Validation of the Application .................................................................................... 3-12

Table of Contents

47 A2 17UG Rev00 ix

4. GCOS 7 Access Controls (Without SECUR'ACCESS) ......................... 4-1

4.1 INTRODUCTION......................................................................................................... 4-1

4.1.1 Aim of this Chapter ................................................................................................... 4-14.1.2 The Security Base ..................................................................................................... 4-1

4.2 CONNECTION CONTROLS ....................................................................................... 4-2

4.2.1 Identification .............................................................................................................. 4-24.2.2 Authentication ........................................................................................................... 4-24.2.3 Control on Access to Applications .......................................................................... 4-3

4.3 PASSWORD MANAGEMENT .................................................................................... 4-4

4.4 APPLICATION CONTROL (ON ACCESS TO TRANSACTIONS) ............................. 4-5

4.5 THE CATALOG SECURITY BASE ............................................................................ 4-6

4.5.1 Administration of the Catalog Security Base ......................................................... 4-64.5.2 Responsibilities Defined in the Catalog Security Base ......................................... 4-64.5.2.1 System Administrator .................................................................................................. 4-64.5.2.2 AUDIT 7 Administrator ................................................................................................ 4-74.5.2.3 Main Operator ............................................................................................................. 4-74.5.2.4 TDS Master Operator.................................................................................................. 4-7

4.6 INSTALLATION OF ACCESS CONTROLS ............................................................... 4-8

5. SECUR'ACCESS .................................................................................................. 5-1

5.1 INTRODUCTION......................................................................................................... 5-1

5.1.1 Aim of this Chapter ................................................................................................... 5-15.1.2 The Catalog and SECUR'ACCESS Security Bases ................................................ 5-25.1.3 Installation Categories .............................................................................................. 5-25.1.3.1 GCOS 7 With SECUR'ACCESS ................................................................................. 5-25.1.3.2 TDS and IOF Connection Controls With SECUR'ACCESS........................................ 5-25.1.3.3 TDS Application Services............................................................................................ 5-3

5.2 CONNECTION CONTROLS WITH SECUR'ACCESS ............................................... 5-4


x 47 A2 17UG Rev00

5.2.1 Connection Controls for a Terminal ........................................................................ 5-45.2.1.1 Identification ................................................................................................................ 5-45.2.1.2 Authentication.............................................................................................................. 5-55.2.1.3 Specific SECUR'ACCESS Connection Controls ......................................................... 5-5

5.2.2 Connection Controls for the Main Console ............................................................ 5-75.2.3 Controls on Connections via Pass-Through .......................................................... 5-75.2.4 Connection Controls When Using Applications Other Than IOF and TDS ......... 5-75.2.5 Password Management and Handling of Authentication Errors .......................... 5-8

5.3 APPLICATION CONTROLS (SECUR'ACCESS PROGRAMMATIC INTERFACE,ACCESS TO TRANSACTIONS) ................................................................................. 5-9

5.3.1 Crossing SECUR'ACCESS Control Points ............................................................. 5-95.3.1.1 Security Functions Initiated by the Programmatic Interface 'Control Point'................. 5-95.3.1.2 Description of Access Control (Control of Main Rights and Locks) ............................ 5-10

5.3.2 Insertion of SECUR'ACCESS Control Points in a TDS Application ..................... 5-105.3.3 Control on Access to Transactions ......................................................................... 5-11

5.4 TYPES OF DATA IN THE SECURITY BASES .......................................................... 5-12

5.4.1 Data in the Catalog Base, Visible in SECUR'ACCESS Mode ................................ 5-125.4.1.1 Identification Data and Rules for Sharing Personal Data............................................ 5-125.4.1.2 Definition of Personal Data.......................................................................................... 5-12

5.4.2 Security Data Related to TDS Transactions ........................................................... 5-135.4.3 The SECUR'ACCESS Base ....................................................................................... 5-135.4.3.1 Content and Structure of the SECUR'ACCESS Base................................................. 5-135.4.3.2 Identification Data........................................................................................................ 5-13

5.4.4 Security Data Specific to SECUR'ACCESS Mode: Permanent Data ..................... 5-145.4.4.1 Data Attached to a Site ............................................................................................... 5-145.4.4.2 Personal Data (Attached to the User Identifier) .......................................................... 5-145.4.4.3 Personal Data (Attached to the Project Identifier)....................................................... 5-155.4.4.4 Data Attached to an IOF or TDS Managed Service (Via the Application Name) ........ 5-155.4.4.5 Data that is Invariable After Installation....................................................................... 5-15

5.4.5 Data in the SECUR'ACCESS Base: Operational Data ............................................ 5-165.4.6 Complementary Files Specific to SECUR'ACCESS Mode ..................................... 5-16

5.5 ADMINISTRATION OF THE SECURITY BASES ...................................................... 5-17

5.5.1 Relationships Between the Catalog Base and the SECUR'ACCESS Base .......... 5-175.5.1.1 Consistent Installation of the Bases ............................................................................ 5-175.5.1.2 Consistent Evolution of the Bases: Management of User Entities .............................. 5-175.5.1.3 Independent Evolution of the Bases............................................................................ 5-175.5.1.4 Management of the Project and Application Entities................................................... 5-185.5.1.5 Management of the Billing and Station Entities........................................................... 5-18

5.5.2 The Different Classes of SECUR'ACCESS Administrators ................................... 5-185.5.3 The Roles of SECUR'ACCESS Administrators and Users .................................... 5-19

Table of Contents

47 A2 17UG Rev00 xi

5.5.3.1 Security Administrators ............................................................................................... 5-195.5.3.2 The SECUR'ACCESS SECADMIN Administrator....................................................... 5-195.5.3.3 SECUR'ACCESS Delegate Administrators (Optional) ................................................ 5-195.5.3.4 End Users.................................................................................................................... 5-205.5.3.5 Internal Passive Users (or Pseudo-Users).................................................................. 5-205.5.3.6 Internal Fictitious Users............................................................................................... 5-20

5.6 STARTING GCOS 7 OPERATIONS WITH SECUR'ACCESS ................................... 5-21

5.6.1 The GCOS 7 STARTUP Sequence ........................................................................... 5-215.6.2 The Two Jobs Started by the Regular STARTUP Sequence ................................. 5-215.6.3 The Status of GCOS 7 After the STARTUP Sequence ........................................... 5-215.6.4 Anomalies During the STARTUP Sequence ........................................................... 5-225.6.5 Starting the First Operation (The SECUR'ACCESS Base is Empty) ..................... 5-22

6. Protection of Data in a GCOS 7 Context ................................................... 6-1

6.1 CATALOGED FILE ACCESS RIGHTS ...................................................................... 6-1

6.1.1 Protection Mechanism (Access Control) ................................................................ 6-16.1.1.1 Principle of the Access Control Mechanism................................................................ 6-16.1.1.2 Files, Catalogs and Generation Groups...................................................................... 6-26.1.1.3 Directory Access Rights, Hierarchical Propagation..................................................... 6-26.1.1.4 File Links ..................................................................................................................... 6-3

6.1.2 Access Rights Hierarchy .......................................................................................... 6-36.1.3 Files, Catalogs and Generation Groups .................................................................. 6-46.1.4 Directories .................................................................................................................. 6-56.1.5 Access Rights to Cataloged Files ............................................................................ 6-6

6.2 VOLUME ACCESS RIGHTS ...................................................................................... 6-14

6.3 CHECKING ACCESS RIGHTS ................................................................................... 6-16

6.3.1 Checks Made at ASSIGN Time ................................................................................. 6-166.3.2 Checks Made by File Level Processors and Utilities ............................................. 6-186.3.3 Checks Made by Volume Level Processors and Utilities ...................................... 6-23

6.4 FILE SECURITY PROCEDURES FOR THE SYSTEM ADMINISTRATOR ............... 6-25

6.4.1 Setting Up Access Rights on the System ............................................................... 6-256.4.1.1 Initialising Access Rights on the System..................................................................... 6-256.4.1.2 Setting Access Rights on the Site Catalog.................................................................. 6-266.4.1.3 Setting Access Rights on the SYS Files (If Necessary) .............................................. 6-266.4.1.4 Setting OWNER Access on Master Directories .......................................................... 6-276.4.1.5 Setting Access Rights on a Private Catalog................................................................ 6-276.4.1.6 Setting Access Rights on a Volume ............................................................................ 6-28


xii 47 A2 17UG Rev00

6.4.2 Returning to an Unprotected System ...................................................................... 6-286.4.3 Changing the Owner of a Private Catalog .............................................................. 6-296.4.4 Deleting a Project that is the Owner of a Private Catalog ..................................... 6-316.4.5 Saving a Protected Site Catalog to an Unprotected Site Catalog ........................ 6-31

Table of Contents

47 A2 17UG Rev00 xiii

Glossary ................................................................................................................................... g-1

Index .................................................................................................................................... i-1


xiv 47 A2 17UG Rev00

Illustrations

Figures

2-1 Logical Security in a GCOS 7 Context ........................................................................ 2-2

Tables6-1 Summary of Access Right Controls ............................................................................ 6-176-2 Access Rights Required by File Level Processors (GCL) (1/3) .................................. 6-196-2 Access Rights Required by File Level Processors (GCL) (2/3) .................................. 6-206-2 Access Rights Required by File Level Processors (GCL) (3/3) .................................. 6-216-3 Access Rights Required by File Level Utilities (JCL) .................................................. 6-226-4 Access Rights Required by the Volume Level Processors (GCL) .............................. 6-236-5 Access Rights Required by the Volume Level Utilities (JCL) ...................................... 6-24

Table of Contents

47 A2 17UG Rev00 xv

47 A2 17UG Rev00 1-1

1. Logical Security - A Recall

A brief reminder of 'logical security' is given below. For full details, refer to the followingdocuments:

• Trusted Computer Systems Evaluation CriteriaDOD 5200.28-STD, Department of Defense, U.S.A. December 1985

• Information Technology Security Evaluation CriteriaISBN 92-826-3005-6, ITSEC V1.2, June 1991

The 'logical security' of information systems is traditionally split into three areas:

ConfidentialityThe faculty for an information system to limit the disclosure of information to authorizedpersons (for example, protection against the theft of files).

IntegrityThe possibility of preventing ill-intentioned destruction or modification of information (forexample, deleting files).

AvailabilityThe guarantee that the information system will always be capable of providing the servicerequired by its users (for example, protection against the saturation of an interactiveapplication with the intention of producing unacceptable response times).

A certain number of functions can be implemented on an operating system in order toguarantee 'logical security'. These functions are traditionally divided into the followingcategories:

Identification and AuthenticationAn information system must be able to establish the identity, and verify the claimedidentity, of the person using a particular service (for example, who is accessing data ormanaging the system and its applications).

Access ControlAccess to protected objects in an information system must be restricted to authorizedpersons. These objects may vary according to the user's needs. (For example, theobject may be a complete file that contains a confidential letter, or it may be a record in afile where each record contains confidential information on a different person.)


1-2 47 A2 17UG Rev00

Object ReuseWhen a protected object is no longer used (for example a deleted file, or a deletedrecord), the information system must ensure that the content of this object, that has beenlogically deleted, cannot be retrieved (for example, by using a disk exploring tool, or byreusing the same disk space for a new file).

Accountability and AuditThe accountability function consists of collecting and recording security-related events(such as: a user's access to an information system, management of access rights, asystem administrator's actions).

The audit function searches the entire collection and analyses specific selected events.

47 A2 17UG Rev00 2-1

2. Description of Security Functions in aGCOS 7 Context

This chapter presents the various GCOS 7 security functions that are available, andindicates, for each function, the actions to take and the rules to observe in order toimplement these functions.

The choice of a security function depends on the needs of each specific operation. Forexample, in a purely TDS environment it is not always necessary to control access to files.This chapter indicates, for each security function, the context in which the function can beused.

The implementation of GCOS 7 security functions may imply actions on:

• Basic GCOS 7 functions (for example, controlling access rights to files)

• GCOS 7 associated with a complementary product such as SECUR'ACCESS(for example, identification and authentication using smart cards)

• A GCOS 7 product such as AUDIT 7 (AUDIT 7 provides accountability functions)

• An application "cooperating" with GCOS 7 (for example, a TDS application thatincludes controls on access rights to individual records of a file).

The various participants that play a role in security operations are:

System Administrator }AUDIT 7 Administrator }Main Operator }IOF End User } Their roles are described in Chapter 4.TDS Master Operator }TDS End User }Developer of a secure application }

Security Administrator }SECUR'ACCESS SECADMIN Administrator }Delegate Administrator } Their roles are described in Chapter 5.TDS-SA7 Master Operator }TDS End User }IOF End User }

Developer of an application using SECUR'ACCESS


2-2 47 A2 17UG Rev00

T D SIO FO ther

ca ta logedapplica tions

R em otesystem

D P S 7000

D A T A

T erm ina l access

A dm in is tra tiv eF unctions

S E C U R 'A C C E S S

A ccess R ights

S ite andpriva te

cata logs

R esourcecontro l too ls

A R M , Q U O TA

Im puta tion too lA U D IT 7

D ata des tructionfunc tion

E R A S E option

S YS T E M A C C E S SC O N T R O LSP assw ord identifica tion

P assw ord authentica tion

P ro jec t < ---> U serrestric tions

A P P LIC A T IO NA C C E S S C O N T R O LS

- A ccess contro l to ca ta loged app lica tions

- A ccess contro l to transactions

- S E C U R 'A C C E S S contro l po in t

- e tc.

D A T A A C C E S SC O N T R O LS

- V o lum e access righ ts

- Q U O TA contro l

- F ile access righ ts (O w ner, R ead, W rite )

- D ata destruction

C P U A C C E S SC O N T R O LS

G C O S 7 s itecata log contro ls

S iteca ta log

S A 7database

Figure 2-1. Logical Security in a GCOS 7 Context

Description of Security Functions in a GCOS 7 Context

47 A2 17UG Rev00 2-3

2.1 IDENTIFICATION AND AUTHENTICATION

Summary of Identification and Authentication Functions

Function Aim Person Responsible

GCOS 7 authentication withoutSECUR'ACCESS

To controlaccess to IOFand TDS

- System Administrator

GCOS 7 authentication withSECUR'ACCESS, but without a smartcard (using a password)

GCOS 7 authentication withSECUR'ACCESS and with a smartcard

To controlaccess to IOFand TDS

- Security Administrator- SECUR'ACCESS SECADMIN Administrator (in the case of an incident)- Delegate Administrator- Developer of a secure application

GCOS 7 authentication for servicesother than IOF and TDS

To controlaccess to DJP,UFT, .....

Each case must be considered separately

Identification and authentication whenthere is delegation of identity (in batchprocessing)

To control thesubmission ofbatch jobs

- System Administrator- Main Operator- IOF End User

2.1.1 Description of Identification and Authentication in a GCOS 7 Context

Identification and authentication are basic security functions that enable trustworthyaccess controls and audits to be performed.

The implementation of these functions is imperative for guaranteeing the security of anoperating system.

The identification function is based on the couple of identifiers (Project, User). Aconnected subject is identified by the complete identification:

Project.User

The authentication function can apply three types of control when IOF or TDS services arebeing accessed. They are listed below in increasing order of security and are described inthe following paragraphs.

• GCOS 7 authentication without SECUR'ACCESS

• GCOS 7 authentication with SECUR'ACCESS, but without a smart card (using apassword)


2-4 47 A2 17UG Rev00

• GCOS 7 authentication with SECUR'ACCESS and with a smart card

Access controls to services other than IOF and TDS are dealt with in a specific paragraph.

The authentication function is executed at the beginning of the dialog between the userand the information system. In the last two of the above cases (with SECUR'ACCESS),and in TDS only, the function may be re-executed during the dialog, in order to ensurethat the user has not changed. (For example, a connected terminal that becomes freemay be borrowed by an ill-intentioned user.)

If the user's identity is not repeatedly authenticated, the only guarantees of identity thatremain are physical protection, or the application of strict rules (for example, systematicdisconnection of the terminal user).

The GCOS 7 identification/authentication mechanism (with or without SECUR'ACCESS)does not apply to certain operations performed at the Main console(s), (for example,system initialization). Consequently, physical protection and operating rules should beimplemented for the system and the Main console(s) (from protecting a site with lockeddoors to keeping a paper trace of all dialogues on the Main console(s)).

The following special rules also apply to RMS (Remote Maintenance Service), theconnection available to Bull technical support via the switched telecommunicationsnetwork.

The connection to RMS:

• must be explicitly authorized from the main console

• may be made secure by an "electronic box" that guarantees the security of theconnection between the remote maintenance center and the customer.

• does not undergo SECUR'ACCESS security checks

You are advised to:

- Limit the use of the Main console(s) to a minimum, and physicallyprotect equipment.

- Use specific remote maintenance control features.

- Systematically keep a trace (paper, for example) of all dialogues onthe Main console(s), and of remote maintenance activity.

Certain applications (see Chapter 4) can request that the GCOS 7 authenticationmechanism (without SECUR'ACCESS) be disabled. The configuration option'CHKPW=YES' may be used to prohibit this possibility. See the SECOPT command ofthe CONFIG utility in the System Installation, Configuration, and Updating Guide.

You are advised to:

Use the configuration option: CHKPW=YES


47 A2 17UG Rev00 2-5

The case of identity delegation will be dealt with at the end of this chapter. Identitydelegation means, in the present context, 'sending a batch job on another person's behalf'(for example: submission of a batch job by the operator).

2.1.1.1 GCOS 7 Authentication Without SECUR'ACCESS

This authentication mode uses the "simple" password mechanism, without:

• controlling unsuccessful attempts• controlling the complexity of a password• controlling the frequency of the password's renewal• periodic re-authentication of the user's identity• etc.

The resistance level of this authentication mechanism is relatively low and is not advisablein a "hostile" environment (for example, where it is possible to connect from a publicnetwork and where the data on the site is attractive for a potential pirate).

Access control is performed by comparing the references supplied by the user whenconnecting (User name, password...) with the references contained in the GCOS 7catalog (the SITE.CATALOG file). These references in the GCOS 7 catalog are managed(creation, modification..., of a user, a project...) by the IOF utility MAINTAIN_CATALOG.

See Chapter 4 of this document for a more complete description of this authenticationmode. See also the System Administrator's Manual for details of MAINTAIN_CATALOGcommands.

This mode of authentication is systematically implemented at each installation of GCOS 7.The main installation phases and the special precautions to take are briefly described inChapter 3 of this document. See also the:

System Installation, Configuration and Updating GuideSystem Administrator's Manual

2.1.1.2 GCOS 7 Authentication With SECUR'ACCESS, But Without a Smart Card(Using a Password)

This authentication mode uses an "advanced" password mechanism, with functions suchas:

• limiting the number of consecutive unsuccessful attempts• forcing the user to choose a complex password• forcing the user to renew the password periodically• etc.

The resistance level of this authentication mechanism is relatively high, and difficult toimprove on without an additional checking system such as a smart card reader. (Seenext paragraph.)

The resistance of this mechanism depends on the values given to security parameters bysite administrators (number of consecutive unsuccessful attempts accepted, minimumlength of passwords, etc.).


2-6 47 A2 17UG Rev00

You are advised to:

- Define authentication parameters in such a way that the probability ofdiscovering a password after several successive attempts is highlyunlikely. (Take into account the complexity imposed on the password,and the time required for an attempt.)

- Track down attempts of this kind using the accountability and audittools. See 'Accountability and Audit' later in this chapter.

This authentication mode also offers management facilities such as the possibility ofdistributing security responsibilities between several administrators, or creating historyfiles that are available for consultation.

Access control is performed by comparing the references (user name, password...)supplied by the user when connecting with the references (user name, password...)contained in the GCOS 7 catalog (SITE.CATALOG file) and the SECUR'ACCESS base(SA7.* files).

Identification/authentication may be repeated during a TDS session. This mode ofoperating must be programmed into TDS applications. It is also possible, withSECUR'ACCESS, to identify/authenticate, successively, several users of the sameconnection, provided that this mode of functioning is authorized on the site (with the"MODE CONTROL USER" option). For example, in the case of a terminal that is freelyavailable to everyone on the site and remains permanently connected.

You are advised:

In TDS:- to repeat the authentication operation frequently, particularly if theconnection is made from a machine that is not physically protected.(For example, a terminal situated in a place without access controls.) Ifrepeated authentication is not available, the application should beprogrammed or installed in such a way that the terminal isautomatically disconnected after a given period of idleness.

- to authorize multiple-user TDS sessions only if strictly necessary.The existence of two identifications (one attached to the connectionand one attached to the current user) adds to the complexity of theapplication and of the audit analysis.

In IOF:- to give strict directives (not to leave a connected terminalunsupervised), and to protect, physically, the equipment allowingaccess to the IOF service.

- to use, if necessary, the function that disconnects an IOF terminalautomatically, after a given period of idleness.


47 A2 17UG Rev00 2-7

Management of Security References

• Certain references in the GCOS 7 catalog are managed (creation, modification..., of aproject) by the IOF utility MAINTAIN_CATALOG.

• References relating to individual users are managed (creation, modification..., of auser) by a specific administrative interface (connected to a TDS that updates theSECUR'ACCESS base and, in certain cases, the GCOS 7 catalog).

• Specific SECUR'ACCESS information is also managed by the specific administrativeinterface (connected to a TDS that updates the SECUR'ACCESS base).

Refer to Chapter 5 of this document for a more complete description of this authenticationmode and:

• The System Administrator's Manual, for a description of the IOF utilityMAINTAIN_CATALOG.

• The SECUR'ACCESS Security Administrator's Guide, for a description of theSECUR'ACCESS operating mode and administrative interface.

• Chapter 3 of this document, the SECUR'ACCESS Customer Service Bulletin and theSECUR'ACCESS Security Administrator's Guide for the particular precautions to takewhen installing this mode of authentication.

2.1.1.3 GCOS 7 Authentication With SECUR'ACCESS and a Smart Card

This authentication mode combines the "advanced" password mechanism, as describedin the previous paragraph, with the use of a smart card. Possession of a smart cardprovides supplementary authentication of a user's identity and supplementary securitywhen using a network. (The equivalent of the password used in this authentication modeis not directly transmitted over the telecommunication line and cannot, therefore, bediscovered).

Apart from the specific requirements of the smart card reader, the utilization,administration and installation of this mode of authentication remain the same as in theprevious paragraph.


2-8 47 A2 17UG Rev00

2.1.2 GCOS 7 Authentication for Services Other Than IOF and TDS

Authentication modes that use SECUR'ACCESS are designed specifically for checking ona person's access from a remote installation (of the terminal type).

For products such as UFT (Unified File Transfer) or DJP (Distributed Job Processing),where the dialog is between one machine and another, the authentication mode withoutSECUR'ACCESS applies. (See above).

As this authentication mode is less resistant than the mode using SECUR'ACCESS, therules to apply are as follows:

• Refer to the product documentation for specific identification and authenticationprocedures. For example,

- DJP User's Guide,- UFT User's Guide.

• Isolate the users of these products (individual projects and/or individual rights from aSECUR'ACCESS point of view) so that, under the identity of these users, it isimpossible to access other services (such as IOF or TDS). See "Access Control onCataloged Applications" later in this document.

You are advised to:

Install and manage your site in such a way that users controlled bySECUR'ACCESS (IOF and TDS users) are distinct from those whoare not (users of UFT, DJP...).

NOTE:

UFT and DJP are given here as examples. The following products should also betaken into consideration:

- XCP1 and XCP2 transactional cooperative protocols (See the TDSAdministrator's Guide)

- ISO sessions

- Network administration tools (DSAC). See the following documents:Network Overview Network Generation

- OPEN 7

- etc.


47 A2 17UG Rev00 2-9

2.1.3 Identification and Authentication in the Case of Delegated Identity(Batch Processing)

This case of identification corresponds to the processing of batch jobs. There is noauthentication of identity insofar as the user, under certain conditions (if he is an IOF EndUser on an unprotected system, or a Main Operator on a protected system), can submit abatch job on behalf of another person.

However, it is possible to prevent a batch job from being submitted on behalf of a user ofthe SYSADMIN project, via a configuration option (CONFIG utility, SADMOPT command,CHKJSADM parameter). See Chapter 3 of this document and the System Installation,Configuration and Updating Guide.

NOTE: The terms 'protected system/unprotected system' refer to the protection of filesthrough the access right mechanism. (The subject of access rights to files isdealt with in Chapter 3.)

You are advised to:

• Install and manage your site in such a way that users controlled by SECUR'ACCESS(IOF and TDS users) are distinct from those who are not (users of UFT, DJP...).

• Install the system in 'protected' mode, and use the configuration options that prohibit:

- batch jobs from being submitted on behalf of a user of the SYSADMIN project (seeChapter 3)

- UFT, DJP... from being used without explicit authorization (see Chapters 3 and 4).

• Check, by using accountability and audit tools (see 'Accountability and Audit' later inthis chapter) that the Main Operators do not abuse of their right to send a batch job onbehalf of another person.

Refer to the following documents:• System Administrator's Manual, for the right to send batch jobs• System Operator's Guide, for a description of the batch mechanism.


2-10 47 A2 17UG Rev00

2.2 ACCESS CONTROLS

Summary of Access Controls


Control on access to catalogedapplications

To control theright to accessapplications suchas IOF, TDS,DJP, UFT...


Control on access to transactions(authority mask)

To control rightswithin a TDSapplication

- System Administrator- TDS Master Operator

Access control through a'SECUR'ACCESS control point'

To control rightswithin a TDSapplication

- Security Administrator- Delegate Administrator- Developer of a secure application

Control on access to files(and control on access to the userjournal)

To controlaccess to fileswhen using IOF,batch mode,UFT, DJP,...(but not usuallywhen using TDS)

- System Administrator- IOF End User

Control on access to memoryresources and CPU (using ARM)

To controlaccess toresources whenusing IOF,batch mode, TDS

Control on access to available spaceon disk or tape(using QUOTA, 'Volume OWNER')

To controlaccess toresources whenusing IOF,batch mode, TDS


Control on access to commands viathe following:- Mandatory startup mechanism- Checks on type of IOF user- Checks on GCL commands

To controlaccess to GCLand JCLcommands inIOF or batchmode

- System Administrator- Developer of the GCL command


47 A2 17UG Rev00 2-11

2.2.1 Control on Access to Cataloged Applications

This mechanism is very often the first control on access to GCOS 7. Its use is imperative.

NOTE: A cataloged application is a list of names associated with a project in the catalogbase (see Chapter 4). Each name represents an access right to a GCOS 7service.

This notion of 'cataloged application' is not to be confused with the notion of'application' in the usual sense of the word.

The first control on access to IOF or to a TDS application is performed by the mechanismof cataloged applications (to check that the name "IOF", or the name of the TDSapplication, belong to the list in the catalog). If SECUR'ACCESS is active on the site, thiscontrol may be an unnecessary repetition.

Control on access to UFT (Unified File Transfer), DJP (Distributed Job Processing)..., isalso performed by the mechanism of cataloged UFT, DJP..., applications (see Chapter 4).In this case, the control mechanism is complementary to SECUR'ACCESS mechanisms,insofar as SECUR'ACCESS operates only on terminal-->TDS and terminal-->IOFconnections.

You are advised to:

Ensure that (depending on the products available on the site) projectsdo not have the right to more than is necessary. To limit their rights,use the CONFIG utility (SECOPT command, CHKPW parameter).See Chapter 4 of this document, and the System Installation,Configuration and Updating Guide

This access control is managed in the GCOS 7 catalog by the IOF utility,MAINTAIN_CATALOG (creation, addition, or deletion of a cataloged application from aproject). See Chapter 4 and the System Administrator's Manual.


2-12 47 A2 17UG Rev00

2.2.2 Control on Access to Transactions (Authority Mask)

This mechanism is dedicated to controls on access to TDS transactions. Its use isimperative in order to limit access to transactions.

NOTE: When SECUR'ACCESS is used, the following cases must be distinguished:

1) Limiting access to transactions reserved for the TDS MasterOperator and to the pre-defined transactions, TRACE andPass-Through.

2) Limiting access to applicative transactions

In case 2), the 'SECUR'ACCESS control points' are an alternative, or complementary,solution.

This mechanism compares authority codes attached to a project with authority codesattached to a transaction. There are 32 possible codes. A transaction is authorised ifcode N is attached to both the project and the transaction.

For more information see Chapter 4 of this document and the:• System Administrator's Guide• TDS Administrator's Guide

This access control is managed as follows:

Codes <--> project relationshipThe IOF utility MAINTAIN_CATALOG adds, modifies or deletes a code for acataloged application and a project. See Chapter 4 of this document and the SystemAdministrator's Guide

Codes <--> transaction relationshipA code for a transaction is added, modified or deleted:- either, at TDS generation (AUTHORITY-CODE statement of TDSGEN)- or, dynamically, using the TDS Master Operator command (the GCL command

MODIFY_TX or equivalent).

NOTE: Authority codes of pre-defined transactions (TRACE for debugging and Pass-Through (PT)) are specified in the TP7TXLIB subfile of SYS.HSLLIB. Thedefinition of these transactions is common to all TDS applications on a site.

You are advised to:

Modify TP7TXLIB in the SYS.HSLLIB file in order to restrict access todebugging transactions (TRACE) and to PT (Pass-Through).This modification should be repeated at each installation of a newtechnical status.


47 A2 17UG Rev00 2-13

As a complement to this type of control, it is possible to specify and create a TDSapplication in such a way that the TDS command mode cannot be accessed (whichmeans that the transactions cannot be activated directly by entering their names).

2.2.3 Access Control Through a SECUR'ACCESS Control Point

This mechanism allows access control within a TDS application. It is complementary tothe mechanism described in the previous paragraph.

• It applies to applicative transactions and may either complete (with possibilities for amore refined control than the simple access right to a transaction), or replace, themechanism of 'Control on Access to Transactions'.

• It does not apply to transactions reserved for the TDS Master Operator and debuggingtransactions (TRACE) and must be implemented in conjunction with the 'Control onAccess to Transactions' (described above).

This mechanism is based on 'control points' in the applicative transactions. These 'controlpoints' enable you to test the information in the SECUR'ACCESS base (Main Rights andlocks) related to the right of a given user to pass a given 'control point'.

The access controls are managed as follows:

• For 'control points', by programming a link to a SECUR'ACCESS function between twoTPR applications. See Chapter 5 and the SECUR'ACCESS Programming andImplementation Guide.

• For the management each user's rights (Main Rights and locks), by administration ofthe SECUR'ACCESS base. See Chapter 5 and the SECUR'ACCESS SecurityAdministrator's Manual.

2.2.4 Control on Access to Files

This mechanism is used to control access to cataloged files by IOF and batch users.

NOTE: This control is unnecessary for a TDS application, as controls on a TDS user,with regard to files, are never performed (unless specially programmed in theapplication).

The control is performed on the project of an IOF user, or of a user under whose identity abatch job is submitted. The access rights "project user" <--> "cataloged file" are recordedin:

• either the SITE.CATALOG file,

• or the SYS.CATALOG file,

• or in specific private catalogs.


2-14 47 A2 17UG Rev00

These rights are managed via IOF or batch commands.


47 A2 17UG Rev00 2-15

NOTE: Specific control on access to the user journal is performed, via the DUMPJRNLutility. Access is checked with regard to the conventional directoryDUMPJRNL_CTRL:When this directory exists, you must have the READ access right (at least), inorder to use the DUMPJRNL utility.

For more information, refer to Chapter 6 of this document and the:• Catalog Management User's Guide,• IOF Terminal User's Reference Manual, Part 1, Part 2, Part 3.

2.2.5 Control on Access to Memory Resources and CPU (ARM)

The ARM (Automatic Resource Manager) mechanism is more a system managementfacility than a security function. However, it may contribute to the "availability" aspect, byguaranteeing the rights of an IOF or batch user, compared to other users, to memoryresources and the CPU.

Refer to the following documents:• ARM User's Guide, for the mechanism of resource management,• System Operator's Guide and the ARM User's Guide, for the management of

resources using commands available to the Main Operator.

2.2.6 Control on Access to Available Disk or Tape Space(QUOTA, 'Volume OWNER' and 'Volume Name OWNER')

These mechanisms are more system management facilities than security functions.However, they may contribute to the "availability" aspect, by guaranteeing the rights of anIOF user, or of a user under whose identity a batch job is submitted, compared to otherusers, to disk or tape space. (The term "tape" also includes cartridges).

QUOTA Manages, to a very precise degree, the disk space allocatedto a project. (The quota of allocated space may bedistributed among several disks that are shared by severalprojects.)

Volume OWNER Only one project has the right to use the available space on agiven volume. This mechanism applies to tapes and disks.

Volume Name OWNER Controls the use of volume preparation tools(PREPARE_DISK, PREPARE_TAPE...). The volume names(disks or tapes) provided by the users of these tools arecompared with the finite list of names associated with theuser's project (list stored in the catalog).

Refer to:• Administering the Storage Manager, for information on QUOTA• Chapter 6 of this document for information on 'Volume OWNER' and 'Volume Name

OWNER'.


2-16 47 A2 17UG Rev00

2.2.7 Control on Access to GCL and JCL Commands

The following methods are available for controlling access to commands in an IOFenvironment:

• the mandatory startup mechanism• checks on the type of IOF user (Main Operator, Station Operator, IOF End User, etc.)• the mechanism of controlling access to GCL commands.

These controls are performed with regard to information registered in theSITE.CATALOG, at project level.

2.2.7.1 The Mandatory Startup Mechanism

At the beginning of each IOF session you can execute a registered sequence ofcommands. This execution cannot be bypassed by an IOF End User.

The subfile containing the commands (Mandatory Startup) is defined at project level by aSystem Administrator via the MAINTAIN_CATALOG utility.

This startup sequence may be used, for example, to access a processor directly, withouthaving access to all the system (S:) level IOF commands.

2.2.7.2 Checks on the Type of IOF User

Some commands, or parts of commands, used for system administration are reserved forthe Main Operator or Station Operator. (For details, refer to the System Operator'sGuide.)

The Main Operator or Station Operator attribute is defined at project level via theMAINTAIN_CATALOG utility.

NOTE:

For batch jobs, and according to the command, checks are performed:

- sometimes with regard to the submitter's project- at other times with regard to the submitter, or the owner, of the job (i.e. a

command may be allowed if either the submitter, or the owner, of the job is anoperator.)

2.2.7.3 Control on Access to GCL Commands

This mechanism controls access to GCL commands by IOF and batch users, in GCLmode only.

NOTE: This control is unnecessary for a TDS application, and for users with access toJCL commands.


47 A2 17UG Rev00 2-17

The control is performed on the project of an IOF user, or of a user under whose identity abatch job is submitted. The access rights "project user" <--> "GCL command" arerecorded in the SITE.CATALOG file.

These rights are managed by the GCL command management utilityMAINTAIN_COMMAND. For more information, refer to the following documents:• System Administrator's Manual,• GCL Programmer's Manual,• IOF Termi.nal User's Reference Manual, Part 1, Part 2, Part 3.

The System Administrator's control over access rights to GCL commands can be adjustedusing the CONFIG utility (command SADMOPT, parameters GCLKPROJ andGCLKSADM). Refer to Chapter 3 of this document and the:• System Installation, Configuration and Updating Guide.

Changing to JCL mode can be prohibited by the presence of H_NJCL_I in the list ofcataloged applications linked to a project. See Chapter 4 of this document:

You are advised to:

- limit the use of MAINTAIN_COMMAND- limit the use of JCL mode- limit the execution of programs in IOF or batch mode (EXEC_PG orEJR)

in order to obtain efficient control on access to GCL commands.

2.2.8 Other Types of Access Control

Certain functions may implement specific controls (for example, the utilization of XCP1and XCP2 protocols under TDS). Refer to the documentation on access controls relatedto these particular functions.


2-18 47 A2 17UG Rev00

2.3 OBJECT REUSE

Summary of Object Reuse Functions


Object reuse related to a TDSapplication

To deleteobsoleteinformation froma TDSapplication

- Developer of a secure application

Object reuse related to a disk file To deleteobsoleteinformation froma disk file

- System Administrator- IOF End User

Reuse of a disk volume

Reuse of a tape file or volume

To deleteobsoleteinformation froma disk volume,or from a tapefile/volume

- System Administrator- Main Operator

2.3.1 Object Reuse Related to a TDS Application

This aspect is specific to TDS applications that handle stored objects (for example, datastored in memory) which must be kept confidential. It is essential to ensure that whenthese objects are no longer used, their contents may not be retrieved (wholly or partially)by another user.

The objects of a TDS application cannot be defined arbitrarily; they are specific to eachapplication. (For example: personal information such as an address or a salary may beconsidered to be confidential, while statistical information such as the average of a set ofsalaries may be considered to be public.)

You should, therefore, make an inventory of confidential information manipulated by theapplication, and respect a certain number of rules for manipulating this information whendesigning and running the application.


47 A2 17UG Rev00 2-19

The rules are, notably:

• Initialize systematically, and as soon as possible, all zones of data, whether the databe:

- private, for a particular TPR (Transaction Processing Routine)- shared by the TPRs of a transaction- common to all transactions

Note that some data is initialized automatically by TDS. In this particular case, asecond initialization is unnecessary. For other data, not automatically initialized (datalocal to a program), initialization is essential.

See the TDS COBOL Programmer's Guide for information on data manipulated by aTDS application.

• Erase data systematically, and as soon as possible, from all data zones (byre-initializing the zones with constant values). Private data for a particular TPR shouldbe erased, at the latest, at the end of TPR execution. Proceed in the same way forobsolete information stored in files.

• Prohibit the use of debugging tools (such as TRACE, or applicative debuggingtransactions). These tools could provide a direct access to data manipulated bytransactions. See 'Control on Access to Transactions', described earlier in thischapter.

2.3.2 Object Reuse Related to a Disk File

This mechanism contributes to the confidentiality of data stored in disk files. It prohibitsthe possibility of retrieving data from a disk file that has been logically deleted (forexample: via maintenance tools, or by re-allocating a file to a space from which a file hasjust been deleted).

The mechanism is triggered by file destruction commands (such as, DELETE_FILE,DELETE_CATALOG...) that may systematically overwrite all data in a file before freeingthe disk space.

There are two methods of erasing data when deleting files:

• file by file, using a specific parameter (for example, the ERASE parameter of the GCLcommand DELETE_FILE),

• globally, whatever parameter is used at the time of destruction. This method isimplemented at configuration (with the ERASE parameter of the SADMOPT commandin the CONFIG utility. Refer to the System Installation, Configuration and UpdatingGuide).


2-20 47 A2 17UG Rev00

2.3.3 Reuse of a Disk Volume

All the data on a disk can be completely erased by using the COMPLETE parameter ofone of the following commands:

PREPARE_VOLUME (GCL syntax)VOLPREP (JCL syntax)

Note that this operation is very long.

For more information, refer to: Data Management Utilities User's Guide.

2.3.4 Reuse of a Tape File or Volume

Although there is no pre-defined GCOS 7 tool that erases data on a tape volume, arecommended method is to develop a program that creates a new file and overwrites allexisting data on the tape.


47 A2 17UG Rev00 2-21

2.4 ACCOUNTABILITY AND AUDIT

The tool described in this paragraph (AUDIT 7) is a product dedicated to security. Its usemust be completed by collecting and conserving various traces (magnetic or paper) - of,for example, dialogs on the Main console, the system configuration report, or applicationsource programs.

A description of AUDIT 7 can be found in the AUDIT 7 Administrator's Manual.

Summary of Accountability and Audit Functions


Accountability To collectsecurity-relatedevents

AUDIT 7 Administrator

Audit To analyzeevents collectedduring theaccountabilityphase

AUDIT 7 Administrator

2.4.1 Accountability for Events

This mechanism consists mainly of collecting security-related events using the AUDIT 7product. The events collected are related to one of the following:

• The activation of a security function, such as:- an identification- an authentication- control on access to transactions- SECUR'ACCESS control points- control on access to a files

• An administrative operation associated with a security function (such as: adding aproject to the GCOS 7 catalog, adding a user to the GCOS 7 catalog or to theSECUR'ACCESS base, modifying or deleting the project or the user)

• An administrative operation related to the 'availability' aspect of security (stopping aTDS application, for example).

The management of this function (which consists mainly of selecting events to becollected - see the AUDIT 7 Administrator's Manual) is handled by the IOF utilityMAINTAIN_AUDIT7. Use of this utility is restricted to the AUDIT 7 Administrator (whichmeans any user who is a member of the AUDIT 7 project).


2-22 47 A2 17UG Rev00

The System Administrator does not have direct access to this function. All indirect access(by modifying, or adding a user to the AUDIT 7 project) can be accounted for and audited,assuming that AUDIT 7 Administrators ensure the confidentiality of their passwords.

You are advised to:

Attribute the roles of AUDIT 7 Administrator and System Administratorto different people. (Do not allow a user to belong simultaneously toboth of these projects.)

The collected events are recorded in a text file, organized in columns, (the audit file) thatdescribes , for each event, the action performed, when and by whom.

2.4.2 Security Audit

Although there is no pre-defined tool that analyzes the audit file, the format of the file(columns of text documented in the AUDIT 7 Administrator's Manual) makes it possible touse most of the available analyzing tools (such as: SQL language, a specific applicationprogrammed in COBOL, a text editor).

Apart from abnormal or infrequent events, which require particular attention, the analysesare specific to controls that have been implemented and applications with a criticalcharacter (for example, a daily list of all accesses to a transaction that modifies salaries).

The following events may be considered as abnormal or infrequent:

• Access violation.

• Data integrity default in the SECUR'ACCESS security base.

• Use of maintenance tools.

• Modification of the security bases (in particular, modification or addition ofadministrators, operators or IOF End Users)..

• Administrator or operator activity.

• Administration of accountability and audit (including the non-saturation of the eventcollecting mechanism, which implies an adequate size for the collecting files, andcorrect sequencing of the batch jobs that perform collecting/archiving/analyzingoperations).

You are advised to:

- Collect, systematically and automatically, a maximum amount ofinformation (using the FULL filter, for example) and archive thisinformation (on tape or cartridge).


47 A2 17UG Rev00 2-23

- Perform, before archiving, a periodic and systematic audit ofimportant events (every day, every hour and more frequently ifnecessary).

Refer to the list of important events above, and to the AUDIT 7Administrator's Manual.


2-24 47 A2 17UG Rev00

47 A2 17UG Rev00 3-1

3. Installation of GCOS 7 and Basic SecurityComponents

This chapter outlines, in chronological order, the installation of the GCOS 7 system andessential security components. The security components you intend to use must bedefined before installation according to your security objectives - see the previous chapter,'Logical Security in a GCOS 7 Context'.

In the case of an existing installation, this outline can be used as a checklist to verify (and,if necessary, complete) the installation, step by step.

You are advised to carry out the operations described below from the Main console or, forSECUR'ACCESS installation, from a secure terminal, up to the phase 'Verification of theBasic Security Functions'. The authentication and identification mechanisms (whichconstitute the basis for all controls), function fully only when this phase has beencompleted.

The same precautions must be taken at each global manipulation affecting componentsthat are critical for the security of the system (for example, changing the SITE.CATALOGfile, updating the SECUR'ACCESS base using tools such as SA7-GBASE, SABASE).

You are advised to:

- Prohibit connections via a network (GCL command STSVR, orequivalent) before completing the phase 'Verification of the BasicSecurity Functions', except for SECUR'ACCESS installation.

- Keep a detailed trace (magnetic or paper) of all installationoperations, except for SECUR'ACCESS installation.

If there are several occurrences of GCOS 7 systems on a site, (for example: a P2Pconfiguration, coupled systems, systems connected via a network) the levels of securityfunctions installed on the production systems must all be consistent.

Refer to the System Installation, Configuration and Updating Guide for a description of theP2P configuration.

You are advised to:

- Install the same security functions, using the same procedure, on allthe production systems in a P2P configuration, or in a coupledsystems environment.


3-2 47 A2 17UG Rev00

3.1 INSTALLATION OF GCOS 7

This initial phase consists of adapting GCOS 7 software (and firmware) to the hardwareconfiguration in use. It consists also of defining the size of resources necessary forapplications (for example: number of files used simultaneously, number of connections)and implementing certain optional functions (such as Mirror Disks).

This installation phase is described in detail in the System Installation, Configuration andUpdating Guide.

3.2 INSTALLATION OF GCOS 7 SECURITY FUNCTIONS

To complete the previous initial phase, the security functions indicated below must beactivated at the beginning of GCOS 7 operations.

3.2.1 Installation of Configuration Controls

The commands referred to in this paragraph are described in the System Installation,Configuration and Updating Guide.

Two commands of the configuration utility CONFIG, used during the installation phase ofGCOS 7 are directly related to security:

SADMOPT and SECOPT

The parameters of these commands are directly related to the security functionsdescribed in Chapter 2 of this document.

You are advised to:

Select the appropriate values for the parameters of the SADMOPTand SECOPT commands.

WARNING: Wait until the installation phase of SECUR'ACCESS toset the SECOPT parameters: SA7LOGON, SA7ADMIN, SA7NOCSL.

Installation of GCOS 7 and Basic Security Components

47 A2 17UG Rev00 3-3

SADMOPT Parameters

GCLKPROJ Relate to the function "Control on Access to GCLGCLKSADM Commands" (see Chapter 2).

GCSADMOP Relates to the right of the System Administrator to useoperator commands via EXDIR

CHKJSADM Relates to the function "Identification and Authentication inthe Case of Delegated Identity (Batch Processing)" - seeChapter 2.

SECOPT Parameters

SA7LOGON Relate to the functions of GCOS 7 authentication withSA7ADMIN SECUR'ACCESS (see Chapters 2 and 5).SA7NOCSL WARNING: Wait until the installation of SECUR'ACCESS to

set these parameters.

CHKPW Relates to the authentication function and to "Control onAccess to Cataloged Applications". (see Chapter 2)

ERASE Relates to the function "Object Reuse Related to a Disk File"(see Chapters 2 and 5).

3.2.2 Installation of File Access Controls

File access controls are installed in IOF mode, with the GCL command MODIFY_ACL(MDACL), using a procedure described in Chapter 6 of this document or in the SystemAdministrator's Guide

This procedure includes implementing controls on access to system files that werecreated during the installation phase of GCOS 7 (SYS.* and SITE.* files). Refer to theSystem Installation, Configuration and Updating Guide and, more particularly, to thePROTECT_GCOS command of the GIUF utility.

You are advised to:

Define access rights to files as soon as possible in the installationprocedure, as the later phases (installation of SECUR'ACCESS,AUDIT 7...) include the creation of protected files.

The installation of file access controls (after which the term "protected system" can beused) gives rise to complementary effects, such as restrictions concerning batchprocessing under another user's identity. See "Identification and Authentication in theCase of Delegated Identity (Batch Processing)" in Chapter 2.


3-4 47 A2 17UG Rev00

3.2.3 Creation, Deletion, or Modification of 'Standard' Users

Conventional users (such as: SYSADMIN, GCOS7, OPERATOR) are created and used inthe early phases of system installation. Refer to:• System Installation, Configuration and Updating Guide• System Administrator's Guide.

To prevent these names from being used later, the following precautions are necessary:

• Replace the conventional SYSADMIN and GCOS7 users of the SYSADMIN project bythe real identities of the future System Administrators (users of the project attached tothe conventional SYSADMIN name).

• Create the real identities of the future Main Operators (users of projects with the MAINattribute). See the System Administrator's Guide.

• Replace the password of the OPERATOR user with a complex value (for example 12non-trivial characters) stored in a secure place.

NOTE: The OPERATOR user cannot be deleted from the OPERATOR project, as thisidentity is used by convention for certain system jobs sent by GCOS 7.

• Limit the number of connections made under the name 'OPERATOR', in order todistinguish (when auditing, for example) the actions of Main Operators from the actionsof the GCOS 7 system which by convention use the name 'OPERATOR'.

If SECUR'ACCESS is to be installed at a later stage, prior to its installation you mustdeclare the users SECADMIN and M1 with complex passwords stored in a secure place.If this is not done, SECUR'ACCESS will create, by default, users with a fixed password.This could constitute a weakness in the system during the installation phase.

In the SECUR'ACCESS context, limit connections made under the names SECADMINand M1 in order to reduce the risks of divulging their passwords, and to facilitate theauditing of their actions.

You are advised to:

- Delete the users SYSADMIN and GCOS7 from the SYSADMINproject.

- Attribute a complex password to the user OPERATOR of the projectOPERATOR, and abstain from using this identity to connect MainOperators in the operational phase.

- If SECUR'ACCESS is to be installed, anticipate the creation ofSECADMIN and M1 users under the OPERATOR project (whichmust not be the default project) . Give complex passwords to theseusers.


47 A2 17UG Rev00 3-5

3.2.4 Control on Access to Debugging Transactions

Authority codes of the pre-defined transactions TRACE and PT (Pass-Through) arespecified in the subfile TP7TXLIB of SYS.HSLLIB. The definition of these transactions iscommon to all TDS applications on a site.

You are advised to:

Modify TP7TXLIB in the SYS.HSLLIB file in order to restrict access todebugging transactions (TRACE), and to Pass-Through (PT). Thismodification must be repeated at each installation of a new technicalstatus.


3-6 47 A2 17UG Rev00

3.3 INSTALLATION OF AUDIT 7

The procedure and tools used to install AUDIT 7 are described fully in theAUDIT 7 Administrator's Manual.

The actions to be performed when AUDIT 7 is installed are as follows:

• Create elements that are essential to the correct functioning of AUDIT 7 (such as: files,cataloged Project, AUDIT 7 Administrators).

You are advised to:

Ensure the confidentiality of the AUDIT 7 Administrator's password(even with regard to System Administrators). The AUDIT 7Administrator must modify his initial password as soon as possible.

• Replace the password of the conventional user 'AUDIT7' with a complex value (forexample, 12 non-trivial characters) stored in a secure place. Limit the number ofconnections under the name 'AUDIT7' in order to reduce the risk of divulging thepassword, and to facilitate the auditing of this user's actions.

You are advised to:

Attribute a complex password to the user 'AUDIT7' of the project'AUDIT7', and limit the use of this identity in the operational phase.

• Personalize tools for archiving files in which events are to be stored.

• Start the event collecting function.

• Select the security-related events that you wish to collect.

• Create tools to analyze these events.

You are advised to:

Guarantee automatic sequencing of the tools that collect and analyzeevents (sufficient capacity for event-collecting files; the batch job classreserved for analyzing tools, with a high execution priority).

NOTE: The module that displays AUDIT 7 events is updated when SECUR'ACCESS isinstalled. Consequently, AUDIT 7 is fully operational only after installation ofSECUR'ACCESS. (See "Installing SECUR'ACCESS" later in this chapter.)


47 A2 17UG Rev00 3-7

3.4 STARTING TELECOMMUNICATIONS

The next step in the GCOS 7 installation procedure is to install telecommunicationssoftware and applications. Refer to the following GCOS 7 documents:• System Operator's Guide• Network Operations• Network Generation

At this stage you must ensure that the identification of terminals with access to the site isreliable. This identification is defined when the front-end processors are configured. It isrecorded by AUDIT 7 when a connection is requested and must allow the physical originof the request to be found.

You are advised to:

Prohibit connections from a non-verifiable origin (for example, via thetelephone network).

3.5 INSTALLATION OF SECUR'ACCESS

The procedure and tools used to install SECUR'ACCESS are described fully in theSECUR'ACCESS Customer Service Bulletin. They are briefly outlined below.

• Create elements that are essential to the correct functioning of SECUR'ACCESS(SECUR'ACCESS files and TDS, cataloged project and users, catalogedSECUR'ACCESS application, updates to system components...).

You are advised to:

Take the precautions concerning the 'standard' users SECADMIN andM1 before beginning SECUR'ACCESS installation. See 'Creation,Deletion, or Modification of Standard Users', earlier in this chapter.

• Start the SECUR'ACCESS TDS.

• Select the parameters that are specific to the site.

• Define Security Administrators other than SECADMIN.

• Align the SECUR'ACCESS security base with the GCOS 7 catalog

• Automate the start-up of the SECUR'ACCESS TDS (modification of system start-up).

• Validate SECUR'ACCESS controls in GCOS 7 (via the CONFIG utility, SECOPTcommand, parameters SA7LOGON, SA7ADMIN, SA7NOCSL - see theSystem Installation, Configuration and Updating Guide).


3-8 47 A2 17UG Rev00

3.6 VERIFICATION OF THE BASIC SECURITY FUNCTIONS

Before GCOS 7 becomes operational, you must ensure that all the installation procedurespreviously described were carried out successfully.

You are advised to:

Perform the tests described below before making GCOS 7operational.

• Try to connect under the following conventional names and passwords, present duringthe installation phase:

- The users SYSADMIN, GCOS7 and OPERATOR, in all cases (GCOS 7 with orwithout SECUR'ACCESS). See the System Installation, Configuration andUpdating Guide.

- The users SECADMIN and M1, if SECUR'ACCESS has been installed. See theSECUR'ACCESS Security Administrator's Guide.

- The AUDIT7 user, if AUDIT 7 has been installed.See the AUDIT 7 Administrator's Manual.

NOTE: The users OPERATOR, SECADMIN and M1 (if SECUR'ACCESS ispresent),AUDIT7 (if AUDIT 7 is present), must continue to exist, but with complexpasswords stored in a safe place. These names are to be used to connect inexceptional cases only.

• Use, under the identity of the Main Operator, the commandDISPLAY_SECURITY_OPTIONS (DSO) which displays configuration options relatingto security (SADMOPT and SECOPT commands of the CONFIG utility) and alsodisplays the situation of file access rights. Refer to:- System Installation, Configuration and Updating Guide, for the CONFIG utility- System Administrator's Manual, for file access rights.

• Display, under the identity of the AUDIT 7 Administrator (using MAINTAIN_AUDIT7),types of collected events (commands STATUS and DISPLAY_FILTER). Check thatthe archiving and auditing procedure is working correctly (by forcing it to function withthe command SWITCH_FILE). Check also that archiving and auditing jobs have ahigher priority than routine operating jobs (reserve a special class for batch jobs, forexample).

• Display, under the identity of the Security Administrator, the data attached to the siteand check the minimal constraints you wish to impose (on the type of control, theminimum length of password, etc.).


47 A2 17UG Rev00 3-9

3.7 CREATION AND ADMINISTRATION OF A TDS APPLICATION

This section briefly describes the main security aspects of TDS.

The creation and administration of a TDS application are described in detail in thefollowing documents:• TDS Administrator's Guide,• TDS COBOL Programmer's Guide.

The SECUR'ACCESS aspects are described in:• SECUR'ACCESS Customer Service Bulletin,• SECUR'ACCESS Programming and Implementation Guide.

3.7.1 Preparation of TDS (TP7PREP)

Concerning file access control, a TDS application obeys the same rules as for a batch job,in that checks are made on the owner of the job.

To audit accesses to components of a TDS application (tds_name.LMLIB,tds_name.SLLIB...) you must:

• Select events related to subfiles, using MAINTAIN_AUDIT7 (see the AUDIT 7Administrator's Guide).

• Modify the libraries to be audited, using MODIFY_FILE (LOGSUBF parameter). Seethe Terminal User's Reference Manual.

You are advised to:

- Protect the files of a TDS application, by controlling access to them.

- Record events related to modifications of the application'scomponents.


3-10 47 A2 17UG Rev00

3.7.2 TDS Generation Options (TP7GEN)

If SECUR'ACCESS is used, TP7GEN parameters prefixed with SA7 must be used.These parameters are:

SA7 Use of SECUR'ACCESS (YES or NO).

SA7IDS If YES, Full IDS is used.If NO, IDS 40 is used.

SA7CULIB Specifies the CU library to be used for the SECUR'ACCESSinterface.

SA7CUDVC Device class of the SA7CULIB, if not cataloged.

SA7CUMD Media of the SA7CULIB, if not cataloged.

Refer to the following documents:• TDS Administrator's Guide• SECUR'ACCESS Customer Service Bulletin

3.7.2.1 Contents of the "TDS SECTION"

• The option "MASTER MAILBOX IS..." defines a master mailbox to which the TDSMaster Operator can connect.

NOTE: The name of the mailbox, and the authority codes attached to the projects ofTDS Master Operators, must be defined using MAINTAIN_CATALOG. Theauthority code 0 must be used in this case.

If SECUR'ACCESS is used, the TDS-SA7 Master Operator must own the MainRight 799, lock 9.

• The options "USE NOPWCHK-ALLOWED" and "USE FREE-ACCESS-TDS" must behandled with precaution. They may disable controls on a user's identification andassume that:- either the application does not need specific security measures- or the application provides its own security checks.

• The option "MAXIMUM IDLE-TIME IS..." automatically disconnects a terminal after aspecified period of idleness, until the name of a transaction is entered.

Refer to the:• TDS Administrator's Guide for more information on the "TDS SECTION"• System Administrator's Manual for information on MAINTAIN_CATALOG.


47 A2 17UG Rev00 3-11

3.7.2.2 Contents of the "TRANSACTION SECTION"

The option "AUTHORITY-CODES ARE" specifies the authority codes attached to eachtransaction. Refer to Chapters 2 and 4 of this document and the TDS Administrator'sGuide.

NOTE: Cataloged applications, and authority codes attached to projects, mustcorrespond to each other when they are defined using MAINTAIN_CATALOG.(See the System Administrator's Manual.)

3.7.3 Contents of Transactions

• If the function 'SECUR'ACCESS control point' is used, the program that controls thesequencing of the TPRs must include the activation of SECUR'ACCESS. Refer toChapters 2 and 5 of this document and the SECUR'ACCESS Programming andImplementation Guide.

• Idle time, while waiting for a reply from a terminal after a 'SEND EGI...' command, canbe limited by using the WAIT-TIME variable of the "TDS Storage". See the TDSCOBOL Programmer's Guide.

• You must plan for the initialization and destruction of confidential data. See "ObjectReuse Related to a TDS Application" in Chapter 2.

3.7.4 Security Audit of the Application

When designing the security aspect of a TDS application, you must include adaptation ofthe accountability and audit tools.

You are advised to:

- Include, in the systematic analysis of the audit file, the tracking of themost sensitive transactions and/or control points, as well as thetracking of the TDS Master Operator's activities.

- Check that the capacity of the AUDIT 7 event collecting files isglobally sufficient, and takes into account the new application.

NOTE: The TDS Master Operator can change the authority codes of a transaction (withthe GCL command MODIFY_TX, or equivalent). Particular attention must,therefore, be given to this command.


3-12 47 A2 17UG Rev00

3.7.5 Validation of the Application

A TDS application is validated from a functional point of view, and it must also bevalidated from a security point of view, as follows

• Check that unauthorized access to administration and debugging tools is impossible

• Check that the access control mechanisms function correctly (control on access totransactions via authority codes, or SECUR'ACCESS control points)

• Check that the tools for systematic analysis of the audit are correctly adapted to thenew TDS application.

47 A2 17UG Rev00 4-1

4. GCOS 7 Access Controls (WithoutSECUR'ACCESS)

4.1 INTRODUCTION

4.1.1 Aim of this Chapter

This chapter contains a functional synthesis of the controls on access to IOF and TDS inGCOS 7 (without using the SECUR'ACCESS product).

The following functional aspects exist:

• The fundamental security functions: identification, authentication, access controls

• Administrative functions (utilization of the MAINTAIN_CATALOG product in IOF) thatmanage security data associated with the security functions

• Installation and configuration rules to be applied, before controls on access to IOF andTDS applications become operational.

4.1.2 The Security Base

NOTE: The term 'security base' refers to any store of security-related data (in the formof a file, a database etc.)

The GCOS 7 system offers a set of security functions that use the catalog(SITE.CATALOG file) as a security base.

This security base is managed through the MAINTAIN_CATALOG utility, accessibleexclusively via the interactive service IOF, or in batch processing.


4-2 47 A2 17UG Rev00

4.2 CONNECTION CONTROLS

The connection procedure for a terminal user includes the following functions:

• identification (the identifiers are: User, Project)

• authentication (password control)

• control on access to an IOF service or a TDS application.

The controls that correspond to these functions are the only controls performed atconnection.

The controls performed at the Main console, or via the Pass-Through procedure (TDS orIOF) are identical.

4.2.1 Identification

The identification function is based on the pair of identifiers (Project, User). A personconnected to GCOS 7 is identified by:

Project.User

Authentication data, in the form of a specific password, is attached to each User.

The data in the catalog base, concerning a connected person, (various access rights,various administrative attributes) is attached to a Project.

4.2.2 Authentication

Authentication consists exclusively of comparing the password supplied by the user, withthe password registered in the catalog base.

Handling Errors

Errors concerning:

• the Project.User identifier,• the password,• controls on access to IOF or TDS

result in the connection being rejected. The rejection is not recorded and not penalized.

GCOS 7 Access Controls (Without SECUR'ACCESS)

47 A2 17UG Rev00 4-3

Connecting Without Authentication

The authentication function can be disabled at the request of the entity making theconnection.

This technique is used by applications that consider that certain connections must not beauthenticated (for example, UFT with regard to the remote site, when the connection hasalready been authenticated at the local site).

If you have doubts about the security of the set of applications in a network of machines(including non-DPS 7000), you can use the configuration option CHKPW=YES (SECOPTcommand in the CONFIG utility). This option prohibits unauthenticated connections to thefollowing applications: IOF, TDS (except when the generation option USE NOPWCHK-ALLOWED is used), UFT, DJP, SOW. See the System Configuration, Installation andUpdating Guide.

4.2.3 Control on Access to Applications

The access right to a service (IOF, TDS...) is stored in the catalog security base. It isattached to the pair:

(subject: Project identifier, object: Application name).

The cataloged Application name may represent one of the following cases (the list isopen):

• Cataloged application names that are always significant:

- name of a TDS application (mailbox of an ordinary user, i.e. not the TDS MasterOperator)

- name of the master mailbox of a TDS application

- IOF (any user)

- H_NJCL_I (prevents an IOF user switching from GCL mode to JCL mode).

• Cataloged application names that are significant only when the system is configuredwith the option CHKPW=YES (SECOPT command in the CONFIG utility. See theSystem Installation, Configuration and Updating Guide.)

- UFT (user on whose behalf a file transfer request is accepted)See the UFT User's Guide.

- DJP (user on whose behalf a job transfer request is accepted)See the DJP User's Guide.

- SOW (user on whose behalf an output transfer request is accepted)See the DJP User's Guide.

- RPMOS (user on whose behalf an operator command from a remote machine isaccepted).


4-4 47 A2 17UG Rev00

4.3 PASSWORD MANAGEMENT

The System Administrator may attribute the initial password, and may change it later.

An IOF End User may change his password.

A TDS End User may not change his password.


47 A2 17UG Rev00 4-5

4.4 APPLICATION CONTROL (ON ACCESS TO TRANSACTIONS)

This access control is based on:

• The set of 32 authority codes attached to the Project in the catalog base (managed bythe System Administrator). This set of codes is in the form of a hexadecimal string of 8bytes, named 'authority mask'. Note that the first authority code is reserved (by theTDS system) for the TDS Master Operator. See the System Administrator's Manual.

• The set of authority codes attached to each transaction within a TDS system. This setof codes is defined at TDS generation (with the TDSGEN statement AUTHORITY-CODE) and managed by the Master Operator of the TDS (with the GCL commandMODIFY_TX, or equivalent). See the TDS Administrator's Guide.

A transaction is authorized for the user of a given project if there is at least one authoritycode common to:

• the list of codes attached to the project,

• the codes attached to the transaction.


4-6 47 A2 17UG Rev00

4.5 THE CATALOG SECURITY BASE

4.5.1 Administration of the Catalog Security Base

The following entities are managed in the GCOS 7 catalog base by the IOF utilityMAINTAIN_CATALOG: User, Project, Application, Billing, Station.

The management functions are: creation, modification, deletion, copy of these entitiesand their associated attributes.

Only the System Administrator has the right to manage this base (apart from the right thatany IOF user has to modify his own password - see above).

Details of catalog administration are given in the System Administrator's Guide.

NOTE: Updates to the GCOS 7 catalog base are not always immediately transferred toapplications. You must take this fact into account during administrationoperations. (For the updates to be taken into account immediately, disconnectusers who have been modified.)

4.5.2 Responsibilities Defined in the Catalog Security Base

4.5.2.1 System Administrator

This person has the main responsibility for the administration of a GCOS 7 site. Refer tothe System Administrator's Manual.

The system administrator manages:

• the entities in the GCOS 7 catalog (User, Project, Application, Billing, Station). (For aUser in SECUR'ACCESS mode, see Chapter 5 of this document),

• access rights to files,

• available disk space (using QUOTA, Volume OWNER,...).

All users of the project with the conventional name 'SYSADMIN', in the catalog securitybase, are System Administrators, if they connect under this project in IOF.


47 A2 17UG Rev00 4-7

4.5.2.2 AUDIT 7 Administrator

This person is responsible for the administration of the AUDIT 7 product. Refer to theAUDIT 7 Administrator's Manual.

He manages the selecting of security-related events and their recording in the log file. Hehas access to audit files.

All users of the project with the conventional name 'AUDIT7', in the catalog base, areAUDIT 7 Administrators, if they connect under this project in IOF.

4.5.2.3 Main Operator

This person is responsible for the routine management of a GCOS 7 system.

He has access to a set of commands that enable him to operate the system(management of batch jobs, including those submitted by other users; management oftelecommunications...). See the System Operator's Guide.

All users of projects that have the MAIN attribute in the catalog security base are MainOperators, if they connect under these projects in IOF. (See the System Administrator'sManual for information on commands related to projects.)

4.5.2.4 TDS Master Operator

This person is responsible for the administration of a TDS service. He has access to aset of specific commands.

A TDS Master Operator may be:

• either a user of the project who has access to, and is connected to, the TDS mastermailbox, and who has the first authority code set to 1

• or the TDS submitter, if there is no TDS master mailbox.

There is only one TDS Master Operator at any given time.

Refer to:• TDS Administrator's Guide, for information on the TDS Master Operator• System Administrator's Manual, for information on commands related to projects.


4-8 47 A2 17UG Rev00

4.6 INSTALLATION OF ACCESS CONTROLS

The installation of access controls using the catalog base (SITE.CATLOG file) is includedin the general GCOS 7 installation procedure. The access controls are systematicallyactivated when a GCOS 7 session is initialized. See the System Installation,Configuration and Updating Guide.

47 A2 17UG Rev00 5-1

5. SECUR'ACCESS

5.1 INTRODUCTION

5.1.1 Aim of this Chapter

This chapter contains a synthesis of SECUR'ACCESS functions in GCOS 7. Thefollowing features are visible in SECUR'ACCESS:

• The security functions themselves: identification, authentication, access controls

• SECUR'ACCESS administrative functions (TDS-SA7 administrative service), thatmanage security data associated with the security functions. In some cases (projectmanagement), the GCOS 7 administrative functions must also be applied (using theIOF utility MAINTAIN_CATALOG).

• The programmatic interface that enables SECUR'ACCESS security functions to beused, while a TDS application is running. This interface is available for applicationdevelopment.

• Installation and configuration rules to be applied before SECUR'ACCESS becomesoperational.

The SECUR'ACCESS operating mode (referred to as GCOS 7 with SECUR'ACCESS) isan extension of the operating mode without SECUR'ACCESS (referred to as GCOS 7without SECUR'ACCESS, described in Chapter 4) and is compatible with it to a degree.

NOTE:

Certain terms in the SECUR'ACCESS documentation are not consistent with theterminology used in international security standards, or in GCOS 7 documentation.

- "Access control" may refer to the three functions: identification, authenticationand access controls.

- "Authorization" refers to access controls.- The phrase "several users using the same TDS session" must be read as

"successive identification/authentication of several users using the same TDSconnection".


5-2 47 A2 17UG Rev00

- "level of security" and "level of control" are identical notions.

SECUR'ACCESS

47 A2 17UG Rev00 5-3

5.1.2 The Catalog and SECUR'ACCESS Security Bases

NOTE: The term security base refers to any store of security-related data (in the form ofa file, a database etc.)

GCOS 7 without SECUR'ACCESS offers a set of security functions that use the catalog(SITE.CATALOG file) as a security base.

GCOS 7 with SECUR'ACCESS combines the catalog base and the SECUR'ACCESSbase to provide the visibility of one global base. Security administration is sharedbetween the System Administrator and specific SECUR'ACCESS administrators.

This chapter describes the rules for coexistence and complementarity between the twosecurity bases, in SECUR'ACCESS mode. The rules concern visible security data,administrative operations, and the different classes of administrators.

5.1.3 Installation Categories

5.1.3.1 GCOS 7 With SECUR'ACCESS

A GCOS 7 site on which SECUR'ACCESS is installed has the following characteristics:

• It possesses a TDS service dedicated to security administration (called TDS-SA7administrative service).

• It is configured so that connections to IOF and TDS services are controlled bySECUR'ACCESS (SA7LOGON parameter of the SECOPT command in the CONFIGutility - see the System Installation, Configuration and Updating Guide.)

5.1.3.2 TDS and IOF Connection Controls With SECUR'ACCESS

Each TDS or IOF connection always undergoes a connection control (access right to theApplication designating IOF or the TDS in the catalog base, see Chapter 4).

For enhanced security, a TDS or IOF service may undergo specific SECUR'ACCESSconnection controls.

A GCOS 7 site with SECUR'ACCESS may contain, simultaneously, TDS applications withor without SECUR'ACCESS.


5-4 47 A2 17UG Rev00

The possibility of a service not undergoing specific SECUR'ACCESS connection controls,if GCOS 7 is used with SECUR'ACCESS, applies only to TDS services. (See theTP7GEN option in the TDS Administrator's Guide.)

If GCOS 7 is used with SECUR'ACCESS, IOF and the TDS-SA7 (TDS containing theadministrative service dedicated to SECUR'ACCESS) connections are automaticallycontrolled.

Access Control Rules

Below is a recall of the IOF and TDS access control rule, applicable whether GCOS 7 isused with or without SECUR'ACCESS:

The access right to an IOF or TDS service is stored in the catalog security base. It isattached to the pair:

(subject: Project identifier, object: Application name).

The Application name may represent one of the following cases:

• a TDS application (End User)

• a TDS application (TDS Master Operator)

• IOF (any user).

NOTE: Other application names may be stored in the catalog base, but they do notinteract with SECUR'ACCESS. See "Control on Access to Applications" inChapter 4.

5.1.3.3 TDS Application Services

The TDS application services controlled by SECUR'ACCESS at connection can be of twotypes:

• services with SECUR'ACCESS control points• services without SECUR'ACCESS control points.

The control points require special applications to be developed.

The designer of the application decides whether or not to renew identification and/orauthentication procedures at these control points.

By this means, it is also possible to install a SECUR'ACCESS operating mode allowingTDS multi-user sessions (several application users, each one with his own context, use inturn the same unique connection, at the same unique terminal). This mode must beauthorized on the site (option "USER CONTROL MODE"). This operating mode is notdescribed in the present document.

SECUR'ACCESS

47 A2 17UG Rev00 5-5

5.2 CONNECTION CONTROLS WITH SECUR'ACCESS

5.2.1 Connection Controls for a Terminal

NOTE: The Main console may undergo specific controls.

Security Functions That Constitute a Connection Control

• identification (identifiers: User, Project)• authentication (catalog base)• control on access to an IOF service or to a TDS application (catalog base)• specific SECUR'ACCESS connection controls (SECUR'ACCESS base)

The controls that correspond to these functions are the only ones performed atconnection and cannot be modified in the program of the TDS application. They arealways performed for a TDS using SECUR'ACCESS, whether application control pointsexist or not.

5.2.1.1 Identification

The identification function uses the pair of identifiers (Project, User). A connected personis identified by:

Project.User

Authentication data is attached to this identification.

Individual data in the security base, for a connected person (various access rights, variousadministrative attributes) is attached:

• either to the Project (mainly in the catalog base),

• or to the User (mainly in the SECUR'ACCESS base).

In the SECUR'ACCESS base, the identifiers User and Project are consideredindependently, without considering at all the complete identification 'Project.User'.

The relationship between the catalog and SECUR'ACCESS security bases is describedlater in this chapter.


5-6 47 A2 17UG Rev00

5.2.1.2 Authentication

In GCOS 7 without SECUR'ACCESS, the authentication function applies only thepassword mechanism.

In GCOS 7 with SECUR'ACCESS, the authentication function applies either the passwordmechanism, or the smart card mechanism.

Three possible SECUR'ACCESS control levels may be applied when connecting:

• The set of connection controls is strictly compatible with a GCOS 7 system that doesnot use SECUR'ACCESS. Specific SECUR'ACCESS connection controls are notconsidered.

• Authentication is performed by a password. SECUR'ACCESS authorization (attachedto the User identifier) is controlled.

• Authentication by smart card (this extension is specific to GCOS 7 withSECUR'ACCESS).

Error Handling

Whether GCOS 7 is used with or without SECUR'ACCESS, errors concerning theProject.User identifier, or controls on access to IOF or TDS services, result in theconnection being rejected. The rejection is not recorded and not penalized.

An error concerning the password (authentication phase) results in:

• the connection being rejected, if GCOS 7 is used without SECUR'ACCESS,• specific handling (see next paragraph), if GCOS 7 is used with SECUR'ACCESS.

5.2.1.3 Specific SECUR'ACCESS Connection Controls

The following controls are extensions to GCOS 7 without SECUR'ACCESS:

• individual controls: user's presence on the blacklist, expired password

• management of unsuccessful authentication attempts: mechanism of connectionrefusal after a number of unsuccessful attempts within a time limit

• controls on access certain services (via the Main Right number 799, reserved bySECUR'ACCESS), as follows:

- access to the IOF service,

- access to the TDS-SA7 administrative service, in the role of TDS-SA7 MasterOperator,

- access to the administrative service of saving/restoring the security base,

- delegation of signature.

SECUR'ACCESS

47 A2 17UG Rev00 5-7

Administration of SECUR'ACCESS Control Levels

The control level depends on three elements of information managed bySECUR'ACCESS:

• the minimum level of control attached to the site (general parameters)

• the minimum level of control applicable to an IOF or TDS service (attached to theApplication name)

• the level of control and the 'privileged project' attribute attached to a Project. (This isthe only data attached to the Project in the SECUR'ACCESS base.)

The level of control effectively implemented is the maximum of the above three levels,and the level required by the control point programmed in the application.


5-8 47 A2 17UG Rev00

5.2.2 Connection Controls for the Main Console

Connection controls via the catalog base (access to the IOF service, specialMAIN/STATION/RMS operator attributes) are always performed, whether GCOS 7 is usedwith or without SECUR'ACCESS.

A configuration parameter (SA7NOCSL, of the SECOPT command in the CONFIG utility)provides the option of using SECUR'ACCESS for the IOF main console. See the SystemInstallation, Configuration and Updating Guide.

5.2.3 Controls on Connections via Pass-Through

The procedures to extend connections from one service to another (Pass-Through in IOFand TDS) are also subjected to the security controls imposed by SECUR'ACCESS. Inmost cases this involves re-entering identification and authentication data when the pass-through is established.

However, in the case of a TDS to TDS connection on the same system, SECUR'ACCESScan automatically reuse the same context for a Pass-Through connection. In this casethe user does not need to re-enter identification and authentication data.

5.2.4 Connection Controls When Using ApplicationsOther Than IOF and TDS

These controls (on file transfers, distributed job processing) are not performed bySECUR'ACCESS.

However, interactions are possible between these controls since most of them use datafrom the catalog security base (namely User, Project and Password), and this data ismaintained by SECUR'ACCESS.

SECUR'ACCESS

47 A2 17UG Rev00 5-9

5.2.5 Password Management and Handling of Authentication Errors

When a user is created, an 'initial' password (configurable on the site) is attributed. Thispassword is not controlled and does not give access to the application, but is used toselect a 'real' operational password.

The password is renewed the first time by an IOF or TDS End User. The operation maythen be spontaneously repeated.

The renewals follow the rules established for password cycles. Each SECUR'ACCESSuser is attached to a cycle, defined by the following time intervals:

• the minimum and maximum time allowed between two renewals• the warning period, before the maximum time interval expires.

If the user forgets his current password, he can ask the administrator to restore his initialpassword in order to re-select an operational password.

The number of unsuccessful attempts at authentication is recorded in the security base.Above a certain limit, the user connection is temporarily or permanently refused (user onblack list).


5-10 47 A2 17UG Rev00

5.3 APPLICATION CONTROLS (SECUR'ACCESS PROGRAMMATICINTERFACE, ACCESS TO TRANSACTIONS)

Two types of control are superposed:

• SECUR'ACCESS control points,• control on access to transactions.

NOTE: The term "authorization" in SECUR'ACCESS documentation may refer to thefirst type of control.

5.3.1 Crossing SECUR'ACCESS Control Points

5.3.1.1 Security Functions Initiated by the Programmatic Interface 'Control Point'

The term 'SECUR'ACCESS control point' refers to a call to SECUR'ACCESS securityfunctions, programmed in an application (i.e., TDS transactions). The functions called bythe application perform SECUR'ACCESS identification, authentication and accesscontrols (Main Right and locks), in conformity with the call parameters and taking intoaccount the content of the security base.

'Normal' execution of these functions constitutes the crossing of the control point.

The programmatic interface allows various choices to be made during the call:

• execution or non-execution of identification and authentication (interval and re-authentication considerations)

• choice of authentication level

• definition of access control (no control, control of a Main Right number with or withoutlock profile).

At the end of the call, the following can be analyzed with the programmatic interface:• call execution conditions,• personal data (in the SECUR'ACCESS base) on the identified and authenticated user.

SECUR'ACCESS

47 A2 17UG Rev00 5-11

5.3.1.2 Description of Access Control (Control of Main Rights and Locks)

In the SECUR'ACCESS base, an authorization table is attached to each User, andcontains the rights of the User. The table is composed of up to 10 Main Rights, each oneassociated with a lock profile. A Main Right is a number between 0 and 999. A lockprofile is specified in a 10-character field.

The programmatic interface checks that a given Main Right number is present and isassociated with (at least) one given lock profile.

The Main Rights and associated lock profiles are made meaningful by the design of theTDS application. Rights are given to the User identifiers, in the SECUR'ACCESS base,by Security Administrators. Note that Main Right number 799 is reserved bySECUR'ACCESS and is not therefore available to the application developer using theprogrammatic interface.

5.3.2 Insertion of SECUR'ACCESS Control Points in a TDS Application

The 'control point' programmatic interface is defined in a TDS application environmentusing I/Os in screen mode (the FORMS screen manager), in the COBOL host language.

This interface reflects the structure of the application - in transactions and TPRs. (A TPR,Transaction Processing Routine, is the development unit of a TDS application.) A controlpoint must be attached to a link between two TPRs. For example:

• between a 'menu' TPR and a TPR for a 'function selected by menu' (link after anexternal selection),

• between a TPR for 'end of function X' and a TPR for 'beginning of function X' (iterativelink).

The 'control point' programmatic interface triggers three TPRs:

• The TPR that calls a SECUR'ACCESS function. The final sequence of this TPRincludes:- giving values to the call parameters in an execution context,- the call to the subroutine pointing to SECUR'ACCESS (to start the security

functions),- the EXIT statement.

• The TPR for a normal return (designated by a call parameter). This TPR includes a callto the subroutine pointing to a SECUR'ACCESS function (for access to the results ofthe controls).

• The TPR for an abnormal return (designated by a call parameter). This TPR includes acall to the subroutine pointing to a SECUR'ACCESS function (for access to the resultsof the controls).


5-12 47 A2 17UG Rev00

The developer responsible for inserting a control point in an application needs to:

• modify the calling TPR and the TPR for a normal return• create a TPR for an abnormal return.

This general method does not enable you to insert a control point at the beginning of aTPR called directly as a transaction. In this case you have to:

• create a TPR for 'beginning of transaction' to act as the calling TPR• link this TPR with the TPR for transaction processing. (This second TPR acts as the

TPR for a normal return.)

5.3.3 Control on Access to Transactions

This type of access control does not depend on whether GCOS 7 is used with or withoutSECUR'ACCESS. It does not require any applications to be developed. It is based on:

• The set of 32 authority codes attached to the Project in the catalog base (managed bythe System Administrator via MAINTAIN_CATALOG). This set is in the form of an 8-byte hexadecimal string, named 'authority mask'. Note that the first authority code isreserved by TDS for the TDS Master Operator.See the System Administrator's Manual.

• The set of authority codes attached to each transaction within a TDS system. This setis defined at TDS generation (with the TDSGEN statement AUTHORITY-CODE) andcan be managed by the Master Operator of the TDS (with the GCL commandMODIFY_TX, or equivalent).See the TDS Administrator's Guide.

A transaction is authorized for the user of a given project if there is at least one authoritycode common to the list of codes attached to his project, and to the codes attached to thetransaction.

Note that the TDS-SA7 administrative service also includes a specific connection control,to check the Main Right (number 799) reserved for access by the TDS-SA7 MasterOperator.

SECUR'ACCESS

47 A2 17UG Rev00 5-13

5.4 TYPES OF DATA IN THE SECURITY BASES

5.4.1 Data in the Catalog Base, Visible in SECUR'ACCESS Mode

5.4.1.1 Identification Data and Rules for Sharing Personal Data

An 'external user' (a potential connected individual) is defined by the completeidentification:

Project.User

Personal data that applies to an external user is attached to the User and Projectidentifiers in one of the two following ways:

User: a password, for example

Project: other personal data. This data is shared by Users attached to the sameProject.

5.4.1.2 Definition of Personal Data

The following data is visible in both SECUR'ACCESS mode and non-SECUR'ACCESSmode. Unless specifically mentioned, it has the same functional visibility when it iscontrolled. However, it is not managed in the same way in the different modes.

• Data attached to the User identifier:- password (different visibility of errors and administrative functions)- default Project- Projects authorized for this User.

• Data attached to the Project identifier:- authorization to access Applications (IOF and TDS services)- authority code to access TDS transactions.

• Specific IOF data attached to the Project identifier:- operator attributes (MAIN, STATION, RMS)- usable STATION and BILLING entities.


5-14 47 A2 17UG Rev00

5.4.2 Security Data Related to TDS Transactions

This data is managed in the same way in both SECUR'ACCESS and non-SECUR'ACCESS modes.

The System Administrator manages the authority codes in the catalog base. Refer to theSystem Administrator's Manual.

The TDS Master Operator manages the authority masks attached to TDS transactions,using the GCL command MODIFY_TX (AUTHORITY_CODE parameter), or equivalent.The initial value of these masks is set at TDS generation. See the TDS Administrator'sGuide.

5.4.3 The SECUR'ACCESS Base

5.4.3.1 Content and Structure of the SECUR'ACCESS Base

The SECUR'ACCESS base contains security data that is specific to access controls andto the administration of SECUR'ACCESS mode. There are two types:

• permanent data,• operational data.

This base corresponds to an IDS/II base, manipulated in a TDS environment (mainly bythe TDS-SA7 administrative service).

5.4.3.2 Identification Data

In SECUR'ACCESS mode, an external user must be known as such by the catalog base.Moreover, each of his identifiers (User, Project) must be associated with aSECUR'ACCESS record, grouping various personal data that is complementary to data inthe catalog base.

The creation/deletion of identifiers and the administration of the corresponding entities aredifferent in SECUR'ACCESS mode and non-SECUR'ACCESS mode.

SECUR'ACCESS

47 A2 17UG Rev00 5-15

5.4.4 Security Data Specific to SECUR'ACCESS Mode: Permanent Data

5.4.4.1 Data Attached to a Site

The main manageable security data attached to a site is the following:

• Default values: language, cycle

• General operating parameters:- initial password,- minimum length of password,- number of previous passwords that are not reusable,- maximum number of connection attempts,- minimum level of control (none, password or smart card),- minimum time lapse between control points,- use of a single connection for several successive users (not described in this

document).

• List of Main Rights and locks to be recorded in the file 'Supervisory journal ofSECUR'ACCESS controls'

• List of Projects (see below for data attached to a Project)

• List of Applications (see below for data attached to a managed service)

• List of Security Administrators (relationships between users and administrators)

• List of password renewal cycles (data that is related to users).

5.4.4.2 Personal Data (Attached to the User Identifier)

The main manageable security data attached to a User is the following:

• SECUR'ACCESS user class:- normal user (TDS End User, any IOF user).

• SECUR'ACCESS administrator:- Security Administrator (the SECADMIN Administrator belongs to this class),- Delegate Administrator.

• Passive user (printer).

• Fictitious user (for replacement smart cards).

• Password management:- last values used (non-manageable),- definition of renewal cycle (minimum and maximum frequency of renewal),- action to be taken on password errors:

. maximum number of attempts allowed,

. sanction beyond this number: permanent or temporary refusal,


5-16 47 A2 17UG Rev00

- expiration date.

SECUR'ACCESS

47 A2 17UG Rev00 5-17

• Activity Control:- Maximum time lapse between two connections (refusal after this time lapse).

• Relationships with administrators:- identification of the Security Administrator,- identification of the Delegate Administrator.

• Individual rights:- authorization table for specific SECUR'ACCESS controls (connection controls and

application controls),- status regarding the black list (containing users who are refused access),- status regarding expiration date.

• Personal data:- complementary name,- complementary first name.

5.4.4.3 Personal Data (Attached to the Project Identifier)

The main manageable data attached to a Project is the following:

• Authentication control level,• 'Privileged project' attribute.

5.4.4.4 Data Attached to an IOF or TDS Managed Service (Via the Application Name)

The main manageable security data is the authentication control level.

5.4.4.5 Data that is Invariable After Installation

This data corresponds to the screens and messages of an application (according to thelanguage used).


5-18 47 A2 17UG Rev00

5.4.5 Data in the SECUR'ACCESS Base: Operational Data

Three lists of records exist in the SECUR'ACCESS base with a more or less implicitvisibility.

Records Concerning the Context of the Person Connected

A record of this type is created (creation of a connected subject) after a successfulconnection procedure. It is deleted if the connection terminates normally. It is saved forthe duration of the connection, to allow for reconnection in the case of an abnormaldisconnection.

Records Awaiting Validation

A record of this type corresponds to an operation of creation or modification of personaldata in the SECUR'ACCESS base that is awaiting validation by a SECUR'ACCESSadministrator (Security Administrator or Delegate Administrator).

Archived Records

A record of this type corresponds to the 'before modification' or 'before deletion' image ofUser data. It is destined for consultation.

5.4.6 Complementary Files Specific to SECUR'ACCESS Mode

When GCOS 7 is used with SECUR'ACCESS, a record is added to the 'supervisoryjournal' in the cases listed below.

• For each incorrect execution of a connection control:- connection refusal by the catalog (identification, authentication, access to the

managed service)- connection refusal by SECUR'ACCESS (black list, expired password).

• For access controls performed by SECUR'ACCESS on Main Right numbers and locksselected by a SECUR'ACCESS administrator's command.

• For each detection of an integrity defect related to SECUR'ACCESS.

Access to transactions is not supervised.

The contents of this file can be examined using administrators' commands (selection viathe User identifier, displaying the contents of a record).

SECUR'ACCESS

47 A2 17UG Rev00 5-19

5.5 ADMINISTRATION OF THE SECURITY BASES

5.5.1 Relationships Between the Catalog Base and the SECUR'ACCESSBase

5.5.1.1 Consistent Installation of the Bases

If the SECUR'ACCESS facility is added to a site that is already operational, you caninitialize the contents of the SECUR'ACCESS base by running a utility that will align it withthe catalog base.

After this initialization, all administrative operations are the responsibility of:

• either the System Administrator, for the catalog base,

• or the TDS-SA7 administrative service (SECUR'ACCESS administrators) for theSECUR'ACCESS base.

5.5.1.2 Consistent Evolution of the Bases: Management of User Entities

A unified vision of the catalog and SECUR'ACCESS bases can be offered toadministrators by using a configuration option (CONFIG utility, SECOPT command,parameter SA7ADMIN=YES). This option guarantees consistency in the evolution of thetwo bases.

In this mode of administration, the IOF commands to create/delete/modify a catalogedUser object are not available to the System Administrator.

The commands available in the TDS-SA7 administrative service enable:

• the creation/deletion/modification of a User entity from the aligned security bases,

• the modification of a password. (This information features in the catalog only; theSECUR'ACCESS base is not modified.)

5.5.1.3 Independent Evolution of the Bases

If you have a specific need, you can allow the catalog base to evolve separately from theSECUR'ACCESS base by using a configuration option (CONFIG utility, SECOPTcommand, parameter SA7ADMIN=NO). The alignment utility will realign theSECUR'ACCESS base with the new status of the catalog base.


5-20 47 A2 17UG Rev00

5.5.1.4 Management of the Project and Application Entities

SECUR'ACCESS administrative commands do not include creating or deleting Project orApplication objects in the catalog base. (See, in the System Administrator's Manual, theMAINTAIN_CATALOG command, accessible to the System Administrator.)

Operations of creating or deleting Project or Application records in the SECUR'ACCESSbase apply only to SECUR'ACCESS complementary data, that is distinct from the data inthe catalog.

A connected person's Project identifier is required to perform controls on the data in thecatalog base. The Project identifier used can be either of the following:

• In the case of User creation, the Project is supplied with the command. The Project'sexistence in the catalog base is controlled.

• When data attached to the Project identifier in the catalog base is controlled, theProject of the connection context is used.

5.5.1.5 Management of the Billing and Station Entities

See the System Administrator's Manual.

5.5.2 The Different Classes of SECUR'ACCESS Administrators

The following are considered to be administrators of GCOS 7 with SECUR'ACCESS:

• All SECUR'ACCESS administrators (described further on), which are:- the Security Administrators (especially the SECADMIN administrator)- the Delegate administrators (created by the Security Administrators)

• The System Administrator in the context of an IOF service (administration of thecatalog base)

• The TDS-SA7 Master Operator

NOTE: Updates to the GCOS 7 catalog base are not always immediately transferred toapplications. This fact must be taken into account during administrativeoperations.

SECUR'ACCESS

47 A2 17UG Rev00 5-21

5.5.3 The Roles of SECUR'ACCESS Administrators and Users

5.5.3.1 Security Administrators

• They do not have access to TDS application services. Their tasks are purelyadministrative. They can be protected with the control level of a password or a smartcard.

• They are required, when personal data in the SECUR'ACCESS base is modified, tovalidate the base, in order for the modified base to become operational. (See theSIGNATURE WAIT file).

An example of an operation that requires validation is: the creation of a User requestedby a Delegate Administrator (or by the Security Administrator himself).

• They manage black lists, and modifications to password cycles. They restorepasswords to their initial state....

• A Security Administrator may be put on the black list, or deleted, by another SecurityAdministrator, provided that two Security Administrators remain, as this is the minimumnumber for a site.

5.5.3.2 The SECUR'ACCESS SECADMIN Administrator

• This specialised SECUR'ACCESS security administrator is mandatory on a site. He isassociated with reserved identifiers (SECADMIN User, SYSADMIN Project) that arecreated when SECUR'ACCESS is installed.

• When there is a failure in the SECUR'ACCESS security functions, the connectionprocedure is blocked. In such a case, the SECADMIN administrator has all the rightsto connect and unblock the situation. See the SECUR'ACCESS Customer ServiceBulletin.

• The SECADMIN Administrator cannot be put on the black list.

• The confidentiality of his password is essential.

5.5.3.3 SECUR'ACCESS Delegate Administrators (Optional)

• They have access to TDS application services (depending on their authorization), likeTDS End Users.

• They have a limited number of administrative functions.

• Each Delegate Administrator manages his own list of End Users.


5-22 47 A2 17UG Rev00

• The operations of creating/deleting a User, or modifying personal data, can beperformed by a Delegate Administrator but must be validated by a SecurityAdministrator.

5.5.3.4 End Users

• A SECUR'ACCESS End User has access to IOF and TDS services.

• He does not have administrative functions concerning security, except the function ofrenewing his individual password.

• An End User may, or may not, be attached to a Delegate Administrator.

• An End User is created after installation of SECUR'ACCESS, by a SecurityAdministrator or a Delegate Administrator.

• When SECUR'ACCESS is installed on a site that is already operational, the Users inthe catalog base are integrated in the SECUR'ACCESS base with the status of EndUser.

5.5.3.5 Internal Passive Users (or Pseudo-Users)

These are passive terminals that require a connection to be made (printers). They arevisible to SECUR'ACCESS administrators.

5.5.3.6 Internal Fictitious Users

These are replacement smart cards, waiting to be allocated to a user. They are visible toSECUR'ACCESS administrators.

SECUR'ACCESS

47 A2 17UG Rev00 5-23

5.6 STARTING GCOS 7 OPERATIONS WITH SECUR'ACCESS

5.6.1 The GCOS 7 STARTUP Sequence

The method applied aims to automate system startup as much as possible, by eliminatingthe possibilities of error in the operator dialog. The GCOS 7 STARTUP mechanismallows an automatic dialog (via IOF commands) that is independent of connection controlson external users (no authentication, no control on access to IOF or TDS services, noSECUR'ACCESS control).

Cataloged rights to use the file system are those of the Project declared in the catalogwith the MAIN operator attribute.

5.6.2 The Two Jobs Started by the Regular STARTUP Sequence

The STARTUP sequence described supposes that the SECUR'ACCESS base includesan external User with the TDS-SA7 Master Operator attribute. It includes the followingtwo job entry requests (ENTER_JOB_REQ):

• The SA7-MASTER job examines the status of the SECUR'ACCESS TDS job, or moreprecisely, the status of associated DSA entities that it represents (DSA mailboxes thatdesignate TDS services). It attempts, periodically, to make an automatic connection(without an external user) to the TDS-SA7 Master Operator's mailbox.

• The SA7-LTDS job initializes all the internal resources required by the TDS-SA7 system(such as: filling various tables, initializing secondary memory, activating the twoassociated mailboxes).

When the connection attempt by the first job detects the operational conditions created bythe second job, the following occurs:

• the 'SECUR'ACCESS system' step is activated,• the connection of the TDS-SA7 Master Operator is made,• all the files of the 'SECUR'ACCESS TDS system' step are opened.

5.6.3 The Status of GCOS 7 After the STARTUP Sequence

After execution of the STARTUP sequence, any external user may connect (having gonethrough the usual connection controls regarding the catalog and SECUR'ACCESS) to:

• either TDS-SA7,

• or the IOF system (the connection to IOF requires TDS-SA7 to be activated),


5-24 47 A2 17UG Rev00

• or a TDS application.

5.6.4 Anomalies During the STARTUP Sequence

When an anomaly is detected in the components that are activated by the two startupjobs, the standard treatment of anomalies (asking the operator a question) does not apply.Therefore you must:

• either configure the system console for GCOS 7 without SECUR'ACCESS,

• or declare an automatic sequence of responses to errors.

The SECUR'ACCESS SECADMIN Administrator and the Main Operator may, however,connect under any circumstance.

5.6.5 Starting the First Operation (The SECUR'ACCESS Base is Empty)

The first external User to connect is the SECUR'ACCESS SECADMIN Administrator (theSECUR'ACCESS mailbox of TDS-SA7). This initial connection allows him to declareother security administrators, and to attribute the rights of the TDS-SA7 Master Operator,so that the normal STARTUP sequence can take place.

47 A2 17UG Rev00 6-1

6. Protection of Data in a GCOS 7 Context

This chapter describes data protection in GCOS 7, and defines the rights of access todata. The paragraphs that deal with volumes are mainly of interest to the SystemAdministrator.

6.1 CATALOGED FILE ACCESS RIGHTS

6.1.1 Protection Mechanism (Access Control)

6.1.1.1 Principle of the Access Control Mechanism

A specific operation on the Site Catalog by the System Administrator enforces orinvalidates the protection mechanism.

When the access control mechanism is enforced, each cataloged object is consideredwith its access control list (ACL), which gives the list of authorized projects for each typeof access (READ, WRITE, etc.). This means that every access by every project isregistered as authorized or not. Checking the authorization is performed for every accessrequest by every project.

A "cataloged" flag is present in cataloged files, in the part of the file named "file label").When this flag is set, access to the file is authorized only through the catalog, and theAccess Control Mechanism cannot be bypassed.

The GCOS 7 user should therefore be aware of the particular access right required byeach particular operation, whether in a command language (JCL or GCL) or in aprogramming language (COBOL, GPL, etc.).

The projects and associated items (users, billings, etc.) are stored in the Site Catalogunder the System Administrator's responsibility. For each master directory a uniqueproject is attached with the OWNER right (by the System Administrator SYSADMIN). Thisowner project has the OWNER right for all objects below the master directory.


6-2 47 A2 17UG Rev00

As a general rule, creation/deletion operations can be executed by the owner project only(but the SYSADMIN project is always authorized for any operation). The owner projectcan set up the access rights for other projects, but cannot change the OWNER status.

The other rights READ, WRITE, etc. correspond to a list of classes of operations on thefile system. For a full description of the user's visibility, see below.

For an exhaustive description of the System Administrator (project SYSADMIN) , see theGCOS 7-V6 System Administrator's Manual.

6.1.1.2 Files, Catalogs and Generation Groups

The full range of operations on these objects corresponds to the following pre-definedordered list of possible rights:

NULL < LIST < EXECUTE < READ < WRITE < RECOVERY < OWNER

When a right is authorized for a project, all lower rights are authorized too. RightsEXECUTE to RECOVERY correspond to the usual operations on a file system.

The NULL right (explicit absence of rights) attached to a project P1, represents theabsence of any right for the project P1.

The NULL right is used to explicitly exclude a project in case of a star notation. Thefollowing list of access rights means that P1 does not have the READ right:

• NULL: P1

• READ: *

• OWNER: P4

The star list designates all projects which are not explicitly assigned to a given right.

6.1.1.3 Directory Access Rights, Hierarchical Propagation

The ordered list of possible rights is the same, but the interpretation of these rights isdifferent.

The OWNER right allows the creation/deletion of entries (for sub-directories, filedescriptions, file links) and the setting of rights to other projects.

The LIST right allows you to display the content of a directory object.

Other rights are considered in the propagation mechanism only.

Protection of Data in a GCOS 7 Context

47 A2 17UG Rev00 6-3

It is important to note the following points on the automatic propagation of access rights:

• When the owner project sets up the right attached to a given directory (for a givenproject), this right is automatically propagated to all dependent objects at any level(whether directories, files or file links), thus overwriting any previously defined right forthe relevant project.

• When a file description is created it automatically inherits the access rights attached toits immediate directory. Its access rights can be explicitly re-defined at file level, orimplicitly by downward propagation resulting from redefining an upper directory. Whensetting access rights at several levels the order of operations is significant.

This shows that directory access rights support two roles:

• Propagating access rights downward: this rule applies to all access rights.

• Enable the authorization checking for specific operations on an explicit directory(OWNER right, LIST right).

Note that no checking is performed when a directory is not explicitly accessed, but merelyused to resolve an intermediate component name in a path name. The unused accessrights at intermediate level are not restricted in any way. The right attached to the final filedescription is the only significant right.

6.1.1.4 File Links

File link objects are not associated with any right. All projects can use them. Accesschecking is performed on the final object referred to by the file link. Only the owner candelete file links.

6.1.2 Access Rights Hierarchy

The following hierarchy applies to access rights for cataloged files. The symbol >indicates that an access right is stronger than, and includes, all those to the right of it inthe list.

OWNER > RECOVERY > WRITE > READ > EXECUTE > LIST > NULL


6-4 47 A2 17UG Rev00

6.1.3 Files, Catalogs and Generation Groups

The access rights which may be applied to files, file-sets, catalogs, and generation groupsare explained below.

OWNER This is the most powerful access right for a file. The projectthat is OWNER of a file possesses all rights on the file. It cancreate or delete the file, change the file description and setaccess rights on the file. A file can have only one owner; notehowever that SYSADMIN effectively has all the rights on allthe files, even if it is not the OWNER project.

NULL This indicates that the specified project(s) may not access thefile. It is not possible for such a project even to find out thename of the file. It is used to override rights granted to allprojects by using the star convention.

Between OWNER (the strongest access right), and NULL (the weakest), there is ahierarchy of access rights which allows the access to files to be finely controlled accordingto the needs of the different users. These access rights are as follows:

LIST Allows projects merely to know that the file exists and to listits catalog structure (name, attributes, list of volumes, etc.).The file cannot be processed, and neither its content nor itsACL (Access Control List) can be inspected. LIST should beapplied when the OWNER of a file wants other projects toknow the name and the type of a file he is using, but does notwant the projects to process the file.

EXECUTE Allows project(s) to execute a file. EXECUTE includes theLIST access right. EXECUTE allows the transfer to GCOS 7of load modules, or of JCL files or GCL files in order toexecute them. You cannot copy the file or read its contents.

READ Allows project(s) to read and copy a file. It includes theEXECUTE access right.

WRITE Allows project(s) to write to a file, to update a file, and toextend it or reduce its size. It includes the READ access right.When applied to catalogs, it allows you to attach themautomatically, using the GCL commandATTACH_CATALOG, or by calling the JCL statementATTACH. When applied to libraries, it allows you to createnew members or delete existing ones.


47 A2 17UG Rev00 6-5

RECOVERY Includes the WRITE access right. It is used in the followingcircumstances:

- When dealing with a generation group, you need theRECOVERY access right to call the JCL statementSHIFT or the GCL command SHIFT_GEN.

- When a step updating a file journalised withJOURNAL=PRIVATE aborts, the file is placed in abortlocked state. To recover the file, you must have theRECOVERY access right.

- You need the RECOVERY access right to reset an abortlock on a file using the UNLOCK parameter of the JCLstatement CATMODIF (or the GCL commandMODIFY_FILE).

- You must have the RECOVERY access right to callFILCHECK for a file (sequential or library files only).

NOTES: 1) In the case of generation groups, access rights may not be set on aspecific generation, but only on the whole group.

2) In the case of file-sets, access rights are set on each individual filein the set. To use a file-set utility which demands a specific accessright, you must have that access right set on every file in the set. Ifyou have the access right for some files in the set and not forothers, the action taken depends on the value of the EVENTparameter. If EVENT=SKIP, the file you cannot access is ignored,and the next file in the set is processed. If EVENT=TALK, theexecution of the utility is aborted, and you are returned to systemlevel. You can then decide to resubmit the command with a morerestricted file-set or use the option EVENT = SKIP.

6.1.4 Directories

Cataloged files are grouped together under directories, and as directories are catalogedobjects, the access rights that apply to files can also be applied to directories.

The three access rights that are specific to directories are OWNER, LIST, and NULL.

OWNER As for files, this is the most powerful access right. It allowsthe OWNER project to create and delete entries for sub-directories and files, and to give access rights to otherprojects.

LIST This allows projects to list the existing catalog structure, butdoes not allow projects to process this structure in any way.

NULL In the same way as for files, this access right gives completeprotection and denies the specified project(s) access to thedirectory. It is used to override rights granted to all projectsby using the star convention.


6-6 47 A2 17UG Rev00


47 A2 17UG Rev00 6-7

6.1.5 Access Rights to Cataloged Files

In the following examples, the commands that you must use to perform the specifiedfunctions are given in both GCL (GCOS Command Language), and JCL (Job ControlLanguage). The GCL is given first, followed by its JCL equivalent.

Example 1

a) Project PROJ is the owner of directory DIR1, and there are no other access rightsset on DIR1. The project PROJ can create and delete sub-directories and files, andcan give access rights on DIR1 and any sub-directories and files to other projects.All other projects are prohibited from accessing DIR1.

As each cataloged file can be accessed only through the catalog, which contains theaccess right information, it is impossible to avoid the access rights mechanism.

b) Some files are now created under the directory DIR1, so the structure becomes:

DIR1

DIR1.F1 DIR1.F2

O W N E R : P R O J

DIR1.F100

If PROJ wants to give an access right (READ for example) to all projects on all the files,this can be done as follows:

1) The access right READ is given at file level to all projects by using the GCLprocessor MODIFY_ACL as follows:

MODIFY_ACL NAME=DIR1.F1 PROJECT=*/READ; MODIFY_ACL NAME=DIR1.F2 PROJECT=*/READ; . . . MODIFY_ACL NAME=DIR1.F100 PROJECT=*/READ;

Alternatively, the JCL statement CATMODIF may be used:

CATMODIF DIR1.F1, READ=*; CATMODIF DIR1.F2, READ=*; . . . CATMODIF DIR1.F100, READ=*;


6-8 47 A2 17UG Rev00

2) The READ access right is given globally at directory level and thus to all the lowerlevels. This is the easiest method, as only one statement is required. In GCL this is:

MODIFY_ACL NAME=DIR1 PROJECT=*/READ TYPE=DIR;

In JCL it is :

CATMODIF DIR1, TYPE=DIR, READ=*;

If the second method is used, any files created subsequently under DIR1 willautomatically have the READ access right set for all projects.

NOTE: In this example READ=* and */READ have been used instead ofREAD=(PROJ1, PROJ2 ...) , or (PROJ1/READ, PROJ2/READ), but it is alwayspossible to set the access rights for specific projects.

c) Given the structure of the previous example (b), and assuming (b) has already beenperformed:

DIR1

DIR1.F1 DIR1.F2 D IR 1.F100

O W N E R : P R O JR E A D :*

The following access rights are now to be set by the project PROJ:

DIR1.F1 All projects can write to the file.DIR1.F2 Projects P1, P2 can write to the file and the other projects can read it.DIR1.F3 No project can access the file.DIR1.F4 Project P3 can read the file; no other project can access it.

This is done as follows:

GCL

MODIFY_ACL NAME=DIR1.F1 PROJECT=*/WRITE;

MODIFY_ACL NAME=DIR1.F2 PROJECT=(P1/WRITE P2/WRITE); P1 and P2 may WRITE to the file F2: all other projects may READ it.

MODIFY_ACL NAME=DIR1.F3 DELETE=*; MODIFY_ACL NAME=DIR1.F4 DELETE=*; Any access rights on files F3 and F4 set using the star convention for the projects

are overridden; no project can access them except the OWNER and SYSADMIN.

MODIFY_ACL NAME=DIR1.F4 PROJECT=P3/READ; The READ access right has been reset for the project P3 on the file F4 only.


47 A2 17UG Rev00 6-9

JCL

CATMODIF DIR1.F1, WRITE=*; CATMODIF DIR1.F2, WRITE=(P1,P2); CATMODIF DIR1.F3, DELETE=*; CATMODIF DIR1.F4, DELETE=*; CATMODIF DIR1.F4, READ=P3;

d) If, using the same example as above, PROJ now wished to create sub-directorieswith the following specific access rights:

DIR-A WRITE for all projectsDIR-B READ for all projectsDIR-C no access for all projects

This would be done as follows:

GCL

CREATE_DIR NAME=DIR1.DIR-A; MDACL NAME=DIR1.DIR-A PROJECT=*/WRITE TYPE=DIR;

This first statement creates the sub-directory DIR-A. The second statement sets theWRITE access right for all projects.

CREATE_DIR NAME=DIR1.DIR-B;

This statement creates the sub-directory DIR-B. The READ access right is impliedautomatically from DIR1.

CREATE_DIR NAME=DIR1.DIR-C;

This statement creates the sub-directory DIR-C. The READ access right is impliedautomatically from DIR1.

MDACL NAME=DIR1.DIR-C DELETE=* TYPE=DIR;

This removes access rights for all projects to sub-directory DIR-C, except for PROJ(the OWNER), and SYSADMIN.

JCL

The equivalent statements in JCL are as follows:

CATALOG DIR1.DIR-A, TYPE=DIR WRITE=*; CATALOG DIR1.DIR-B, TYPE=DIR; CATALOG DIR1.DIR-C, TYPE=DIR; CATMODIF DIR1.DIR-C, TYPE=DIR, DELETE=*;


6-10 47 A2 17UG Rev00

Example 2

Consider the following type of structure:

R O O T

D IR 1 D IR 2 D IR 3

S ite C atalog

O W N E R 1 O W N E R 2 O W N E R 3

The following always applies to such catalog structures:

• The OWNER access right can be set only on master directories and only by theSYSADMIN project.

• The OWNER, once given, cannot be changed at a lower level.

• The OWNER can always process the structure.

If the files are stored in the catalog at the first level under the root, they may also beprotected by an OWNER access right given by SYSADMIN. However, it is advisable notto create files directly under the root.

It is also advisable to catalog user files in private catalogs and not in the SITE.CATALOG.


47 A2 17UG Rev00 6-11

Example 3

This example uses the DELETE parameter of the GCL command MODIFY_ACL and theJCL statement CATMODIF. The DELETE parameter allows you to specify one or moreprojects whose access rights are to be suppressed. The access rights attached to oneproject, several projects or all projects are deleted at all levels of the catalog structurefrom the specified level up to the level where the modified object resides. Consider thestructure:

R O O T

D E P T1

D 1

D 2

F 2

F 1 R E A D : P 2

W R ITE : P 2

If the project P wants to delete the access rights of the project P2 from all objects abovethe directory DEPT1.D1.D2, he uses either the GCL statement:

MDACL DEPT1 DELETE=P2/1 TYPE=DIR;

Or the JCL statement:

CATMODIF DEPT1, TYPE=DIR, DELETE=(P2,(LEVEL=1));


6-12 47 A2 17UG Rev00

This deletes all access rights of P2 down to level 1 of the catalog, so the structurebecomes:

R O O T

D E P T1

D 1

D 2

F2

F 1

W R ITE : P 2

LEVEL0

LEVEL1

LEV E L2

LEVEL3

P2 has lost all access rights at all levels from level 1 up to the modified object (DEPT1).The WRITE access right is still valid for levels below level 1 (levels 2 and 3 in thisexample).


47 A2 17UG Rev00 6-13

Example 4

This example sets access rights on a private catalog. Suppose you have the privatecatalog X.CATALOG:

S ite C atalog

X

C A TA LO G

X .C A TA LO G

O W N E R : PO W N E R : P

For a project (P2 in this example) to be able to access any of the objects in X.CATALOG,two conditions must be met: P2 must have WRITE access to X.CATALOG andX.CATALOG must be attached (automatically or explicitly) to P2's jobs. The owner ofX.CATALOG, called project P in this example, must therefore set the WRITE access righton the catalog for P2. This is done using either the GCL processor MODIFY_ACL(MDACL) or the JCL statement CATMODIF as follows:

MDACL NAME=X.CATALOG PROJECT=P2/WRITE;CATMODIF X.CATALOG, WRITE=P2;

The project P2 can now attach or access the catalog X.CATALOG.

Access rights within the catalog can be set on specific objects. For example, project P2can be given WRITE access on the master directory DEPT1 and on the structuredescending from it, using the GCL command:

MDACL NAME=DEPT1 PROJECT=P2/WRITE TYPE=DIR;

or the JCL command:

CATMODIF DEPT1, TYPE=DIR, WRITE=P2;

(Note that if the catalog is not automatically attachable, it must be attached first).


6-14 47 A2 17UG Rev00

Another, simpler, way of setting access rights on cataloged objects is to do it globally,using the MDACL NAME=*, ...; GCL command or the CATMODIF *, ...; JCL statement.This sets the access rights for a project on the catalog root, and thus on the entirestructure of, and all the objects in, the private catalog (this rule is not applicable to theSITE.CATALOG). For example, if you want to give project P1 WRITE access on all theobjects of catalog X.CATALOG, the statements would be:

in GCL:

MDACL NAME=* PROJECT=P1/WRITE;

or in JCL

CATMODIF *, WRITE=P1;

(If X.CATALOG is not automatically attachable, it must be attached first).

If you want to set the READ access right for projects P2 and P3 and the LIST access rightfor project P4, the statement would be:

in GCL:

MDACL NAME=* PROJECT=(P2/READ P3/READ P4/LIST);

or in JCL:

CATMODIF *, READ=(P2, P3), LIST=P4;


47 A2 17UG Rev00 6-15

6.2 VOLUME ACCESS RIGHTS

Depending on the degree of protection you require, disk and tape volumes can beprotected or unprotected. If volumes are unprotected, each and every access to acataloged file is controlled, but it is possible for any user to allocate and deallocate spaceon these volumes.

The OWNER access right on a volume allows the project to:

• create or delete file space on the volume

• prepare the volume (PREPARE_DISK or PREPARE_TAPE in GCL, and VOLPREP inJCL)

• save or restore the volume (disks only).

It is also possible to make all projects the owner of a volume. This type of ownershipallows all projects to allocate and deallocate space on the volume, but only the SystemAdministrators can use the volume as an output volume for the GCL processorsPREPARE_DISK, PREPARE_TAPE or RESTORE_DISK, and the JCL utilities VOLPREP,VOLREST, etc.

In addition to the notion of owning the space on a volume, there is also the concept ofowning a volume name. In a protected environment, when a project names its volumesheld on disk or tape, it may only use names which belong to a set of volume names, (oneset for disk volumes, one set for tape volumes), previously allocated to the project by theSystem Administrators.

Note that if the System Administrators do not allocate these two sets of volume names,the project cannot call the JCL utility VOLPREP, or the GCL processors PREPARE_DISKor PREPARE_TAPE to label and format a volume.

Example of Additional Control on Volumes

If the project FIMA wants to prepare a disk or tape, as well as needing the OWNERaccess right on the volume, it can only do so if the old and new volume names were givenby SYSADMIN in the MSVOL or MTVOL parameter of MAINTAIN_CATALOG (orCATMAINT) when FIMA was created. These parameters specify which volumes can beprepared by a project. If the MSVOL parameter is given the values:

.., MSVOL=(K001, K002, K003, K004), ..

the GCL command:

PREPARE_DISK INVOL=K001:MS/B10 OUTVOL=K005:MS/B10;

and the JCL statement:

VOLPREP OLD=(DVC=MS/B10, MEDIA=K001), NEW=(DVC=MS/B10, MEDIA=K005);


6-16 47 A2 17UG Rev00

will fail, because the volume K005 does not exist in the list of volumes that can beprepared by FIMA.


47 A2 17UG Rev00 6-17

The statements:

PREPARE_DISK INVOL=K001:MS/B10 OUTVOL=K004:MS/B10;

and

VOLPREP OLD=(DVC=MS/B10, MEDIA=K001), NEW=(DVC=MS/B10, MEDIA=K004);

can be called by the project FIMA. In this case, the volume K004 remains protected withthe project FIMA as the OWNER of the volume.

The MAINTAIN_CATALOG (CATMAINT) commands are described in the SystemAdministrator's Manual.

The GCL processors PREPARE_DISK, PREPARE_TAPE and MODIFY_DISK are fullydescribed in Part 2 of the IOF Terminal User's Reference Manual.

VOLPREP is described in the Data Management Utilities User's Guide.


6-18 47 A2 17UG Rev00

6.3 CHECKING ACCESS RIGHTS

All access right controls (except the OWNER access right) are performed when the objectto be accessed is assigned to the program.

The OWNER access right is checked at execution time only by the processors andutilities which require it.

6.3.1 Checks Made at ASSIGN Time

You can specify the type of access which you require on a file using the parameter

{ READ } { SPREAD }ACCESS= { ALLREAD } { WRITE } { SPWRITE } { RECOVERY }

This parameter is specified either as one of the GCL File Assignment Parameters or inthe JCL statement ASSIGN.

Rights of access to files are checked when the files are assigned, (except for the OWNERaccess right which is required by certain processors and utilities).

File access rights are checked as follows:

If a project P wants to access a file with ACCESS=X, and the project has the access rightA on the file, where A is one of the access rights described in 6.1, the project can accessthe file if A >= X. Table 6-1 summarizes the access right controls. If access to a file is notallowed, one of the following messages is written to the Job Occurrence Report (JOR) forthe job concerned:

DS06. efn FILE ACCESS RIGHTS VIOLATIONDCT77. file-name FILE ACCESS RIGHT VIOLATIONDCT78. directory-name DIRECTORY ACCESS RIGHT VIOLATIONDCT82. file-link-name FILE LINK ACCESS RIGHT VIOLATION


47 A2 17UG Rev00 6-19

Table 6-1. Summary of Access Right Controls

Type o fA ccess

A ccessR ight ofP rojec t

E X E C U T E *R E A DS P R E A DA LLR E A D

W R IT ES P W R ITE R E C O V E R Y

N U LL

LIS T

E X E C U T E

R E A D

W R IT E

R E C O V E R Y

O W N E R O .K .

O .K .

O .K .

O .K .

O .K .

O .K .

O .K .

O .K .

O .K .

O .K .

O .K .

O .K .

O .K .

O .K .

Shade denotes an access rights violation, which is recorded in the system accounting file,SYS.ACT1 or SYS.ACT2, and in the GCOS 7 security log, AUDIT 7.

* EXECUTE cannot be specified as a value for ACCESS. It can only be set by certainJCL, GCL and OCL commands that require EXECUTE as the minimum access right.These commands are as follows:

JCL GCL OCL

EXECUTE ENTER_JB_REQUEST ENTER_JB_REQUEST

INVOKE EXEC_PG PREINITIALIZE_LOAD_MODULE

RUN START_INPUT

STEP START_JOB

If a project attempts to execute a job for which it does not have the EXECUTE accessright set, the project is rejected and the command fails.


6-20 47 A2 17UG Rev00

6.3.2 Checks Made by File Level Processors and Utilities

These checks are, in most cases, similar to those performed by file assignment. Ingeneral the rules are as follows:

1) If you are using a processor or a utility which operates on files or file-sets and youuse one of the parameters INFILE, INLIB(i) or COMFILE, the file is assigned to youwith ACCESS=READ as the default.

2) If you are using a processor or a utility which operates on files or filesets and you useone of the parameters OUTFILE, PRTFILE, LIB or OUTLIB, the file is assigned toyou with ACCESS=WRITE as the default.

However, in this case, ACCESS=READ may be specified if the processor or utility whichyou are using only generates a READ operation.

For example, if the processor or utility is MAINTAIN_LIBRARY or LIBMAINT you can callthe following commands with ACCESS=READ:

COMPAREEDIT (WRITE if Z or W are used)FSE (WRITE if SV or SVQ are used) (MAINTAIN_LIBRARY ONLY)LISTPRINT

The exceptions to rules 1) and 2) above are given in Table 6-2. For processors andutilities that allocate and deallocate space (CREATE_CATALOG, DELETE_CATALOG,CREATE_FILE, CREATE_FILESET, DELETE_FILESET, BUILD_LIBRARY,DELETE_LIBRARY, BUILD FILE, in GCL; CATBUILD, CATDELET, DEALLOC,FILALLOC, LIBALLOC, LIBDELET and PREALLOC in JCL) or which request the dynamicallocation of space for the output file (the parameters DYNALC and ALLOCATE in GCL;OUTALC and PRTALC in JCL), the project must be allowed to create or delete a file onthe given volumes (see the checking of the OWNER access right on volumes).

Some processors and utilities are reserved for use by the project SYSADMIN. (Refer toTable 6-2.)

This is because:

a) The files are reserved for use by SYSADMIN only,

b) Certain parameters of these processors and utilities bypass the standard systemcontrols.


47 A2 17UG Rev00 6-21

Table 6-2. Access Rights Required by File Level Processors (GCL) (1/3)

U T IL IT YM IN IM U M A C C E S S R E Q U IR E D

C O M M E N T ST arget ob jec t

S econd ta rge tobjec t, if any

A T T A C H _C A T A LO G

C atalog au tom atic attachm ent

B U ILD _FILE

C H E C K _C A T A LO G

C LE A R _F ILE

C LE A R _LIB R A R Y

C O P Y_C A T A LO G

C O P Y_FILE

C O P Y_FILE S E T

C R E A T E _C A T A LO G

C R E A T E _D IR

C R E A T E _F ILE

C R E A T E _F ILE _D E S C

C R E A T E _F ILE S E T

C R E A T E _G E N

C R E A T E _LIN K

C R E A T E _M T _F ILE

D E LE T E _C A T A LO G

D E LE T E _D IR

D E LE T E _F ILE

D E LE T E _F ILE S E T

D E LE T E _G E N

D E LE T E _LIB R A R Y

D E LE T E _LIN K

W R IT E

W R IT E

O W N E R

O W N E R

W R IT E

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

A LLR E A D

O W N E R

A LLR E A D

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

S YS A D M IN w hen FO R C E is used




6-22 47 A2 17UG Rev00





E N T E R _F ILE _T R A N S _R E Q

E N T E R _JO B _R E Q U E S T

E X E C _P G

LIS T _A C L

LIS T _C A T A LO G

LIS T _D IR

LIS T _F ILE

LIS T _F ILE S E T

LIS T _F ILE _S P A C E

LIS T _G E N

LIS T _LIN K

M A IN T A IN _C A T A LO G

M A IN T A IN _F ILE

M O D IFY_A C L

M O D IFY_C A T A LO G

M O D IFY_C A T S P A C E

M O D IFY_FILE

M O D IFY_FILE _S P A C E

M O D IFY_FILE _S T A T U S

M O D IFY_G E N

R E A D

E X E C U T E

E X E C U T E

LIS T

L IS T

LIS T

R E A D

R E A D

R E A D

LIS T

L IS T

S YS A D M IN

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

W R IT E

O W N E R

O W N E R

} R e fer to spec ific } docum enta tion fo r } transfer from / to a rem ote s ite

S YS A D M IN ex cept for M D U

S YS A D M IN to m od ifya p ro jec t O W N E R

S YS A D M IN w hen D E V C LA S S ,M E D IA , V O LS E T , C LR V S E T ,IM P O R T , T E N T H , F O R C E is used



47 A2 17UG Rev00 6-23





M O V E _C A T A LO G

M O V E _D IR

M O V E _FILE

R E S T O R E _C A T A LO G

R E S T O R E _FILE

R E S T O R E _FILE S E T

S A V E _C A T A LO G

S A V E _F ILE

S A V E _F ILE S E T

S H IF T _G E N

O W N E R

O W N E R

O W N E R

R E A D

R E A D

R E A D

O W N E R

O W N E R

O W N E R

R E C O V E R Y

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E R

W R IT E

W R IT E

W R IT E


6-24 47 A2 17UG Rev00

Table 6-3. Access Rights Required by File Level Utilities (JCL)




A T T A C HC A T A LO GC A T B U ILDC A T C H E C KC A T D E LE TC A T E X T DC A T LIS TC A T M A IN TC A T M O D IF

C A T M O V ED E A LLO CE X E C U T EFILA LLO CFILC H E C KFILD U P LIF ILL IS TFILM O D IF

FILM A IN TFILR E S TFILS A V EIN V O K ELIB A LLO CLIB D E LE TP R E A LLO CR E P LA C E

R O LLF W DR U NS H IF TS T E PU N C A T

W R IT EO W N E RO W N E RO W N E RO W N E RO W N E RLIS TS YS A D M INO W N E R

O W N E RO W N E RE X E C U T EA LLR E A DR E C O V E R YO W N E RR E A DO W N E R

O W N E RR E A DO W N E RE X E C U T EO W N E RO W N E RO W N E RO W N E R

R E C O V E RE X E C U T ER E C O V E R YE X E C U T EO W N E R

O W N E R

O W N E R

O W N E R

O W N E R

O W N E RW R IT E

O W N E R

S YS A D M IN ex cept for M D US YS A D M IN w hen D E V C LA S S ,M E D IA , V O LS E T , C LR V S E T ,T E N T H , is used, o r to m od ifya p ro jec t O W N E R


W R IT E if F ILM O D IF C LR D A T AS YS A D M IN w hen FO R C E is used

S YS A D M IN w hen D E V C LA S S andM E D IA are used fo r O U T F ILE


47 A2 17UG Rev00 6-25

6.3.3 Checks Made by Volume Level Processors and Utilities

Access to files at volume level is in most cases performed serially; i.e. the first file in thevolume is processed, then the second, then the third etc. This is why, as a general ruleaccess controls are performed file by file. Tables 6-4 and 6-5 give the controls performedby the GCL and JCL volume processors and utilities respectively. Note that the ownershipof a volume only gives the OWNER access right on the volume, and not on the files thatthe volume contains. (See "Volume Access Rights" earlier in this chapter).

Table 6-4. Access Rights Required by the Volume Level Processors (GCL)

U T IL IT Y

M IN IM U M A C C E S SR IG H T R E Q U IR E D

C O M M E N T SIN P U T

V O LU M EO U T P U TV O LU M E

C LE A R _V O LU M E O W N E R o f a ll f iles and O W N E Rof v o lum e

S YS A D M IN on ly if the F O R C Eparam eter is used

R E A D on filesL IS T _V O LU M E (*) T his is the m inim um access righ trequired to lis t a file on a vo lum e

M A IN T A IN _V O LU M E D IS K : O W N E R o f ca ll cata loged f ilesT A P E : S YS A D M IN on ly

C H A N G E com m and reservedfor S YS A D M IN

O W N E RM O D IF Y_D IS K C T LA C C and O W N E R param etersreserv ed fo r S YS A D M IN

P R E P A R E _D IS K

P R E P A R E _T A P E

P R E P A R E _V O LU M E

O W N E R o f a ll ca ta loged filesand O W N E R o f m ed ia nam e

O W N E R o f vo lum e and O W N E Rof m ed ia nam e

F O R C E , C T LA C C , O W N E Rreserv ed fo r S YS A D M IN

F O R C E , C T LA C C , O W N E Rreserv ed fo r S YS A D M IN

R efer to P R E P A R E D IS K andP R E P A R E _T A P E

R E S T O R E _D IS K

S A V E _D IS K

R E A D O W N E R

W R IT EO W N E R o f a llca ta loged files

* LIST_VOLUME: Only files with at least the READ access right are listed. If theproject which requests the list is not the OWNER of thevolume, certain information such as disk occupancy rate,vacant space rate etc. is not listed. If the project SYSADMINrequests the list, a full description of the volume is given.


6-26 47 A2 17UG Rev00

Table 6-5. Access Rights Required by the Volume Level Utilities (JCL)

U T IL IT Y

M IN IM U M A C C E S SR IG H T R E Q U IR E D

C O M M E N T SIN P U T

V O LU M EO U T P U TV O LU M E

V O LC O M P 1) O W N E R o f a ll ca ta loged files

2) O W N E R o f a ll ca ta loged files

N o G C L equ iva len t

V O LD U P LI O W N E R o f a llca ta loged files

O W N E R o fthe vo lum e

V O LLIS T (*) R E A D on files M inim um right requ ired tolis t a file on the vo lum e

N o G C L equiv alen t

D iskV O LM A IN T

T ape

O W N E R o f a llthe cata loged files

S YS A D M IN on ly

C H A N G E com m and reservedfor S YS A D M IN

V O LM O D IF w ith O W N E R ,C T LA C C , N C T LA C C

S YS A D M IN on ly (w ith thecontro l tha t a ll the fileshav e the sam e ow ner ifO W N E R is no t*)

V O LM O D IF w ith B A D T R A C K , F O R G E T ,C O M P LE T E

O W N E R o f the v olum e

V O LP R E P (w ith O W N E Rand C T LA C C , N C T LA C Cor F O R C E )

S YS A D M IN on ly

V O LP R E P(norm al)

O W N E R o f a llthe cata loged files (d isk)or O W N E R of the vo lum e(tape) + m ed ia nam eow ner

V O LR E S T R E A D on the inpu t file O W N E R o fthe vo lum e

V O LS A V E O W N E R o f a llca ta loged files

W R IT E on theoutpu t vo lum e

* VOLLIST: See the note for LIST_VOLUME under Table 6-4.

NOTE: A "work" tape cannot be protected by either PREPARE TAPE (GCL) orVOLPREP (JCL).


47 A2 17UG Rev00 6-27

6.4 FILE SECURITY PROCEDURES FOR THE SYSTEM ADMINISTRATOR

6.4.1 Setting Up Access Rights on the System

The System Administrator, via the project SYSADMIN, is responsible for setting up all theaccess rights on the system, in the following order.

1. He must initialize the access rights mechanism by declaring the SYSADMIN projectOWNER of the Site Catalog.

2. He must grant all projects access rights on the SITE directory; starting with WRITEaccess on the SITE.CATALOG file, and then at least READ access on all other SITEfiles. (Remember that WRITE access includes READ access, just as OWNERaccess includes both WRITE and READ access.)

3. He can, if necessary, set access rights on the SYS directory.

4. If other master directories have been created, he should grant individual projectsOWNER access on these directories in the SITE.CATALOG.

5. He should grant projects OWNER access on private catalogs root.

6. He should grant projects OWNER access on individual volumes.

6.4.1.1 Initialising Access Rights on the System

Before the access rights can be applied on the system, they must first be set up. Therequirements for this are:

1. The access rights facility must be available on the site.

2. The user, project, (and optionally billing) information checks in the Site Catalog mustbe validated by the command VAL (see the System Administrator's Manual).

If these requirements have been met, the System Administrator can initialize the accessrights mechanism with the following command:

MODIFY_ACL NAME=* PROJECT=SYSADMIN/OWNER TYPE=DIR CATNAME=SITE;

This makes the SYSADMIN project the owner of the root of the Site Catalog. Now onlySYSADMIN users can create master directories and other objects (though preferably notfiles) directly under the root of the Site Catalog.

NOTE: It is strongly recommended that CATNAME be specified in all uses of theMDACL command , when no catalog has been explicitly attached.


6-28 47 A2 17UG Rev00

6.4.1.2 Setting Access Rights on the Site Catalog

After the access rights mechanism has been initialized (see above), the SystemAdministrator can set access rights on the master directories and files in the Site Catalog.The procedure is as follows:

1. Set OWNER access on the SITE directory

The SYSADMIN project must be the OWNER of the SITE directory and all of the filesunder it (Such as SITE.STARTUP and SITE.CATALOG). The command is as follows:

MDACL SITE TYPE=DIR PROJECT=SYSADMIN/OWNER CATNAME=SITE

2. Set WRITE access on the SITE.CATALOG file

All projects must be given WRITE access to the file SITE.CATALOG. This allows projectusers to catalog objects under the Site Catalog. The command is as follows:

MDACL NAME=SITE.CATALOG PROJECT=*/WRITE TYPE=FILE CATNAME=SITE;

3. Set READ/WRITE access on other SITE files

All projects should have READ access to all files in the SITE directory. Selected projectsshould also have WRITE access to certain files, such as SITE.STARTUP. The followingcommand is an example of what you can do:

MDACL NAME=SITE.STARTUP PROJECT=(*/READ PROJ1/WRITE PROJ2/WRITE) TYPE=FILE CATNAME=SITE;

6.4.1.3 Setting Access Rights on the SYS Files (If Necessary)

It is recommended that only default access rights be set on the system files. This is doneusing the GIUF facility:

PROTECT_GCOS ACCESS_RIGHT=SET

This facility is fully described in the System Installation, Configuration and Updating Guide.


47 A2 17UG Rev00 6-29

6.4.1.4 Setting OWNER Access on Master Directories

After setting READ/WRITE access rights on the SITE directory, the System Administratorcan now grant OWNER access on the other master directories in the Site Catalog.

If the directory does not already exist, it must first be created using the command:

CREATE_DIR NAME=master-directory;

Once the directory exists, the OWNER access rights can be set, using:

MDACL NAME=master-directory TYPE=DIR PROJECT=project-name/OWNER CATNAME=SITE;

Note that OWNER access on a master directory can also be granted at project creationtime, using the command:

CRP project-name,...., MASTDIR;

This automatically makes the specified project the owner of the master directory which iscreated with the same name as the project.

If the project already exists, and the name of the master directory is identical to the projectname (as is recommended), then use:

MDP project-name,...., MASTDIR;

The CRP and MDP commands are fully described in the System Administrator's Manual.

6.4.1.5 Setting Access Rights on a Private Catalog

Access rights on the master directory in the SITE.CATALOG must have been setpreviously. (See the System Administrator's Manual.)

A private catalog must be attached before the OWNER access right can be set on it.

If the catalog is auto-attachable (as is recommended) then there is no need to attach itbefore setting the access right. If it is not auto-attachable, and is not currently attached,then it must first be attached as follows:

ATTACH_CATALOG CAT=catalog-name;

Once the catalog is attached, the OWNER access right can be set, as follows:

MDACL NAME=* PROJECT=project-name/OWNER TYPE=DIR [CATNAME=catalog-name];

The parameter CATNAME is mandatory if the catalog concerned is auto-attachable.


6-30 47 A2 17UG Rev00

Note that users of projects which have no private catalogs can create them using thecommand CREATE_CATALOG. In this case, the OWNER access right is automaticallyset.

6.4.1.6 Setting Access Rights on a Volume

The OWNER access right on a volume is set by the System Administrator using thecommands:

PREPARE_DISK/PREPARE_TAPE for volumes containing no filesMODIFY_DISK for volumes containing files.

6.4.2 Returning to an Unprotected System

In some cases, the System Administrator may wish to cancel the access rights that werepreviously set on the system, either to return to the situation of an unprotected system, orto set new access rights from scratch. The procedure for cancelling the access rights on asystem is as follows:

1. Cancel the OWNER access right on each private catalog

If a private catalog is not auto-attachable, and is not currently attached, it must first beattached before the OWNER access right is cancelled. The command to attach a catalogis:


Once a private catalog is attached, the OWNER access right is cancelled with thecommand:

MDACL NAME=* DELETE=owner-project TYPE=DIR [CATNAME=private-catalog];


2. Cancel the OWNER access right on each protected volume

The command to do this is:

MODIFY_DISK VOL=vol-name:device-class CTLACC=NO;

Then delete the list of volumes that are assigned to projects, using theMAINTAIN_CATALOG command MDP. Enter this command with MSVOL='; orMTVOL=';.


47 A2 17UG Rev00 6-31

3. Cancel the access rights on the system files

If the default access rights were set on the system files using the GIUF functionPROTECT_GCOS, these can be cancelled using:

PROTECT_GCOS ACCESS_RIGHT=RESET;

The SYSADMIN project remains the OWNER of these files.

4. Cancel the access rights on SYS.CATALOG

If SYS.CATALOG is protected, the access rights on this catalog must be deleted beforethe access rights are deleted on SITE.CATALOG. The command to do this is:

MDACL NAME=* DELETE=SYSADMIN TYPE=DIR CATNAME=SYS;

5. Cancel the OWNER access right on SITE.CATALOG

MDACL NAME=* DELETE=SYSADMIN TYPE=DIR CATNAME=SITE;

If at system initialization the Site Catalog is unprotected, and the System Catalog is stillprotected, the following error message will be issued:

CG09. SYS.CATALOG IS CONSIDERED AS NOT VALID

If this happens, the System Administrator must:

• Reset the access rights on the Site Catalog.

• Delete the access rights on the System Catalog.

• Reset the access rights on the Site Catalog again.

Similar operations must be performed if the Site Catalog is unprotected and a privatecatalog is still protected.

6.4.3 Changing the Owner of a Private Catalog

In some cases, the System Administrator may wish to cancel the access rights that werepreviously set on the system, either to return to the situation of an unprotected system, orto set new access rights from scratch. The procedure for cancelling the access rights on asystem is as follows:


6-32 47 A2 17UG Rev00

1. Cancel the OWNER access right on each private catalog

If a private catalog is not auto-attachable, and is not currently attached, it must first beattached before the OWNER access right is cancelled. The command to attach a catalogis:



47 A2 17UG Rev00 6-33

Once a private catalog is attached, the OWNER access right is cancelled with thecommand:

MDACL NAME=* DELETE=owner-project TYPE=DIR [CATNAME=private-catalog];


2. Cancel the OWNER access right on each protected volume

The command to do this is:

MODIFY_DISK VOL=vol-name:device-class CTLACC=NO;

Then delete the list of volumes that are assigned to projects, using theMAINTAIN_CATALOG command MDP. Enter this command with MSVOL='; orMTVOL=';.

3. Cancel the access rights on the system files

If the default access rights were set on the system files using the GIUF functionPROTECT_GCOS, these can be cancelled using:

PROTECT_GCOS ACCESS_RIGHT=RESET;

The SYSADMIN project remains the OWNER of these files.

4. Cancel the access rights on SYS.CATALOG

If SYS.CATALOG is protected, the access rights on this catalog must be deleted beforethe access rights are deleted on SITE.CATALOG. The command to do this is:

MDACL NAME=* DELETE=SYSADMIN TYPE=DIR CATNAME=SYS;

5. Cancel the OWNER access right on SITE.CATALOG

MDACL NAME=* DELETE=SYSADMIN TYPE=DIR CATNAME=SITE;

If at system initialization the Site Catalog is unprotected, and the System Catalog is stillprotected, the following error message will be issued:

CG09. SYS.CATALOG IS CONSIDERED AS NOT VALID

If this happens, the System Administrator must:

• Reset the access rights on the Site Catalog.• Delete the access rights on the System Catalog.• Reset the access rights on the Site Catalog again.


6-34 47 A2 17UG Rev00

Similar operations must be performed if the Site Catalog is unprotected and a privatecatalog is still protected.

6.4.4 Deleting a Project that is the Owner of a Private Catalog

Suppose that a project, OWNER of a Private Catalog, is to be deleted. First, delete itsaccess rights on its master directory in the Site Catalog; then delete its access right on itsprivate catalog.

1. Delete access right on the Site Catalog

MDACL NAME=master-directory TYPE=DIR DELETE=project-name CATNAME=SITE;

2. Delete access right on the private catalog

If the private catalog is not auto-attachable, and is not currently attached, it must first beattached before the OWNER access right is deleted. The command to attach a catalog is:


Once the catalog is attached, the OWNER access right on it can be deleted as follows:

MDACL NAME=* TYPE=DIR DELETE=project-name [CATNAME=catalog-name];


6.4.5 Saving a Protected Site Catalog to an Unprotected Site Catalog

It may happen that the System Administrators have to save a protected (active)SITE.CATALOG to another SITE.CATALOG on the same site which is unprotected andinactive. To do this, the System Administrators must protect the unprotectedSITE.CATALOG before transferring any information into it using the CATMOVE utility.The CATMOVE utility does not allow transfers from a protected catalog to an unprotectedone.

JCL Example (to be executed in batch mode)

CATBUILD SITE.CATALOG,DVC=MS/B10,MD=K088,NB0BJ=600;ATTACH CATALOG1=SITE.CATALOG, CATALOG2=(SITE.CATALOG,DVC=MS/B10,MD=K088);CATMODIF *,OWNER=SYSADMIN,CATALOG=2;CATMODIF SITE,OWNER=SYSADMIN,TYPE=DIR,CATALOG=2;


47 A2 17UG Rev00 6-35

CATMODIF SITE.CATALOG,WRITE=*,CATALOG=2;CATMOVE FROM=*,INFILE=(SITE.CATALOG,CATALOG=1, OUTFILE=(SITE.CATALOG,CATALOG=2); REPLACE;

GCL Example (to be executed in batch or interactive mode)

CREATE_CATALOG SITE.CATALOG,VOL=K088:MS/B10, NB0BJ=600;ATTACH (SITE.CATALOG,SITE.CATALOG:MS/B10:K088);MODIFY_ACL * PROJECT=SYSADMIN/OWNER TYPE=DIR CATALOG=2;MODIFY_ACL SITE PROJECT=SYSADMIN/OWNER TYPE=DIR CATALOG=2;MODIFY_ACL SITE.CATLOG PROJECT=*/WRITE TYPE=FILE CATALOG=2;MOVE_CATLOG INCAT=SITE.CATALOG OUTCAT=SITE.CATALOG CATALOG_I=1 CATALOG_O=2 REPLACE;

NOTE: The last command, MOVE_CATALOG, is always executed in batch mode, evenwhen it is supplied in IOF mode.

When catalogs and files are transferred from an unprotected site to a protected site, theSystem Administrator of the host site must carefully check the volume names that areintroduced to his site to avoid volume name duplication.

47 A2 17UG Rev00 g-1

Glossary

This glossary lists terms used in a GCOS 7 context.

For standard international terminology, refer to the following documents:

Trusted Computer Systems Evaluation CriteriaDOD 5200.28-STD, Department of Defence, U.S.A. December 1985

Information Technology Security Evaluation CriteriaISBN 92-826-3005-6, ITSEC V1.2, June 1991

Access control Access to objects protected by the operating system isrestricted to authorized persons. This term is used abusively(compared to standard international terminology) in certainGCOS 7 or SECUR'ACCESS documents to designate all thesecurity checks performed (including identification andauthentication).

Audit Search and analysis of events relating to logical security.

AUDIT 7 Optional GCOS 7 product, performing imputation functions(recording events relating to logical security).

AUDIT 7 Administrator Person responsible for the administration of the AUDIT 7product.

Authentication Function that enables an information system to confirm that auser's identity is exact.

Authority code Binary data used to define the rights of project users for TDStransactions.

Authorization Term used (abusively compared to standard internationalterminology) in certain GCOS 7 or SECUR'ACCESSdocuments to designate 'access control'.

Availability Access to resources of the information system is protectedagainst disruptions from unauthorized persons.

Confidentiality Prevention of the unauthorized disclosure of information.


g-2 47 A2 17UG Rev00

CONFIG Utility implemented during the first phase of GCOS 7installation.

Delegate Administrator Person responsible for managing a group of users in aSECUR'ACCESS environment.

Developer of a secure applicationPerson responsible for the design, creation and validation ofthe security-related aspects of a GCOS 7 application.

DJP Distributed Job ProcessingGCOS 7 product used to submit a remote job.

Fictitious User Facility for managing replacement smart cards in aSECUR'ACCESS context.

GCOS 7 without SECUR'ACCESSUtilization of GCOS 7 without the SECUR'ACCESS product.

GCOS 7 with SECUR'ACCESSUtilization of GCOS 7 with the SECUR'ACCESS product, toimprove the level of logical security in GCOS 7.

GCOS 7 with SECUR'ACCESS and smart cardUtilization of GCOS 7 with the SECUR'ACCESS product anda smart card to authenticate identification.

GCOS 7 with SECUR'ACCESS and passwordUtilization of GCOS 7 with the SECUR'ACCESS product anda password to authenticate identification.

Identification Recognition of the user's identity by the information system.

Accountability Recording of events related to logical security.

Integrity Prevention of the unauthorized modification of information.

IOF Interactive Operating FacilityInterface for an open GCOS 7 dialog enabling theadministration, operation and utilization of the informationsystem.

IOF End User User connected to the IOF service, who has no particularrights (neither Administrator nor Operator rights).

Lock Binary data (there are 10 locks associated with each mainright) used in a SECUR'ACCESS context to define a user'srights.

Logical security A concept in information technology that covers the notions ofconfidentiality, integrity and availability.

Main console A terminal dedicated to a GCOS 7 system, connected by adirect physical link. Certain specific operations are performedat the main console (such as initialization or maintenance).

Main Operator Person responsible for routine GCOS 7 management.

Glossary

47 A2 17UG Rev00 g-3

Main Right A number between 0 and 999, used in a SECUR'ACCESSenvironment to define the rights of a user.

Object reuse All storage objects are treated before reuse in such a waythat conclusions cannot be drawn regarding the previouscontents.GCOS 7 functions ensure that all information logically deletedcannot be retrieved.

Operator console See 'Main console'.

Owner of a file Person who has all the rights on a file, including the right togive rights. All the rights may be given, except the right togive rights.

Owner of a volume Person who has the right to allocate and deallocate space ona volume.

Owner of a volume name Person who is allowed to prepare a volume (with the GCLcommand PREPARE_VOLUME, JCL statement VOLPREP,etc.).

Passive user See 'Pseudo-user'.

Protected system GCOS 7 operating mode, in which checks on access to filesare performed according to the user's identity.

Protected volume Volume that has an owner (see "Owner of a volume").

Pseudo-User Facility that allows printers to be managed in aSECUR'ACCESS context. Also called 'passive user'.

SECUR'ACCESS An optional GCOS 7 product performing identification,authentication and access control functions.

SECUR'ACCESS SECADMIN AdministratorSecurity administrator who has a particular role in the case ofa failure in security functions.

Security Administrator Person with overall responsibility for the administration of theSECUR'ACCESS product.

Smart card Card with integrated micro-chip allowing more reliable accesscontrols to be performed.

System Administrator Person with overall responsibility for the administration of aGCOS 7 system.

TDS Transaction Driven SystemGCOS 7 transactional environment.

TDS End User User connected to a TDS service, who has no particularrights (neither Administrator nor Operator rights).

TDS Master Operator Person responsible for managing a TDS service.


g-4 47 A2 17UG Rev00

TDS-SA7 Transactional application dedicated to managing the securityof a GCOS 7 system that uses SECUR'ACCESS.

Glossary

47 A2 17UG Rev00 g-5

TDS-SA7 Master OperatorTDS Master Operator dedicated to managingSECUR'ACCESS (manages a dedicated TDS named SA7).

UFT Unified File TransferGCOS 7 product enabling the transfer of files betweendistinct sites.

Unprotected volume Volume that does not have an owner (see "Owner of avolume").

47 A2 17UG Rev00 i-1

Index

A

Access Control List 6-4Access control rule, IOF and TDS 4-3, 5-3Access controls,installing 4-8Access Rights

cancelling 6-28, 6-29initializing 6-25on private catalogs 6-27on the Site Catalog 6-26on volumes 6-28setting 6-25

Access rights 2-3Access rights to files 2-9, 3-3Access to available space 2-14Access to GCL commands 2-15, 2-16Access to JCL commands 2-15Access to transactions 5-11Accountability 2-20ACL 6-4Advanced password verification 2-5, 2-7Analyzing security-related events 3-6Application

Access control rule 4-3, 5-3Application management 5-18Archiving events 3-8Audit 2-20, 2-21AUDIT 7

Administrator 3-6, 4-7Installing 3-6

Audit file 2-21AUDIT 7 2-20Auditing of events 3-8Authentication 2-3Authentication errors 4-2Authentication, disabling 2-4Authority codes 2-12, 4-5, 5-11Authority masks 4-5Authorization table 5-10

B

Basic security functions 3-8Batch processing 2-3, 2-9, 2-10, 2-13, 3-3Billing management 5-18

C

Catalog 2-6, 2-7, 2-11, 2-20Catalog base 4-6, 4-8, 5-12Cataloged applications 2-10, 2-11Cataloged files 2-13, 6-3Checks during a TDS session 2-4Collecting security-related events 2-20, 3-6Common data 2-18Complex passwords 3-4, 3-6Confidentiality of data 2-17, 2-18CONFIG utility 2-4, 2-9, 2-16, 4-3Configuration 2-4, 2-9, 2-16, 3-1, 4-3Configuration controls 3-2Connection controls 4-2Control on access

to transactions 5-11Control points 5-9, 5-10Coupled systems 3-1

D

Dataaccess rights 6-1, 6-3common 2-18confidentiality 2-17, 2-18erasing 2-18, 2-19private 2-18protection 6-1shared 2-18


i-2 47 A2 17UG Rev00

Data securityprocedures 6-25

Debugging tools 2-18Debugging transactions 3-5Delegated identity 2-9Deleting files 2-18Disabling authentication 2-4Disk volume, reuse 2-19DJP 2-3, 2-8, 2-10, 4-3

E

Environmentprotected 2-5vulnerable 2-5

Erasing data 2-18, 2-19Errors

authentication 4-2Event management 4-7Events 2-20, 2-21

F

File access controls 3-3Files

deleting 2-18

G

GCL commands, access to 2-15, 2-16GCOS 7

data protection 6-1routine management 4-7startup with SECUR'ACCESS 5-21, 5-22

GCOS 7 security functions 2-1, 2-2GCOS 7 startup 5-21

H

History files 2-6

I

Identification 2-3Installation 2-5

Installinga technical status 3-5access controls 4-8AUDIT 7 3-6file access controls 3-3GCOS 7 3-2SECUR'ACCESS 3-4, 3-7security functions 3-1, 3-2telecommunications 3-7

IOF access control rule 4-3, 5-3

J

JCL commands, access to 2-15JCL mode, prohibiting 2-16

L

Limiting the rights of projects 2-11Lock profile 5-10Locks 5-9Logging on to GCOS 7 2-3Logical security

definition 1-1functions 1-1

M

Main consoles 2-4Main Operator 3-4, 4-7Main rights 5-9, 5-10, 5-11MAINTAIN_AUDIT7 2-20MAINTAIN_CATALOG 2-7, 2-15, 5-11MAINTAIN_COMMAND 2-15Management

application 5-18billing 5-18project 5-18station 5-18

Mandatory Startup 2-15Master Operator 5-11

O

Object Reuse 2-17

Index

47 A2 17UG Rev00 i-3

P

P2P configuration 3-1Participants in GCOS 7 security operations2-1Password

complex 3-6initial 4-4IOF user 4-4modification 4-6TDS user 4-4

Password verificationadvanced 2-5, 2-7simple 2-5

Passwordscomplex 3-4

Pre-defined transactionsPT 2-12TRACE 2-12

Private data 2-18Project management 5-18Project rights, limiting 2-11Protected environment 2-5Protected system 2-9PT (Pass-Through) 3-5PT transaction 2-12, 2-13

Q

QUOTA 2-14

R

Repeated authentication 2-4Reusing a disk volume 2-19Reusing a tape file 2-19Reusing a tape volume 2-19Reusing objects 2-17Roles in GCOS 7 security 2-1

S

SA7.* files 2-6SADMOPT, configuration command 3-2SECADMIN, configuration command 3-4SECOPT, configuration command 3-2SECUR'ACCESS

administrators 5-18control points 5-9, 5-10installing 3-4, 3-7Main Right number 5-11

security base 5-10TDS-SA7 Master Operator 5-11


i-4 47 A2 17UG Rev00

SECUR'ACCESS administratorsclasses 5-18roles 5-19

SECUR'ACCESS base 5-13Security administrators 3-8, 5-10Security base 4-1, 4-6, 5-2, 5-9, 5-12, 5-13

administration 5-17Security data

and TDS transactions 5-13identification data 5-12, 5-13invariable 5-15optional data 5-16permanent data 5-14personal data 5-12, 5-14, 5-15

Security functions in GCOS 7 2-1, 2-2Security parameters 3-2Security-related events 2-20, 2-21, 4-7Shared data 2-18SITE.CATALOG file 2-6, 2-11, 2-13, 2-15Smart card 2-3, 2-7Standard users 3-4Startup 5-21Startup sequence 2-15Startup with SECUR'ACCESS 5-21, 5-22Station management 5-18SYS.CATALOG file 2-13SYSADMIN project 2-9System Administrator 2-15, 3-4, 4-6, 5-11

T

Tape file, reuse 2-19Tape volume, reuse 2-19TDS

Master Operator 4-7TDS access control rule 4-3, 5-3TDS Security 3-9Technical status, installing 3-5Testing basic security functions 3-8TPR 2-18TRACE 2-18, 3-5TRACE transaction 2-12Transaction Processing Routine 2-18

U

UFT 2-3, 2-8, 2-10, 4-3Unprotected system 2-9

Index

47 A2 17UG Rev00 i-5

V

Verifying basic security functions 3-8Volume

access rights 6-28Volume Name OWNER 2-14Volume OWNER 2-14

X

XCP1 protocol 2-16XCP2 protocol 2-16

Technical publication remarks form

Title : DPS7000/XTA NOVASCALE 7000 Guide to Logical Security Security

Reference Nº : 47 A2 17UG 00 Date: February 1996

ERRORS IN PUBLICATION

SUGGESTIONS FOR IMPROVEMENT TO PUBLICATION

Your comments will be promptly investigated by qualified technical personnel and action will be taken as required.If you require a written reply, please include your complete mailing address below.

NAME : Date :

COMPANY :

ADDRESS :

Please give this technical publication remarks form to your BULL representative or mail to:

Bull - Documentation Dept.

1 Rue de ProvenceBP 20838432 ECHIROLLES [email protected]

Technical publications ordering form

To order additional publications, please fill in a copy of this form and send it via mail to:

BULL CEDOC357 AVENUE PATTONB.P.2084549008 ANGERS CEDEX 01FRANCE

Phone: +33 (0) 2 41 73 72 66FAX: +33 (0) 2 41 73 70 66E-Mail: [email protected]

CEDOC Reference # Designation Qty

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

[ _ _ ] : The latest revision will be provided if no revision number is given.

NAME: Date:

COMPANY:

ADDRESS:

PHONE: FAX:

E-MAIL:

For Bull Subsidiaries:

Identification:

For Bull Affiliated Customers:

Customer Code:

For Bull Internal Customers:

Budgetary Section:

For Others: Please ask your Bull representative.

BULL CEDOC

357 AVENUE PATTON

B.P.20845

49008 ANGERS CEDEX 01

FRANCE

47 A2 17UG 00REFERENCE