OpenVMS VAX Guide to System Security
Part Number: AA- PVSRA- TE Open VMS VAX Guide to System Security
Order Number: AA-PV5RA-TE
May 1993
This guide describes the security features available through the OpenVMS VAX operating system. It explains the purpose and proper application of each feature in the context of specific security needs.
Revision/Update Information: This manual supersedes the Guide to VMS System Security, Version 5.2. Software Version: OpenVMS VAX Version 6.0
Digital Equipment Corporation Maynard, Massachusetts May 1993 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital Equipment Corporation or its affiliated companies. ©Digital Equipment Corporation 1993. All Rights Reserved. The postpaid Reader's Comments forms at the end of this document request your critical evaluation to assist in preparing future documentation. The following are trademarks of Digital Equipment Corporation: Bookreader, CI, DECnet, DECserver, DECtalk, DECwindows, Digital, HSC, LAT, MSCP, OpenVMS, UETP, VAX, VAX 9000, VAXcluster, VAX MACRO, VAX Notes, VAXstation, VMS, VMScluster, VTlOO, VT200, and the DIGITAL logo. Display PostScript is a registered trademark of Adobe Systems Incorporated. All other trademarks and. registered trademarks are the property of their respective holders. ZK6060
This document was prepared using VAX DOCUMENT, Version 2.1. Contents
Preface ...... xv
Part I Security Overview
1 Understanding System Security 1.1 Types of Computer Security Problems ...... 1-1 1.2 Levels of Security Requirements ...... 1-2 1.3 Building a Secure System Environment ...... 1-3
2 OpenVMS Security Model 2.1 Reference Monitor Concept ...... 2-1 2.2 Implementation of the Reference Monitor ...... 2-2 2.2.1 Subjects ...... 2-3 2.2.2 Objects ...... 2-3 2.2.3 Authorization Database ...... 2-4 2.2.4 Audit Trail ...... 2-4 2.2.5 Reference Monitor ...... 2-5 2.2.6 Authorization Database Represented as an Access Matrix ...... 2-5 2.3 Summary: System Security Design ...... 2-7
Part II Security for the User
3 Using the System Responsibly 3.1 Choosing a Password for Your Account ...... 3-1 3.1.1 Obtaining Your Initial Password ...... 3-1 3.1.2 Observing System Restrictions on Passwords ...... 3-2 3.2 Knowing What Type of Password to Use ...... 3-2 3.2.1 Entering a System Password ...... 3-3 3.2.2 Entering a Secondary Password ...... 3-4 3.3 Password Requirements for Different Types of Accounts ...... 3-4 3.4 Types of Logins and Login Classes ...... 3-4 3.4.1 Logging In Interactively: Local, Dialup, and Remote Logins ...... 3-5 3.4.2 Reading Informational Messages ...... 3-5 3.4.3 When the System Logs In for You: Network and Batch Logins ...... 3-7 3.5 Login Failures: When You Are Unable to Log In ...... 3-7 3.5.1 Using a Terminal That Requires a System Password ...... 3-8 3.5.2 Observing Your Login Class Restrictions ...... 3-8 3.5.3 Using an Account Restricted to Certain Days and Times ...... 3-8 3.5.4 Failing to Enter the Correct Password During a Dialup Login ...... 3-8 3.5.5 Knowing When Break-In Evasion Procedures Are in Effect ...... 3-9
iii 3.6 Changing Your Password ...... 3-9 3.6.1 Selecting Your Own Password ...... 3-9 3.6.2 Using Generated Passwords...... 3-10 3.6.3 Changing a Secondary Password ...... 3-11 3.6.4 Changing Your Password As You Log In ...... 3-11 3. 7 Password and Account Expiration Times ...... 3-11 3. 7 .1 Changing an Expired Password ...... 3-12 3.7.2 Renewing an Expired Account ...... 3-12 3.8 Guidelines for Protecting Your Password ...... 3-13 3.9 Network Security Considerations...... 3-14 3.9.1 Protecting Information in Access Control Strings ...... 3-14 3.9.2 Using Proxy Login Accounts to Protect Passwords...... 3-15 3.10 Auditing Access to Your Account and Files ...... 3-16 3.10.1 Observing Your Last Login Time ...... 3-17 3.10.2 Adding Access Control Entries to Sensitive Files ...... 3-17 3.10.3 Asking Your Security Administrator to Enable Auditing ...... 3-18 3.10.3.1 Auditing File Access...... 3-18 3.10.3.2 Additional Events to Audit...... 3-19 3.11 Logging Out Without Compromising System Security...... 3-19 3.11 .1 Clearing Your Terminal Screen ...... 3-19 3.11 .2 Disposing of Hardcopy Output ...... 3-20 3.11 .3 Removing Disconnected Processes ...... 3-20 3.11 .4 Breaking the Connection to a Dialup Line ...... 3-20 3.12 Checklist for Contributing to System Security ...... 3-21
4 Protecting Data 4.1 Contents of a User's Security Profile ...... 4-1 4.1.1 User Identification Code (UIC) ...... 4-2 4.1.1.1 Format of a UIC ...... 4-2 4.1.1.2 Guidelines for Creating a UIC ...... 4-2 4.1.1.3 How Your Process Acquires a UIC ...... 4-3 4.1.2 Rights Identifiers ...... 4-3 4.1.2.1 Types of Identifiers ...... 4-3 4.1.2.2 Displaying the Rights Identifiers of Your Process ...... 4-4 4.1.2.3 How Rights Identifiers Appear in the Audit Trail ...... 4-5 4.1.3 Privileges ...... 4-5 4.2 Security Profile of Objects ...... 4-6 4.2.1 Definition of a Protected Object ...... 4-6 4.2.2 Contents of an Object's Profile . ·...... 4-6 4.2.2.1 Owner ...... 4-7 4.2.2.2 Protection Code ...... 4-7 4.2.2.3 Access Control List (ACL) ...... 4-8 4.2.3 Displaying a Security Profile ...... 4-8 4.2.4 Modifying a Security Profile ...... 4-9 4.2.5 Specifying an Object's Class ...... 4-9 4.2.6 Access Required to Modify a Profile ...... 4-10 4.3 How the System Determines If a User Can Access a Protected Object .. . 4-10 4.4 Methods of Controlling Access with ACLs ...... 4-16 4.4.1 Using Identifier Access Control Entries (ACEs) ...... 4-16 4.4.2 Granting Access to Particular Users ...... 4-16 4.4.3 Preventing Users from Accessing an Object ...... 4-17 4.4.4 Limiting Access to a Device ...... 4-17 4.4.5 Limiting Access to an Environment ...... 4-18
iv 4.4.6 Ordering ACEs Within a List ...... 4-18 4.4.7 Establishing an Inheritance Scheme for Files ...... 4-19 4.4.8 Displaying ACLs ...... 4-20 4.4.9 Adding ACEs to an Existing ACL ...... 4-20 4.4.10 Deleting an ACL ...... 4-21 4.4.11 Deleting ACEs from an ACL ...... 4-21 4.4.12 Replacing Part of an ACL ...... 4-22 4.4.13 Restoring a File's Default ACL ...... 4-22 4.4.14 Copying an ACL ...... 4-22 4.5 Controlling Access with Protection Codes ...... 4-23 4.5.1 Format of a Protection Code ...... 4-23 4.5.2 Types of Access in a Protection Code ...... 4-24 4.5.3 Processing a Protection Code ...... 4-24 4.5.4 Changing a Protection Code ...... 4-25 4.5.5 Enhancing Protection for Sensitive Objects ...... 4-25 4.5.6 Providing a Default Protection Code for a Directory Structure ...... 4-26 4.5.7 Restoring a File's Default Security Profile ...... 4-26 4.6 Understanding Privileges and Control Access ...... 4-27 4.6.1 How Privileges Affect Protection Mechanisms ...... 4-27 4.6.2 Using Control Access to Modify an Object Profile ...... 4-27 4.6.3 Object-Specific Access Considerations ...... 4-28 4.7 Auditing Protected Objects ...... 4-28 4.7.1 Kinds of Events the System Audits ...... 4-28 4.7.2 Enabling Auditing for a Class of Objects ...... 4-28 4.7.3 Adding Security-Auditing ACEs ...... 4-29 4.8 Descriptions of Object Classes ...... 4-29 4.8.1 Capabilities ...... 4-29 4.8.1.1 Naming Rules ...... 4-30 4.8.1.2 Types of Access ...... 4-30 4.8.1.3 Template Profile ...... 4-30 4.8.1.4 Kinds of Auditing Performed ...... 4-30 4.8.1.5 Permanence of the Object ...... 4-30 4.8.2 Common Event Flag Clusters ...... 4-30 4.8.2.1 Naming Rules ...... 4-30 4.8.2.2 Types of Access ...... 4-31 4.8.2.3 Template Profile ...... 4-31 4.8.2.4 Privilege Requirements ...... 4-31 4.8.2.5 Kinds of Auditing Performed ...... 4-31 4.8.2.6 Permanence of the Object ...... 4-31 4.8.3 Devices ...... 4-31 4.8.3.1 Naming Rules ...... 4-32 4.8.3.2 Types of Access ...... 4-32 4.8.3.3 Access Requirements for I/O Operations ...... 4-32 4.8.3.4 Template Profile ...... 4-33 4.8.3.5 Setting Up Profiles for New Devices ...... 4-34 4.8.3.6 Privilege Requirements ...... 4-35 4.8.3.7 Kinds of Auditing Performed ...... 4-35 4.8.3.8 Permanence of the Object ...... 4-35 4.8.4 Files ...... : · 4-35 4.8.4.1 Naming Rules ...... 4-35 4.8.4.2 Types of Access ...... 4-36 4.8.4.3 Access Requirements ...... 4-36 4.8.4.4 Creation Requirements ...... 4-37 4.8.4.5 Profile Assignment ...... 4-37
v 4.8.4.6 Kinds of Auditing Performed ...... 4-38 4.8.4.7 Protecting Information When Disk Space Is Reassigned ...... 4-38 4.8.4.7.1 Overwriting Disk Blocks ...... 4-39 4.8.4.7.2 Setting a Highwater Mark ...... 4-39 4.8.4.7.3 Accessibility of Data in a File ...... 4-40 4.8.4.8 Suggestions for Optimizing File Security ...... 4-40 4.8.5 Global Sections ...... 4-41 4.8.5.1 Naming Rules ...... 4-41 4.8.5.2 fypes of Access ...... 4-41 4.8.5.3 Template Profile ...... 4-41 4.8.5.4 Privilege Requirements ...... 4-42 4.8.5.5 Kinds of Auditing Performed ...... 4-42 4.8.5.6 Permanence of the Object ...... 4-42 4.8.6 Logical Name Tables ...... 4-42 4.8.6.1 Naming Rules ...... 4-42 4.8.6.2 fypes of Access ...... 4-42 4.8.6.3 Template Profile ...... 4-43 4.8.6.4 Privilege Requirements ...... 4-43 4.8.6.5 Kinds of Auditing Performed ...... 4-43 4.8.6.6 Permanence of the Object ...... 4-43 4.8.7 Queues ...... 4-43 4.8.7.1 Naming Rules ...... 4-44 4.8.7.2 fypes of Access ...... 4-44 4.8.7.3 Template Profile ...... 4-44 4.8.7.4 Privilege Requirements ...... 4-44 4.8.7.5 Kinds of Auditing Performed ...... 4-44 4.8.7.6 Permanence of the Object ...... 4-45 4.8.8 Resource Domains ...... 4-45 4.8.8.1 Naming Rules ...... 4-45 4.8.8.2 fypes of Access ...... 4-45 4.8.8.3 Template Profile ...... 4-45 4.8.8.4 Privilege Requirements ...... 4-45 4.8.8.5 Kinds of Auditing Performed ...... 4-45 4.8.8.6 Permanence of the Object ...... 4-46 4.8.9 Security Classes ...... 4-46 4.8.9.1 Naming Rules ...... 4-46 4.8.9.2 fypes of Access ...... 4-46 4.8.9.3 Template Profile ...... 4-46 4.8.9.4 Kinds of Auditing Performed ...... 4-47 4.8.9.5 Permanence of the Object ...... 4-47 4.8.10 Volumes ...... 4-47 4.8.10.1 Naming Rules ...... 4-47 4.8.10.2 fypes of Access ...... 4-47 4.8.10.3 Template Profile ...... 4-47 4.8.10.4 Privilege Requirements ...... 4-48 4.8.10.5 Kinds of Auditing Performed ...... 4-48 4.8.10.6 Permanence of the Object ...... 4-48
vi Part Ill Security for the System Administrator
5 Managing the System and Its Data 5.1 Security Management Account ...... 5-1 5.2 Considerations for Establishing User Accounts ...... 5-1 5.2.1 Introduction to Group Design...... 5-2 5.2.1.1 Example of UIC Group Design ...... 5-2 5.2.1.2 Limitations to UIC Group Design ...... 5-3 5.2.2 Designing Access Control Lists (ACLs) and Identifiers ...... 5-3 5.3 Creating and Maintaining a Rights Database ...... 5-4 5.3.1 Adding Identifiers ...... 5-5 5.3.2 Assigning Identifiers to Users ...... 5-6 5.3.3 Removing Identifiers and Holders ...... 5-6 5.3.4 Displaying the Rights Database...... 5-7 5.3.5 Modifying a System or Process Rights List ...... 5-7 5.4 Modifying Identifiers for Different Users ...... 5-7 5.4.1 Using Environmental Identifiers ...... 5-7 5.4.2 Adding Special Attributes to Identifiers...... 5-8 5.4.2.1 Dynamic Attribute ...... 5-8 5.4.2.2 Holder Hidden Attribute ...... 5-9 5.4.2.3 Name Hidden Attribute ...... 5-9 5.4.2.4 No Access Attribute ...... 5-9 5.4.2.5 Resource Attribute ...... 5-10 5.4.2.6 Subsystem Attribute ...... 5-11 5.5 Setting Object Protection and Ownership Defaults for Users ...... 5-11 5.5.1 Setting File Defaults ...... 5-11 5.5.1.1 Adjusting Protection Defaults ...... 5-15 5.5.1.2 Setting Defaults for a Directory Owned by a Resource Identifier ...... 5-16 5.5.1.2.1 Setting Up the Resource Identifier...... 5-17 5.5.1.2.2 Setting Up the Directory of a Resource Identifier ...... 5-17 5.5.1.2.3 Setting Up the ACL ...... 5-17 5.5.2 Setting Defaults for Objects Other Than Files ...... 5-18 5.5.2.1 Displaying Class Defaults ...... 5-19 5.5.2.2 Modifying Class Templates ...... 5-20 5.6 Password Management ...... 5-20 5.6.1 Initial Passwords ...... 5-20 5.6.2 System Passwords ...... 5-21 5.6.3 Primary and Secondary Passwords ...... ·.. . 5-22 5.6.4 Enforcing Minimum Password Standards ...... 5-23 5.6.4.1 Password Expiration ...... 5-23 5.6.4.2 Forcing Expired Password Changes ...... 5-24 5.6.4.3 Minimum Password Length ...... 5-24 5.6.5 Screening New Passwords ...... 5-25 5.6.5.1 System Dictionary ...... 5-25 5.6.5.2 Password History List ...... 5-26 5.6.5.3 Site-Specific Filter ...... 5-26 5.6.6 Requiring the Password Generator ...... 5-27 5.6. 7 Specifying a Site-Specific Password Algorithm ...... 5-27 5.6.8 Enabling the Console Password ...... 5-28 5.6.9 Protecting Passwords ...... 5-29 5. 7 Login Options ...... 5-30 5.7.1 Controlling the Announcement Message ...... 5-30
vii 5.7.2 Co~trolling the Welcome Message ...... 5-30 5.7.3 Controlling the Last Login Messages...... 5-30 5. 7 .4 Controlling New Mail Announcements ...... 5-30 5.7.5 Controlling Disconnected Processes ...... 5-31 5.7.6 Controlling Failed Login Attempts...... 5-31 5. 7. 7 Restricting Login Functions ...... 5-32 5.7.8 User Authorization File Login Checks ...... 5-32 5.7.9 Controlling Break-In Detection and Evasion ...... 5-33 5.7.10 Using the Secure Server ...... 5-36 5.8 Using the Automatic Login Facility (ALF) ...... 5-37 5.8.1 Adding New Records ...... 5-38 5.8.2 Deleting Records ...... : ...... 5-38 5.8.3 Displaying Records...... 5-38 5.8.4 Restricting ALF Users ...... 5-39 5.8.5 Logging In to an Automatic Login Terminal ...... 5-39 5.8.6 Protecting Automatic Login Accounts ...... 5-39 5.9 Protecting System Programs and Databases ...... 5-39 5.9.1 Augmenting Protection on System Files...... 5-40 5.9.2 Precautions to Take when Installing New Software...... 5-41 5.9.2.1 Protecting Programs and Directories ...... 5-41 5.9.2.2 Installing Programs with Privilege ...... 5-42 5.9.3 Encrypting Files...... 5-42 5.9.4 Restricting Command Outputs ...... 5-42 5.10 Authorizing U s~ge ...... 5-42 5.10.1 Restricting Devices ...... 5-42 5.10.1.1 Restricting Disk Volumes ...... 5-43 5.10.1 .2 Restricting Terminal Use ...... 5-43 5.10.1.3 Restricting Applications Terminals and Miscellaneous Devices . . . 5-43 5.10.2 Restricting Work Times ...... 5-43 5.10.3 Restricting Mode of. Operation ...... 5-44 5.10.4 Restricting DCL Command Usage ...... 5-44 5.10.5 Restricting Account Duration ...... 5-45 5.11 Granting User Privileges ...... 5-45 5.11.1 Limiting User Privileges ...... 5-47 5.11 .2 Suggested Privilege Allocations ...... 5-48 5.11 .3 Controlling Privileged Accounts ...... 5-48 5.11 .4 Special-Purpose Privileged Captive Accounts ...... 5-49 5.12 Examples of Establishing User Accounts ...... 5-49 5.12.1 System Manager's Account ...... 5-49 5.12.2 Interactive User's Account ...... 5-50 5.12.3 Production Account ; ...... 5-50 5.13 Using Limited-Access Accounts to Create a Restricted Environment . . . . 5-51 5.13.1 Captive Accounts ...... 5-52 5.13.1.1 Setting Up Captive Accounts ...... 5-52 5.13.1 .2 Guidelines for Captive Command Procedures ...... 5-53 5.13.2 Creating a Restricted Account ...... 5-54 5.13.3 Guest Accounts ...... 5-56 5.13.4 Effect of the DISIMAGE Flag ...... 5-57 5.13.5 Proxy Login Accounts ...... 5-57 5 .14 Training the New User ...... 5-57 5.15 Logging a User's Session ...... 5-58 5.16 Configuring Terminal Lines for Modems ...... 5-60 5.17 Disk Maintenance Considerations ...... • . 5-60 5.17 .1 Backups of Disks ...... 5-60
viii 5.17.2 Protecting a Backup Save Set ...... 5-61 5.17.3 Retrieving Files from Backup Save Sets ...... 5-62 5.18 Methods for Discouraging Disk Scavenging ...... 5-62 5.18.1 Erasing Techniques ...... 5-62 5.18.2 Prevention Through Highwater Marking ..... ·...... 5-63 5.18.3 Summary of Prevention Techniques ...... 5-64 5.19 Ongoing Tasks to Maintain a Secure System ...... 5-64
6 Security Auditing 6.1 Overview of the Auditing Process ...... 6-1 6.2 Reporting Security-Relevant Events ...... 6-2 6.2.1 Ways to Generate Audit Information ...... 6-2 6.2.1.1 Auditing Categories of Activity ...... 6-2 6.2.1.2 Attaching a Security-Auditing ACE ...... 6-5 6.2.1.3 Modifying a User Authorization Record ...... 6-6 6.2.2 Kinds of System Activity the Operating System Can Report ...... 6-7 6.2.2.1 Suppression of Certain Privilege Audits ...... 6-8 6.2.2.2 Suppression of Certain Process Control Audits ...... 6-8 6.2.3 Sources of Event Information ...... 6-9 6.3 Developing an Auditing Plan ...... 6-9 6.3.1 Assessing Your Auditing Requirements ...... 6-10 6.3.2 Selecting a Destination for the Event Message ...... 6-12 6.3.3 Considering the Performance Impact ...... 6-12 6.4 Methods of Capturing Event Messages ...... 6-13 6.4.1 Using an Audit Log File ...... 6-13 6.4.1.1 Maintaining the File ...... 6-13 6.4.1.2 Moving the File from the System Disk ...... 6-14 6.4.2 Enabling a Terminal to Receive Alarms ...... 6-15 6.4.3 Secondary Destinations for Event Messages ...... 6-15 6.4.3.1 Using a Remote Log File ...... 6-15 6.4.3.2 Using a Listener Mailbox ...... 6-16 6.5 Analyzing a Log File ...... 6-17 6.5.1 Recommended Procedure ...... 6-17 6.5.2 Invoking the Audit Analysis Utility ...... 6-18 6.5.3 Providing Report Specifications ...... 6-19 6.5.4 Using the Audit Analysis Utility Interactively ...... 6-21 6.5.5 Examining the Report ...... 6-21 6.6 Managing the Auditing Subsystem ...... 6-23 6.6.1 Tasks Performed by the Audit Server ...... 6-23 6.6.2 Disabling and Reenabling Startup of the Audit Server ...... 6-25 6.6.3 Changing the Point in Startup When the Operating System Initiates Auditing ...... 6-25 6.6.4 Choosing the Number of Outstanding Messages That Trigger Process Suspension ...... 6-26 6.6.4.1 Controlling Message Flow ...... 6-26 6.6.4.2 Preventing Process Suspension ...... 6-27 6.6.5 Reacting to Insufficient Memory ...... 6-27 6.6.6 Maintaining the Accuracy of Message Time-Stamping ...... 6-28 6.6.7 Adjusting the Transfer of Messages to Disk ...... 6-28 6.6.8 Allocating Disk Space for the Audit Log File ...... 6-28 6.6.9 Error Handling in the Auditing Facility ...... 6-29 6.6.9.1 Disabling Disk Monitoring ...... 6-29 6.6.9.2 Losing the Link to a Remote Log File ...... 6-29
ix 7 System Security Breaches 7.1 Forms of System Attacks ...... 7-1 7.2 Indications of Trouble ...... 7-2 7.2.1 Reports from Users ...... 7-2 7.2.2 Monitoring the System ...... 7-2 7.3 Routine System Surveillance ...... 7-3 7.3.1 System Accounting ...... 7-3 7.3.2 Security Auditing ...... 7-4 7.4 Handling a Security Breach ...... 7-6 7.4.1 Unsuccessful Break-In Attempts ...... 7-6 7.4.1.1 Detection of the Break-In Attempt ...... 7-6 7.4.1.2 Identifying the Perpetrator ...... 7-6 7.4.1.3 Prevention of Break-In Attempts ...... 7-6 7.4.2 Successful Break-In Attempts ...... 7-7 7.4.2.1 Identifying the Successful Perpetrator ...... 7-7 7.4.2.2 Securing the System ...... 7-8 7.4.2.3 Repair After a Successful Break-In ...... 7-8
8 Securing a Cluster 8.1 Overview of Clusters 8-1 8.2 Building a Common Environment ...... 8-2 8.2.1 Required Common System Files ...... 8-2 8.2.2 Recommended Common System Files ...... 8-3 8.2.3 Synchronizing Multiple Versions of Files ...... 8-3 8.3 Synchronizing Authorization Data ...... 8-4 8.4 Managing the Audit Log File ...... 8-5 8.5 Protecting Objects ...... 8-6 8.6 Storing Profiles and Auditing Information ...... 8-6 8.7 Using the System Management Utility ...... 8-7 8.8 Managing Cluster Membership ...... 8-7 8.9 Using DECnet Between Cluster Nodes ...... 8-8
9 Security for a DECnet Node 9.1 Access Control in a Network ...... 9-1 9.1.1 Circuit-Level Access Control ...... 9-1 9.1.2 Node-Level Access Control ...... 9-2 9.1.3 System-Level Access Control ...... 9-2 9.2 Reference Monitor in a Network ...... 9-2 9.2.1 Establishing Subject Correspondence ...... 9-4 9.2.2 Specifying Authorizations ...... 9-5 9.2.3 Protecting Communications ...... 9-5 9.2.4 Auditing in the Network ...... 9-6 9.2.5 Summary of OpenVMS Network Security and the Reference Monitor ...... 9-6 9.3 DECnet Accounts ...... 9-6 9.4 DECnet Database ...... 9-7 9.5 Network Laws and Regulations ...... 9-7 9.6 Specifying DECnet Object Accounts ...... 9-8 9.6.1 Summary of Network Objects ...... 9-9 9.6.2 Configuring Network Objects Automatically ...... 9-10
x 9.6.3 Configuring Network Objects Manually ...... 9-10 9.6.3.1 Creating a Top-Level Directory for an Object ...... 9-10 9.6.3.2 Creating an Account for a Network Object ...... 9-11 9.6.3.3 Defining the Network Object Account Name and Password ...... 9-12 9.6.3.4 Removing Default DECnet Access to the System ...... 9-12 9.6.3.5 Rebooting the System ...... 9-13 9.7 Proxy Logins ...... 9-13 9.7.1 Setting Up Proxy Logins ...... 9-13 9.7.1.1 Using the Authorize Utility ...... 9-14 9.7.1.2 Proxy Account Example ...... 9-14 9.7.1.3 Using the Network Control Program (NCP) Utility ...... 9-16 9.7.1.4 Conditions for Proxy Access ...... 9-17 9.7.2 Special Proxy Access Considerations ...... 9-18 9.8 Sharing Files in the Network Environment ...... 9-18 9.8.1 Admitting Remote Users for a Single Task ...... 9-18 9.8.2 Admitting Remote Users to One Account ...... 9-19 9.8.3 Admitting Remote Users to Multiple Accounts ...... 9-19
1O Using Protected Subsystems 10.1 Advantages of Protected Subsystems ...... 10-1 10.2 Applications for Protected Subsystems ...... 10-2 10.3 How Protected Subsystems Work ...... 10-2 10.4 Design Considerations ...... 10-3 10.5 System Management Requirements ...... 10-3 10.6 Building the Subsystem ...... 10-4 10.7 Enabling Protected Subsystems on a Trusted Volume ...... 10-5 10.8 Giving Users Access ...... 10-6 10.9 Example of a Protected Subsystem ...... 10-6 10.9.1 Protecting the Top-Level Directory ...... 10-7 10.9.2 Protecting Subsystem Directories ...... 10-8 10.9.3 Protecting the Images and Data Files ...... 10-9 10.9.4 Protecting the Printer ...... 10-10 10.9.5 Command Procedure for Building the Subsystem ...... 10-10
A Assigning Privileges A.1 ACNT Privilege (Devour) ...... A-2 A.2 ALLSPOOL Privilege (Devour) ...... A-2 A.3 ALTPRI Privilege (System) ...... A-2 A.4 AUDIT Privilege (System) ...... A-3 A.5 BUGCHK Privilege (Devour) ...... A-3 A.6 BYPASS Privilege (All) ...... A-3 A.7 CMEXEC Privilege (All) ...... A-4 A.8 CMKRNL Privilege (All) ...... A-5 A.9 DETACH Privilege (All) ...... A-6 A.10 DIAGNOSE Privilege (Objects) ...... A-6 A.11 DOWNGRADE Privilege (All) ...... A-6 A.12 EXQUOTA Privilege (Devour) ...... A-6 A.13 GROUP Privilege (Group) ...... A-7 A.14 GRPNAM Privilege (Devour) ...... A-7 A.15 GRPPRV Privilege (Group) ...... A-7 A.16 IMPORT Privilege (Objects) ...... A-8 A.17 LOG_IO Privilege (All) ...... A-8
xi A.18 MOUNT Privilege (Normal) ...... A-9 A.19 NETMBX Privilege (Normal) ...... A-9 A.20 OPER Privilege (System) ...... A-9 A.21 PFNMAP Privilege (All) ...... A-12 A.22 PHY_IO Privilege (All) ...... A-12 A.23 PRMCEB Privilege (Devour) ...... A-13 A.24 PRMGBL Privilege (Devour) ...... A-13 A.25 PRMMBX Privilege (Devour) ...... A-14 A.26 PSWAPM Privilege (System) ...... A-14 A.27 READALL Privilege (Objects) ...... A-14 A.28 SECURITY Privilege (System) ...... A-15 A.29 SETPRV Privilege (All) ...... A-15 A.30 SHARE Privilege (All) ...... A-15 A.31 SHMEM Privilege (Devour) ...... A-16 A.32 SYSGBL Privilege (Files) ...... A-16 A.33 SYSLCK Privilege (System) ...... A-16 A.34 SYSNAM Privilege (All) ...... A-16 A.35 SYSPRV Privilege (All) ...... A-17 A.36 TMPMBX Privilege (Normal) ...... A-18 A.37 UPGRADE Privilege (All) ...... A-18 A.38 VOLPRO Privilege (Objects) ...... A-18 A.39 WORLD Privilege (System) ...... A-19
B Protection for OpenVMS System Files
C Running an OpenVMS VAX System in a C2 Environment C.1 Introduction to C2 Systems ...... C-1 C.1.1 Definition of the C2 Environment ...... C-1 C.1.2 Documentation ...... C-1 C.2 Trusted Computing Base (TCB) for C2 Systems ...... C-2 C.2.1 Hardware in the TCB ...... C-2 C.2.2 Software in the TCB ...... C-2 C.2.3 Site-Specific Additions to the TCB ...... C-3 C.3 Protecting Objects ...... C-3 C.4 Protecting the TCB ...... C-4 C.4.1 Protecting Files ...... C-4 C.4.2 Privileges for Trusted Users ...... C-4 C.4.3 Privileges for Untrusted Users ...... C-5 C.4.4 Physical Security ...... C-5 C.5 Configuring a C2 System ...... C-6 C.5.1 Keeping Individuals Accountable ...... C-6 C.5.2 Managing the Auditing Trail ...... C-7 C.5.3 Reusing Objects ...... C-8 C.5.4 Configuring Clusters ...... C-9 C.5.5 Starting Up and Operating the System ...... C-9 C.6 Checklist for Generating a C2 System ...... C-10
xii D Alarm Messages
Glossary
Index
Examples 3-1 Local Login Messages ...... 3-5 4-1 Authorized Versus Default Process Privileges ...... 4-6 5-1 Sample Security/System Manager's Account ...... 5-50 5-2 Typical Interactive User Account ...... 5-50 5-3 Production Account ...... 5-51 5-4 Sample Captive Procedure for Privileged Accounts ...... 5-54 5-5 Sample Captive Command Procedure ...... 5-55 6-1 Sample Alarm Message ...... 6-2 6-2 Audit Generated by an Object Access Event ...... 6-5 6-3 Auditing Events for a Site with Moderate Security Requirements ... . 6-11 6-4 Brief Audit Report ...... 6-20 6-5 One Record from a Full Audit Report ...... 6-20 6-6 Summary of Events in an Audit Log File ...... 6-21 6-7 Identifying Suspicious Activity in the Audit Report ...... 6-22 6-8 Scrutinizing a Suspicious Record ...... 6-23 9-1 UAF Record for MAIL$SERVER Account ...... 9-12 9-2 Sample Proxy Account ...... 9-15 9-3 Protected File Sharing in a Network ...... 9-20 10-1 Subsystem Command Procedure ...... 10-11 8-1 SYSCOMMON Files: Protection Codes and Ownership ...... 8-1 8-2 SYSEXE Files: Protection Codes and Ownership ...... 8-2 8-3 SYSLIB Files: Protection Codes and Ownership ...... 8-8 8-4 SYSMGR Files: Protection Codes and Ownership ...... 8-18
Figures 2-1 Reference Monitor ...... 2-2 2-2 Authorization Access Matrix ...... 2-5 2-3 Authorization Access Matrix with Labeled Cross-Points ...... 2-6 4-1 Flowchart of Access Request Evaluation ...... 4-12 5-1 Flowchart of File Creation ...... 5-13 5-2 Security Class Object ...... 5-19 6-1 Default Characteristics of the Audit Server ...... 6-24 9-1 Simple View of Reference Monitor in a Network ...... 9-3 9-2 Advanced View of the Reference Monitor in a Network ...... 9-4 10-1 How Protected Subsystems Differ from Normal Access Control ...... 10-2 10-2 Directory Structure of the Taylor Company's Subsystem ...... 10-7
xiii Tables
1-1 Event Tolerance as a Measure of Security Requirements ...... 1-2 3-1 Secure and Insecure Passwords ...... 3-1 3-2 fypes of Passwords ...... 3-2 4-1 Major 'I1ypes of Rights Identifiers ...... 4-3 4-2 Classes of Protected Objects ...... 4-10 4-3 Access Requirements for Non-File-Oriented Devices ...... 4-33 5-1 Employee Grouping by Department and Function ...... 5-2 5-2 Defaults for Password History List ...... 5-26 5-3 Restricting Accounts ...... 5-32 5-4 DCL Commands Used to Protect Files ...... 5-40 5-5 OpenVMS Privileges ...... 5-46 5-6 Minimum Privileges for System Users ...... 5-48 5-7 Login Qualifiers Precluded by Captive Accounts ...... 5-52 6-1 Event Classes Audited by Default ...... 6-3 6-2 Access Control Entries (ACEs) for Security Auditing ...... 6-6 6-3 Kinds of Security Events the System Can Report ...... 6-7 6-4 Events to Monitor Depending on a Site's Security Requirements .... . 6-10 6-5 Characteristics of the Audit Log File ...... 6-13 6-6 Qualifiers for the Audit Analysis Utility ...... 6-19 6-7 Controlling the Flow of Audit Event Messages ...... 6-26 7-1 System Files Benefiting from ACL-Based Auditing ...... 7-5 8-1 System Files That Must Be Common in a Cluster ...... 8-2 8-2 System Files Recommended to Be Common ...... 8-3 8-3 Using Multiple Versions of Required Cluster Files ...... 8-4 8-4 Fields in SYSUAF.DAT Requiring Synchronization ...... 8-5 8-5 Summary of Object Behavior in a Cluster ...... 8-6 9-1 Network Object Defaults ...... 9-11 9-2 Executor Proxy Parameter Values ...... 9-16 C-1 Software Not Included in the C2-Evaluated System ...... C-2 C-2 Privileges for Untrusted Users ...... C-5
xiv Preface
Intended Audience This guide is designed for users and for administrators responsible for protecting operating systems from tampering, observation, or theft of services by unauthorized users. The term security administrator is used in this guide to refer to the person or persons responsible for system security. Document Structure This guide contains the following information: • Part I: Introduction Gives security administrators an overview of security issues, conceptual design features, and security features specific to OpenVMS VAX. systems. Chapter 1 discusses levels of security requirements and describes three sources of security failures. Chapter 2 introduces the reference monitor concept of security design and provides an overview of the operating system's security features. • Part II: Security for the User Describes security actions and features for the general user. Chapter 3 provides information for the general user about the login and logout processes and the responsible use of passwords. Chapter 4 describes object protection features in detail. • Part III: Security for the System Administrator Describes security actions and features for the security administrator. Chapter 5 describes general system security features for the security administrator. Chapter 6 describes security-auditing features. Chapter 7 describes how to recognize when a system is under attack and how to protect and defend your system. Chapter 8 describes security-related actions specific to clustered systems, such as setting up common system files and synchronizing authorization data. Chapter 9 describes security considerations for systems using networking. Chapter 10 describes how to set up and manage protected subsystems. Appendix A provides a summary of all the user privileges available on the operating system and describes who may need them.
xv Appendix B lists the protection codes and ownership that Digital provides for critical system files. Appendix C describes how to operate OpenVMS VAX systems in a Division C, Class 2 (C2) security environment. Appendix D provides examples of security alarm messages. • The Glossary provides definitions of security-related terms introduced in this guide. Changes Since the Previous Version OpenVMS VAX Version 6.0 includes many security enhancements. Thus, the Open VMS VAX Guide to System Security includes the following new or changed features: • The system's auditing capabilities are greatly enhanced: you can audit many more classes of security-relevant events, you can select an event as either an alarm or an audit, you can add Audit access control entries (ACEs) to objects, and you can control the flow of audit messages using a new SET AUDIT qualifier (/BACKLOG). (See Chapter 6 for information on auditing.) • The system now protects more object classes. New classes of protected objects include volumes, common event flag clusters, resource domains, and security classes. All protected objects now have a consistent set of security elements: an access control list (ACL), an owner, and a protection code. In addition, all object classes support full ACL auditing. (See Chapter 4 for information on object protection.) • You can modify or display the security profile of all objects by using one set of DCL commands, SET SECURITY and SHOW SECURITY. (See Chapter 4 for examples.) • Security administrators can now control access to files and other objects by using protected subsystems. Protected subsystems provide an alternative to creating installed privileged images or protected shareable images (user written system services). (See Chapter 10 for information on protected subsystems.) Associated Documents The Open VMS VAX Guide to System Security assumes you are familiar with the reference material in the Open VMS System Management Utilities Reference Manual pertaining to the following security-related utilities: • Access control list editor (ACL editor) • Accounting utility • Audit Analysis utility • Authorize utility • Backup utility • System Management (SYSMAN) utility
xvi You might find helpful the amplified security information in the following manuals: • Open VMS DCL Dictionary • Open VMS System Manager's Manual • VMScluster Systems for Open VMS Users with a specific interest in networking should be familiar with the DECnet for Open VMS Networking Manual. Users who need to encrypt files should consult the VAX Encryption Reference Manual. For a complete list and description of the manuals in the documentation set, see the Overview of Open VMS Documentation. Conventions In this manual, every use of OpenVMS VAX means the OpenVMS VAX operating system. The parts of this guide are intended for different audiences, and the meaning of you differs accordingly: • Part I addresses security administrators. • Part II addresses general users. • Part III addresses security administrators. The following conventions are also used in this manual: Ctrl/x A sequence such as Ctrl/x indicates that you must hold down the key labeled Ctrl while you press another key or a pointing device button. In examples, a key name enclosed in a box indicates that you press a key on the keyboard. (In text, a key name is not enclosed in a box.) A horizontal ellipsis in examples indicates one of the following possibilities: • Additional optional arguments in a statement have been omitted. • The preceding item or items can be repeated one or more times. • Additional parameters, values, or other information can be entered.
A vertical ellipsis indicates the omission of items from a code example or command format; the items are omitted because they are not important to the topic being discussed. () In format descriptions, parentheses indicate that, if you choose more than one option, you must enclose the choices in parentheses. [ ] In format descriptions, brackets indicate optional elements. You can choose one, none, or all of the options. (Brackets are not optional, however, in the syntax of a directory name in an OpenVMS file specification, or in the syntax of a substring specification in an assignment statement.)
xvii { } In format descriptions, braces surround a required choice of options; you must choose one of the options listed. boldface text Boldface text represents the introduction of a new term or the name of an argument, an attribute, or a reason. Boldface text is also used to show user input in Bookreader versions of the manual. italic text Italic text emphasizes important information, indicates variables, and indicates complete titles of manuals. Italic text also represents information that can vary in system messages (for example, Internal error number), command lines (for example, IPRODUCER=name), and command parameters in text. UPPERCASE TEXT Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege. A hyphen in code examples indicates that additional arguments to the request are provided on the line that follows. numbers All numbers in text are assumed to be decimal, unless otherwise noted. Nondecimal radixes-binary, octal, or hexadecimal-are explicitly indicated.
xviii Part I Security Overview
The chapters in this part discuss the following topics: • Sources of security failures (Section 1.1) • Levels of security requirements (Section 1.2) • Reference monitor concept of security design (Section 2.1) • Security features of the operating system (Section 2.2)
1 Understanding System Security
Effective operating system security measures help prevent unauthorized access and theft of computer time and any kind of sensitive information, such as marketing plans, formulas, or proprietary software. These measures can also protect equipment, software, and files from damage caused by tampering. This chapter provides security administrators with an overview of security measures available with the operating system.
1.1 Types of Computer Security Problems On any system there can be two types of users: authorized and unauthorized. Any person authorized to use the computer system has the right to access the system and its resources according to the authorization criteria set up by the site security administrator. Usage criteria can include the time of day, types oflogins, use of different resources like printers, terminals, and so on. Unauthorized users have no right to use the system at all or only at a given time of day, or they have no right to use certain system resources. On a computer system, security breaches usually result from one of three types of actions: user irresponsibility, user probing, or user penetration. • User irresponsibility refers to situations where the user purposely or accidentally causes some noticeable damage. One example would be a user who is authorized to access certain files making a copy of a key file to sell. There is little that an operating system can do to protect sites from this source of security failure. The problem frequently lies in application design deficiencies or inconsistent use of available controls by users and the security administrator. Sometimes the failure to enforce adequate environmental security unwittingly encourages this type of security problem. Even the best security system will fail if implemented inconsistently. This, along with the failure to motivate your users to observe good security practices, will make your system vulnerable to security failures caused by user irresponsibility. • User probing refers to situations where a user exploits insufficiently protected parts of the system. Some users consider gaining access to a forbidden system area as an intellectual challenge, playing a game of user versus system. Although intentions may be harmless, theft of services is a crime. Users with more serious intent may seek confidential information, attempt embezzlement, or even destroy data by probing. Always treat user probing seriously. The system provides many security features to combat user probing. Based on security needs, the security administrator implements features on either a temporary or permanent basis. These features are discussed in Part II.
1-1 Understanding System Security 1.1 Types of Computer Security Problems
• User penetration refers to situations where the user breaks through security controls to gain access to the system. While the system has security features that make penetration extremely difficult, it is impossible to make any operating system completely impenetrable. A user who succeeds in penetrating a system is both skilled and malicious. Thus, penetration is the most serious and potentially dangerous type of security breach. With proper implementation of the OpenVMS security features, however, it is also the rarest security breach, requiring unusual skills and perseverance.
1.2 Levels of Security Requirements Each site has unique security requirements. Some sites require only limited measures because they are able to tolerate some forms of unauthorized access with little adverse effect. At the other extreme are those sites that cannot tolerate even the slightest probing, such as strategic military defense centers. In between are many commercial sites, such as banks. While there are many considerations in determining your security needs, the questions in Table 1-1 can get you started. Your answers can help in determining the levels of your security needs. Also refer to Chapter 7 for additional aspects of system use to consider.
Table 1-1 Event Tolerance as a Measure of Security Requirements Level of Security Requirements Question: Could you tolerate Based on Toleration Responses the following event? Low Medium High A user knowing the images being executed on your system y y N A user knowing the names of another user's files y y N A user accessing the file of another user in the group y y N An outsider knowing the name of the system just dialed into y y N A user copying files of other users y N N A user reading another user's electronic mail y N N A user writing data into another user's file y N N A user deleting another user's file y N N A user being able to read sections of a disk that might contain various old files y N N A user consuming machine time and resources to perform unrelated or unauthorized work, possibly even playing games y N N
1-2 Understanding System Security 1.2 Levels of Security Requirements
If you can tolerate most of the events listed, your security requirements are quite low. If your answers are mixed, your requirements are in the medium to high range. Generally, those sites that are most intolerant to the listed events have very high levels of security requirements. When you review your site's security needs, do not confuse a weakness in site operations or recovery procedures as a security problem. Ensure that your operations policies are effective and consistent before evaluating your system security requirements. 1.3 Building a Secure System Environment There are two sources of security problems outside the operating system domain: employee carelessness and facility vulnerability. If you have a careless or malicious employee or your facility is insecure, none of the security measures discussed in this guide will protect you from security breaches. Most system penetration occurs through these environmental weaknesses. It is much easier to physically remove a small reel of tape than it is to break access protection codes or change file protection. Digital strongly encourages you to stress environmental considerations as well as operating system protections when reviewing site security. This book discusses operating system security measures. When deciding on which of these measures to implement, it is important for you to assess site security needs realistically. While instituting adequate security for your site is essential, instituting more security than actually necessary is costly and time-consuming. When deciding which security measures to apply to your system, remember the following: • The most secure system is also the most difficult to use. • Increasing security can increase costs in terms of slower access to data, slower machine operations, and slower system performance. • More security measures require more personnel time. The operating system provides the basic mechanisms to control access to the system and its data. It also provides monitoring tools to ensure that access is restricted to authorized users. However, many computer crimes are committed by authorized users with no violation of the operating system's security controls. Therefore, the security of your operation depends on how you apply these security features and how you control your employees and your site. By first building appropriate supervisory controls into your application and designing your application with the goal of minimizing opportunities for abuse, you can then implement operating system and site security features and produce a less vulnerable environment.
1-3
2 OpenVMS Security Model
This chapter presents the concepts that guided the design and implementation of the security features and mechanisms incorporated into the operating system. The intent is to provide a framework for thinking about your total system security picture. Subsequent chapters present details about the security features and their use. 2.1 Reference Monitor Concept In the late 1960s, a great deal of research and development was dedicated to the problem of achieving security in multiuser computer systems. Much of the development work involved attempts to find all the things that could go wrong with a system's security and then to correct those flaws one by one. It became apparent to the researchers that this process was ineffective; effective system security could result only from a basic model of the structure of a secure computer system. The reference monitor concept was proposed as such a model and gained wide acceptance. According to the reference monitor concept, a computer system can be depicted in terms of subjects, objects, an authorization database, an audit trail, and a reference monitor. The reference monitor is the control center that authenticates subjects and implements and enforces the security policy for every access to an object by a subject. Figure 2-1 shows the relationship of these elements. Subjects are active entities, such as user processes, that gain access to information on behalf of people. Objects are passive repositories of information to be protected, such as files. The authorization database contains the security attributes of subjects and objects. From these attributes, the reference monitor determines what kind of access (if any) is authorized. The audit trail maintains a record of all security-relevant events, such as access attempts, successful or not, as required by the authorization database.· The reference monitor enforces the security rules by authorizing the creation of subjects, by granting subjects access to objects based on the information in a dynamic authorization database, and by recording events, as necessary, in the audit trail. In an ideal system, the reference monitor must meet the following three requirements: • Mediate every attempt by a subject to gain access to an object • Provide a tamperproof database and audit trail that are thoroughly protected from unauthorized observation and modification • Remain a small, simple, and well-structured piece of software so that it is effective in enforcing security requirements
2-1 OpenVMS Security Model 2.1 Reference Monitor Concept
Figure 2-1 Reference Monitor
Authorization Database
Subject: System User Authorization File, Rights Database, Network Proxy Authorization File Object: UIC-Based Protection Code, Owner UIC, ACL
Audit: Audit Database (Location and listing• of enabled events)
Object: Files, Queues, Volumes, Subject: Devices (Disks, Mailboxes, Users, Processes, --•- Reference Monitor --•·· Terminals), Global Sections, Batch Jobs ... Logical Name Tables, Resource Domains, Common Event Flag Clusters
Audit Trail: Audit Log File Operator Alarms
ZK-2446A-GE
A system that meets all requirements of the reference monitor model is very secure. These are the requirements proposed for systems that are secure even against penetration. (In such systems, the reference monitor is implemented by a security-related subset, or security kernel, of the operating system.) While the OpenVMS operating system is not such a system, its interface to users and system managers does mirror the basic structure dictated by the reference monitor concept. Experience shows that incorporating such a structure-is the best way to build a system resistant to probing and to most attempts at penetration. 2.2 Implementation of the Reference Monitor The following sections describe how the reference monitor is implemented in the OpenVMS operating system.
2-2 OpenVMS Security Model 2.2 Implementation of the Reference Monitor
2.2.1 Subjects Subjects are the users or user agents (the user processes) that access information and, in some cases, may be prevented from accessing information. For example, when a user logs in to use the operating system interactively or when a batch or network job starts, the operating system creates a process that includes the identity of the user. That process gains access to information as the agent for the user. Processes are vulnerable to security breaches while they are being created and while they are accessing information. The system manages process access to information by using its authorization data and internal mechanisms, such as hardware controls. Because process creation has many areas of security vulnerability, many operating security features concentrate on the area of process (or subject) creation. When a user attempts to log in to a system, the user provides a user name (a name that will be given to the resulting process) and a password. The password serves as an authenticator that should be known only to the user and to the operating system. Because a short or obvious password is likely to fail this requirement, the system incorporates many password protection mechanisms that can be invoked by the user or required by the security administrator. The operating system is also capable of limiting the number of attempts that an intruder can make to guess a password. Briefly, then, the association of the user with a subject (process) is a critical aspect of system security. The file of users' passwords is part of the security database that must be protected from unauthorized observation and modification. The system meets this requirement by storing the passwords in a file protected from general access, the system user authorization file (SYSUAF.DAT). The system takes the additional precaution of storing passwords in an encoded form that is not usable if stolen. Once the operating system creates a process for a user, it assigns a user identification code or UIC from the user authorization record to that process. The UIC corresponds to the name of the user who created the process (as authenticated by the user's password). In addition, the UIC indicates the user's membership in a group that can correspond to the user's department, project, or function. The system can also attach additional information to the process regarding the creation of the process and the affiliation of the process owner with other groups. This additional information plays a part in the application of the authorization database, which is described in Chapter 4 and Chapter 5. 2.2.2 Objects In the reference monitor concept, objects are passive repositories of information. In the OpenVMS system, there are many objects subject to protection. The most common object in an OpenVMS system is a file. The operating system protects files from unauthorized access and provides a variety of mechanisms (described in Chapter 4) for sharing them in a controlled manner. Objects other than files can also store sensitive information. These objects include common event flag clusters, devices, group global sections, logical name tables, resource domains, system global sections, volumes, and queues.
2-3 OpenVMS Security Model 2.2 Implementation of the Reference Monitor
Besides storing information, an object can be a resource to which the system controls access. In the OpenVMS system, the capability object class protects resources; for example, the ability to process vector instructions is a system capability. The capability object employs the same protection mechanisms as the objects storing information. 2.2.3 Authorization Database According to the reference monitor model, each subject's authorization to gain 1 access to an object is based on an ' abstract authorization database. This database is a set of dynamic security attributes that govern a subject's access to an object at any given time. In the OpenVMS system, the database is distributed and stored in association with the objects that must be protected. For example, the authorization data for a file or directory is stored in the file header for that file or directory. As Section 2.2.2 suggested, different objects in the OpenVMS system can be shared with differing levels of flexibility. Protected objects are subject to a protection code. This code specifies whether access is allowed or denied to processes run on behalf of system users, the user who is owner of the object, other members of the UIC group of the owner, and all other users. In addition to the protection code, objects can be shared under control of access control lists (ACLs). ACLs provide a finer granularity of access control than VIC-based protection, especially for user groups or subsets of groups. ACLs list individual users or groups of users who are to be allowed or denied access to the object. ACLs specify sharing on the basis of UIC identification as well as other groupings or identifiers that can be associated with a process. For example, it is possible to specify that a file should never be read by a process connected to a terminal on a dialup line. Section 4.4 describes ACLs and identifiers in detail. 2.2.4 Audit Trail All security-relevant events can be recorded in an audit log file, sent to an operator terminal, or both. A terminal can be designated as a security operator terminal where all auditable events can be displayed. An audit log file provides a permanent record of security events. Many times a security administrator can find a pattern of activity, called an audit trail, by studying the log file, Some events, such as certain login failures, are always auditable. Other events, such as successful or unsuccessful attempts to gain access to sensitive files, can be selected by users or security administrators for auditing. For example, the owner of a sensitive file may create an ACL entry requesting that all accesses to that file be audited. The operating system audits the following classes of security events by default: changes to the authorization, rights, and network proxy databases; attempted break-ins; use of the SET AUDIT command; all events requested by an Audit or Alarm ACE; and all login failures. The audit log allows users and security administrators to record many events. Because it is time-consuming to examine every event, it is most efficient to audit events that will contribute the most information to your security picture. See Chapter 6 for a description of security auditing.
2-4 OpenVMS Security Model 2.2 Implementation of the Reference Monitor
2.2.5 Reference Monitor In the OpenVMS operating system, the executive performs the role of the reference monitor. All system programs that run in kernel and executive mode help implement the reference monitor, as do the command line interpreter and certain user-mode images that run with privilege. While the volume of code comprising the executive is large, Digital attempts to ensure that none of the code can be used to bypass system security. Some privileges can grant a user the authority to modify or subvert the reference monitor. For example, a process with the BYPASS privilege can gain access to any object without reference to the authorization database. Clearly, granting such critical privileges should be severely limited. Similarly, give privileges such as SYSPRV and SECURITY only to users whose processes help maintain the reference monitor and authorization database. 2.2.6 Authorization Database Represented as an Access Matrix The reference monitor model specifies an authorization database, which describes all access authorizations in the system for all subjects and all objects. This database is often represented as an access matrix, which lists subjects on one axis and objects on the other (see Figure 2-2). Each crosspoint in the matrix thus represents the access that one subject has to one object.
Figure 2-2 Authorization Access Matrix
Objects: v w x y z
Subjects:
A * *
B * c * * *
D * * * *
E * ZK-1061A-GE In this access matrix, an asterisk ( * ) denotes that the subject has access to that object (different types of access, such as read and write, are omitted from this example for simplicity). Thus, subjects B, C, and Dall have access to objects W, X, and Y. In addition, subject A has a,ccess to objects W and Z, subject D to object V, and subject E to object V. Breaking up the access matrix by rows yields a capability-based model, in which each subject carries a list of the objects that it can access. Thus, a capability representation of this access matrix would appear as follows: A:W,Z B:W,X, Y C:W,X, Y D: V, W, X, Y E:V
2-5 OpenVMS Security Model 2.2 Implementation of the Reference Monitor
It is also possible to break up the access matrix by columns, listing for each object the subjects that have access to it. This results in an authority-based model, implemented in the OpenVMS system by ACLs (see Chapter 4). The ACL representation appears as follows: V: D, E W: A, B, C, D X:B,C,D Y:B,C,D Z:A The ACL and identifier controls used by the operating system combine the properties of both the capability- and authority-based systems. The result is an extremely powerful and flexible system capable of representing complex access matrixes in a compact and convenient manner. Consider what happens to the previous example of an access matrix when some of the cross-points have labels, as shown in Figure 2-3.
Figure 2-3 Authorization Access Matrix with Labeled Cross-Points
Objects: v w x y z
Subjects: A * * B a a Q c a a a
D p a a a
E p ZK-1062A-GE Some labeled cross-points can be grouped and treated as a single entity. Thus, the points that are labeled Q in Figure 2-3 represent the access that subjects B, C, and D have to objects W, X, and Y. All the Q points can be considered as a single area of interest. The system provides the concept of identifiers to take practical advantage of this grouping of areas of interest. You can define identifiers to represent the two groups of access, P and Q, in Figure 2-3. Note that two of the cross-points in the matrix remain unlabeled. Identifiers can also represent individual subjects and thus allow the traditional ACL facility. To represent the access matrix, the OpenVMS operating system uses two structures, one for each dimension. The rights list represents the rows of the access matrix and thus corresponds to the capability model. For the matrix in Figure 2-3, you would need the following rights list: B:Q C:Q D: P,Q E: p
2-6 OpenVMS Security Model 2.2 Implementation of the Reference Monitor
ACLs for the protected objects represent the columns of the access matrix. For this example, you would need the following ACLs: V: p W:A,Q X:Q Y:Q Z:A Note that the system structures required to represent the access matrix are simpler than either the traditional capability or authority model and require fewer terms in total. In the example, the difference is slight. However, complexity of the access matrix increases with the square of its size. 2.3 Summary: System Security Design When designing an overall system security plan, ask yourself the following questions: • How are users associated with subjects? What is the reliability of the authentication mechanism? • What objects contain sensitive information in this system or application? Is access to those objects controlled? • Does the authorization database reflect the site's security policy? Who is authorized to gain access to sensitive objects? Are adequate restrictions in place? • Is the audit trail recording enough or too much information? Who will monitor it? How often will it be examined? • What programs are functioning as part of the reference monitor? Which users can modify the security policy and the authorization database? Is this the desired configuration? These considerations, as well as the underlying reference monitor design, apply equally to a time-shared system, a widespread network, or a single application on a system that grants access to records in a file or database. The operating system provides general mechanisms that users and security administrators must apply to achieve system security.
2-7
Part II Security for the User
The chapters in this part discuss the following topics: • Login and logout processes (Chapter 3) • Password use (Chapter 3) • Security profiles of subjects and objects (Chapter 4) • Object protection mechanisms (Chapter 4) • Characteristics of object classes (Chapter 4)
3 Using the System Responsibly
This chapter provides basic information on how to use the system securely. If you apply this knowledge consistently and accurately, while observing your site's specific security policies, you can make the difference between a secure system and one that is vulnerable to unauthorized users. 3.1 Choosing a Password for Your Account To choose a secure password, use the following guidelines: • Include both numbers and letters in the password. Although a 6-character password that contains only letters is secure, a 6-character password with both letters and numbers is much more secure. • Choose passwords that contain 6 to 10 characters. Adequate length makes passwords more secure. You can choose a password as long as 32 characters. • Do not select passwords from a dictionary or from your native language. • Avoid choosing words readily associated with your computer site or yourself, such as the name of a product or the model of your car. • Choose new passwords each time. Do not reuse old ones. Your security administrator may set up additional restrictions, for example, not allowing passwords with fewer than 10 characters. Table 3-1 provides examples of secure as opposed to risky passwords.
Table 3-1 Secure and Insecure Passwords Secure Passwords Insecure Passwords Nonsense syllables: Words with a strong personal association: aladaskgam your name eojfuvcue the name of a loved one joxtyois the name of your pet the name of your town the name of your automobile A mixed string: A work-related term: 492 weid your company name $924spa a special project zu_$rags your work group name
3.1.1 Obtaining Your Initial Password Typically, when you learn that an account has been created for you on the system, you are told whether a user password is required. If user passwords are in effect, you are told to use a specific password for your first login. This password has been placed in the system user authorization file (SYSUAF.DAT) with other information about how your account can be used.
3-1 Using the System Responsibly 3.1 Choosing a Password for Your Account
It is inadvisable to have passwords that can be easily guessed. Ask the person creating an account for you to specify a password that is difficult to guess. If you have no control over the password you are given, you might be given a password that is the same as your first name. If so, change it immediately after you log in. (The use of first or last names as passwords is a practice so well known that it is undesirable from a security standpoint.) Log in to your account soon after it is created to change your password. If there is a time lapse from the moment when your account is created until your first login, other users might log in to your account successfully, gaining a chance to damage the system. Similarly, if you neglect to change the password or are unable to do so, the system remains vulnerable. Possible damage depends largely on what other security measures are in effect. At the time your account is created, you should also be told a minimum length for your password and whether you can choose your new password or let the system generate the password for you. 3.1.2 Observing System Restrictions on Passwords The system screens passwords for acceptability, as follows: • It automatically compares new passwords to a system dictionary. This helps to ensure that a password is not a native language word. • It maintains a history list of your old passwords and compares each new password to this list to be sure that you do not reuse an old password. • It enforces a minimum password length, which the system manager specifies in your UAF record.
3.2 Knowing What Type of Password to Use There are several types of passwords recognized by the OpenVMS operating system. In general, you need to provide a user password when you log in. In some cases, you might also need to provide a system password to gain access to a particular terminal before logging in with your user password. If you are using a system with high security requirements, you might need to provide a primary password and a secondary password. Table 3-2 describes each type of password.
Table 3-2 Types of Passwords User password Required for most accounts. After you enter your user name, you are prompted for a password. If the account requires both primary and secondary passwords, two passwords must be entered. System password Controls access to particular terminals and is required at the discretion of the security administrator. System passwords are usually necessary to control access to terminals that might be targets for unauthorized use, such as dialup and public terminal lines. Primary password The first of two passwords to be entered for an account requiring both primary and secondary passwords. (continued on next page)
3-2 Using the System Responsibly 3.2 Knowing What Type of Password to Use
Table 3-2 (Cont.) Types of Passwords
Secondary password The second of two passwords to be entered for an account requiring both primary and secondary passwords. The secondary password provides an additional level of security on user accounts. Typically, the general user does n
3.2.1 Entering a System Password Your security administrator will tell you if you must specify a system password to log in to one or more of the terminals designated for your use. Ask your security administrator for the current system password, how often it changes, and how to obtain the new system password when it does change. To specify a system password, do the following: 1. Press the Return key until the terminal responds with the recognition character, which is normally a bell.
IReturn I
As this example shows, there is no prompt and no echo of the characters you type. If you fail to specify the correct system password, the system does not notify you. (Initially, you might think the system is malfunctioning unless you know that a system password is required at that terminal.) If you do not receive a response from the system, assume that you have entered the wrong password and try again. 3. When you enter the correct system password, you receive the system announcement message, if there is one, followed by the U sername: prompt. For example: MAPLE - A member of the Forest Cluster Unauthorized Access Is Prohibited Username:
3-3 Using the System Responsibly 3.2 Knowing What Type of Password to Use
3.2.2 Entering a Secondary Password Your security administrator decides whether to require the use of secondary passwords for your account at the time your account is created. When your account requires primary and secondary passwords, you need two passwords to log in. Minimum password length, which the security administrator specifies in your UAF record, applies to both passwords. An example of a login requiring primary and secondary passwords follows:
WILLOW - A member of the Forest Cluster Welcome to OpenVMS on node WILLOW Username: RWOODS Password: IReturn I Password: IReturn I Last interactive login on Friday, ll-DEC-1993 10:22 $ As with a single password login, the system allots a limited amount of time for the entire login. If you do not enter a secondary password in time, the login period expires. 3.3 Password Requirements for Different Types of Accounts Four types of user accounts are available on OpenVMS systems: • Accounts secured with passwords that you or the security administrator change periodically. This account type is the most common. • Accounts that always require passwords but prohibit you from changing the password. By locking the password (setting the LOCKPWD flag in the UAF record), the security administrator controls all changes made to the password. • Restricted accounts limit your use of the system and sometimes require a password. • Open accounts require no password; the password is null. When you log in to an open account, the system does not prompt you for a password, and you do not need to enter one. You can begin entering commands immediately. Because open accounts allow anyone to gain access to the system, they are used only at sites with minimal security requirements.
3.4 Types of Logins and Login Classes Logins can be either interactive or noninteractive. When you log in interactively, you enter a user name and a password. In noninteractive logins, the system performs the identification and authentication for you; you are not prompted for a user name and password. (The term interactive, as used here, differs from an interactive mode process defined by the DCL lexical function F$MODE( ). For a description of the F$MODE function, see the Open VMS DCL Dictionary.)
3-4 Using the System Responsibly 3.4 Types of Logins and Login Classes
In addition to interactive and noninteractive logins, the OpenVMS operating system recognizes different classes of logins. How you log in to the system determines the login class to which you belong. Based on your login class, as well as the time of day or day of the week, the system manager controls your access to the system. 3.4.1 Logging In Interactively: Local, Dialup, and Remote Logins Interactive logins include the following login classes: • Local You log in from a terminal connected directly to the central processor or from a terminal server that communicates directly with the central processor. • Dialup You log in to a terminal that uses a modem and a telephone line to make a connection to the computer system. Depending on the terminal that your system uses, you might need to execute a few additional steps initially. Your site security administrator can give you the necessary details. • Remote You log in to a node over the network by entering the DCL command SET HOST. For example, to access the remote node HUBBUB, you enter the following command: $ SET HOST HUBBUB If you have access to an account on node HUBBUB, you can log in to that account from your local node. You have access to the facilities on node HUBBUB, but you remain physically connected to your local node. 3.4.2 Reading Informational Messages When you log in from a terminal that is directly connected to a computer, the OpenVMS system displays informational system messages. Example 3-1 illustrates most of these messages.
Example 3-1 Local Login Messages
WILLOW - A member of the Forest Cluster C) Unlawful Access is Prohibited Username: RWOODS Password: You have the following disconnected process: f} Terminal Process name Image name VTA52: RWOODS (none) Connect to above listed process [YES]: NO Welcome to OpenVMS on node WILLOW 0 Last interactive login on Wednesday, 1-DEC-1993 10:20 ~ Last non-interactive login on Monday, 30-NOV-1993 17:39~ 2 failures since last successful login ~
You have 1 new mail message. f'j
$
3-5 Using the System Responsibly 3.4 Types of Logins and Login Classes
0 The announcement message identifies the node (and, if relevant, the cluster). It may also warn unauthorized users that unlawful access is prohibited. The system manager or security administrator can control both the appearance and the content of this message. 8 A disconnected job message informs you that your process was disconnected at some time after your last successful login but is still available. You have the option of reconnecting to the old process and returning your process to its state before you were disconnected. The system displays the disconnected job message only when the following conditions exist: • The terminal where the interruption occurred is set up as a virtual terminal. • Your terminal is set up as one that can be disconnected. • During a recent session, your connection to the central processing unit (CPU) through that terminal was broken before you logged out. In general, the security administrator should allow you to reconnect to a disconnected job because this ability poses no special problems for system security. However, the security administrator can disable this function by changing the setup on terminals and by disabling virtual terminals on the system. (For information on setting up and reconnecting to virtual terminals, refer to the Open VMS System Manager's Manual.) 0 A welcome message indicates the version number of the OpenVMS operating system that is running and the name of the node on which you are logged in. The system manager can choose a different message or can suppress the message entirely. 8 The last successful interactive login message provides the time of the last completed login for a local, dialup, or remote login. (The system does not count logins from a subprocess whose parent was one of these types.) 0 The last successful noninteractive login message provides the time the last noninteractive (batch or network) login finished. 0 The number of login failures message indicates the number of failed attempts at login. (An incorrect password is the only source of login failure that is counted.) To attract your attention, a bell rings after the message appears. 0 The new mail message indicates if you have any new mail messages. A security administrator can suppress the announcement and welcome messages, which include node names and operating system identification. Because login procedures differ from system to system, it is more difficult to log in without this information. The last login success and failure messages are optional. Your security administrator can enable or disable them as a group. Sites with medium-level or high-level security needs display these messages because they can indicate break-in attempts. In addition, by showing that the system is monitoring logins, these messages can be a deterrent to potential illegal users. Each time you log in, the system resets the values for the last successful login and the number of login failures. If you access your account interactively and do not specify an incorrect password in your login attempts, you may not see the last successful noninteractive login and login failure messages.
3-6 Using the System Responsibly 3.4 Types of Logins and Login Classes
3.4.3 When the System Logs In for You: Network and Batch Logins Noninteractive logins include network logins and batch logins. The system performs a network login when you initiate a network task on a remote node, such as displaying the contents of a directory or copying files stored in a directory on another node. Both your current system and the remote system must be nodes in the same network. In the file specification, you identify the target node and provide an access control string, which includes your user name and password for the remote node. For example, a network login occurs when user Greg, who has an account on remote node PARIS, enters the following command:
$DIRECTORY PARIS 11 GREG 8G4FR93A"::WORK2:[PUBLIC]*.*;* This command displays a listing of all the files in the public directory on disk WORK2. It also reveals the password 8G4FR93A. A more secure way to perform the same task would be to use a proxy account on node PARIS. For an example of a proxy login, see Section 3.9.2. The system performs a batch login when a batch job that you submitted runs. Authorization to build the job is determined at the time the job is submitted. When the system prepares to execute the job, the job controller creates a noninteractive process that logs in to your account. No password is required when the job logs in. 3.5 Login Failures: When You Are Unable to Log In Logins can fail for any number of reasons. One of your passwords might have changed, or your account might have expired. You might be attempting to log in over the network or from a modem but be unauthorized to do so. The following table summarizes common reasons for login failure:
Failure Indicator: Reason: No response from the terminal. A defective terminal, a terminal that requires a system password, or a terminal that is not powered on. No response from any terminal. The system is down. No response from the terminal when you The system password changed. enter the system password. System messages: "User authorization failure" A typing error in your user name or password. The account or password expired. "Not authorized to log in from this Your particular class of login (local, dialup, source" remote, interactive, batch, or network) is prohibited. "Not authorized to log in at this time" You do not have access to log in during this hour or this day of the week. "User authorization failure" (and no An apparent break-in has been attempted at known user failure occurred) the terminal using your user name, and the system has temporarily disabled all logins at that terminal by your user name.
The following sections describe the reasons for login failure in more detail.
3-7 Using the System Responsibly 3.5 Login Failures: When You Are Unable to Log In
3.5.1 Using a Terminal That Requires a System Password You cannot log in if the terminal you attempt to use requires a system password and you are unaware of the requirement. All attempts at logging in fail until you enter the system password. If you know the system password, perform the steps described in Section 3.2.1. If your attempts fail, it is possible that the system password has been changed. Move to a different terminal that does not require a system password, or request the new system password. If you do not know the system password and you suspect that this is the problem, try logging in at another terminal. 3.5.2 Observing Your Login Class Restrictions If you attempt a class of login that is prohibited in your UAF record, your login fails. For example, your security administrator can restrict you from logging in over the network. If you attempt a network login, you receive a message stating that you are not authorized to log in from this source. Your security administrator can restrict your logins to include or exclude any of the following classes: local, remote, dialup, batch, or network. (For a description of these classes, see Section 3.4.1 and Section 3.4.3.) 3.5.3 Using an Account Restricted to Certain Days and Times Another cause of login difficulty is failure to observe your shift restrictions. A system manager or security administrator can control access to the system based on the time of day or the day of the week. These restrictions are imposed on classes of logins. The security administrator can apply the same work-time restrictions to all classes of logins or choose to place different restrictions on different login classes. If you attempt a login during a time prohibited for that login class, your login fails. The system notifies you that you are not authorized to log in at this time. When shift restrictions apply to batch jobs, jobs you submit that are scheduled to run outside your permitted work times are not run. The system does not automatically resubmit such jobs during your next available permitted work time. Similarly, if you' have initiated any kind of job and attempt to run it beyond your permitted time periods, the job controller aborts the uncompleted job when the end of your allocated work shift is reached. This job termination behavior applies to all jobs. 3.5.4 Failing to Enter the Correct Password During a Dialup Login Your security administrator can control the number of chances you are given to enter a correct password during a dialup login before the connection is automatically broken. If your login fails and you have attempts remaining, press the Return key and try again. You can do this until you succeed or reach the limit. If the connection is lost, you can redial the access line and start again. The typical reason for limiting the number of dialup login failures is to discourage unauthorized users attempting to learn passwords by trial and error. They already have the advantage of anonymity because of the dialup line. Of course, limiting the number of tries for each dial up does not necessarily stop this kind of break-in attempt. It only requires the would-be perpetrator to redial and start another login.
3-8 Using the System Responsibly 3.5 Login Failures: When You Are Unable to Log In
3.5.5 Knowing When Break-In Evasion Procedures Are in Effect If anyone has made a number of failed attempts to log in at the same terminal with your user name, the system can respond as though a break-in attempt is in progress. That is, the system concludes that someone is attempting to gain illegal access to the system by using your user name. At the discretion of your security administrator, break-in evasion measures can be in effect for all users of the system. The security administrator controls how many password attempts are allowed over what period of time. Once break-in evasion tactics are triggered, you cannot log in to the terminal-even with your correct password-during a defined interval. Your security administrator can tell you how long you must wait before reattempting the login, or you can move to another terminal to attempt a login. If you suspect that break-in evasion is preventing your login and you have not personally experienced any login failures, you should contact your security administrator immediately. Together, you should attempt another login and check the message that reveals the number of login failures since the last login to confirm or deny your suspicion of break-in attempts. (If your system does not normally display the login message, your security administrator can use the Authorize utility (AUTHORIZE) to examine the data in your UAF record.) With prompt action, your security administrator can locate someone attempting logins at another terminal. 3.6 Changing Your Password Changing passwords on a regular basis promotes system security. To change your password, enter the DCL command SET PASSWORD. The system manager can allow you to select a password on your own or can require that you use the automatic password generator when you change your password. If you select your own password, p.ote that the password must follow system restrictions on length and acceptability (see Section 3.1.2). For example, if your password choice is too short, the system displays the following message: %SET-E-INVPWDLEN, invalid password length - password not changed Section 3.1 provides guidelines and examples for specifying secure passwords. There is no restriction on how many times you can change your password in a given period of time. 3.6.1 Selecting Your Own Password If your system manager does not require use of the automatic password generator, the SET PASSWORD command prompts you to enter the new password. It then prompts you to reenter the new password for verification, as follows:
$ SET PASSWORD IReturnl New password: Verification: If you fail to enter the same password twice, the password is not changed. If you succeed in these two steps, there is no notification. The command changes your password and returns you to the DCL prompt. Even though your security administrator may not require the password generator, you are strongly encouraged to use it to promote the security of your system. Section 3.6.2 describes how to use generated passwords.
3-9 Using the System Responsibly 3.6 Changing Your Password
3.6.2 Using Generated Passwords If your system security administrator decides that you must let the system generate the password for you automatically, the system provides you with a list of password choices when you enter the DCL command SET PASSWORD. (You do not need to specify the /GENERATE qualifier.) The character sequence resembles native language words to make it easy to remember, but it is unusual enough to be difficult for outsiders to guess. Because system-generated passwords vary in length, they become even more difficult to guess.
The password generator uses basic syllabic rules to generate words but has no real knowledge of any language. As a result, it can unintentionally produce words that are offensive.
In the following example, the system automatically generates a list of passwords made up of random sequences of characters. The minimum password length for the user in the following example has been set to 8 in their UAF record. $ SET PASSWORD Old password: reankuna rean-ku-na f) cigtawdpau cig-tawd-pau adehecun a-de-he-cun ceebatorai cee-ba-to-rai arhoajabad ar-hoa-ja-bad Choose a password from this list, or press Return to get a new list 8 New password: IReturnl 0 Verification: IReturnl 0 $0 The preceding example illustrates the following: 0 The user correctly specifies the old password and presses the Return key. f) The system responds with a list of five password choices ranging in length from 8 to 10 characters. On OpenVMS VAX systems, there are representations of the same word divided into syllables to the right of each password choice (as shown here). Usually the password that is easiest to pronounce is easiest to remember and, therefore, the best choice. 8 The system informs the user that it is possible to request a new list by pressing the Return key in response to the prompt for a new password. 0 The user enters one of the first five possible passwords and presses the Return key. 0 The system recognizes that this password is one provided by the automatic password generator and responds with the verification prompt. The user enters the new password again and presses Return. 0 The system changes the password and responds with the DCL prompt. One disadvantage of automatic password generation is the possibility that you might not remember your password choice. However, if you dislike all the password choices in your list or think none are easy to remember, you can always request another list.
3-10 Using the System Responsibly 3.6 Changing Your Password
A more serious drawback of automatic password generation is the potential disclosure of password choices from the display the command produces. To protect your account, change your password in private. If you perform the change on a video terminal, clear the display of password choices from the screen after the command finishes. If you perform the change in a DECwindows environment, be aware that anyone could use the scroll bars to review your screen. If you use a printing terminal, properly dispose of all hardcopy output. If you later realize that you failed to protect your password in these ways, change your password immediately. Depending on site policy or your own judgment concerning the length of time your account was exposed, you might decide to notify your security administrator that a security breach could have occurred through your account. 3.6.3 Changing a Secondary Password To change a secondary password, use the DCL command SET PASSWORD /SECONDARY. You are prompted to specify the old secondary password and the new secondary password, just as in the procedure for changing the primary password. To remove a secondary password, press the Return key when you are prompted for a new password and verification. You can change primary and secondary passwords independently, but both are subject to the same change frequency because they share the same password lifetime. 3.6.4 Changing Your Password As You Log In Even if your current password has not yet expired, you can change your password when you log in to the system by including the /NEW_PASSWORD qualifier with your user name, as follows: WILLOW - A member of the Forest Cluster Username: RWOODS/NEW PASSWORD Password: - Welcome to OpenVMS on node WILLOW Last interactive login on Tuesday, 7-NOV-1993 10:20 Last non-interactive login on Monday, 6-NOV-1993 14:20 Your password has expired; you must set a new password to log in New password: Verification: Entering the /NEW_PASSWORD qualifier after your user name forces you to set a new password immediately after login. 3.7 Password and Account Expiration Times Your system manager can set up your account so that your password, or the account itself, expires automatically on a particular date and time. Password expiration times promote system security by forcing you to change your password on a regular basis. Account expiration times help to ensure that accounts are available only for as long as they are needed.
3-11 Using the System Responsibly 3. 7 Password and Account Expiration Times
3.7.1 Changing an Expired Password As you approach the expiration time of your password, you receive an advance warning message. The message first appears 5 days before the expiration date and at each subsequent login. The message appears immediately below the new mail message and sounds the bell character on your terminal to attract your attention. The message indicates that your password is expiring, as follows: WARNING -- Your password expires on Thursday 19-DEC-1993 15:00 If you fail to change your password before it expires, you receive the following message when you log in: Your password has expired; you must set a new password to log in New password: The system prompts you for a new password or, if automatic password generation is enabled, asks you to select a new password from those listed (see Section 3.6.2). You can abort the login by pressing Ctrl/Y. At your next login attempt, the system again prompts you to change your password. When You Are Using a Secondary Password If secondary passwords are in effect for your account (see Section 3.2), the secondary password expires at the same time as the primary one. You are prompted to change both passwords. If you change the primary password and press Ctrl/Y before changing the secondary password, the login fails. The system does not record a password change. When You Fail to Change Your Password If the system manager decides not to force you to change your expired password upon logging in, you receive one final warning when you log in after your password expires, as follows: WARNING -- Your password has expired; update immediately with SET PASSWORD! At this point, if you do not change the password or if the system fails before you have the opportunity to do so, you will be unable to log in again. To regain access, see your system manager. 3.7.2 Renewing an Expired Account If you need your account for a specific purpose for a limited time only, the person who creates your account may specify a period of time after which the account lapses. For example, student accounts at universities are typically authorized for a single semester at a time. Expired accounts deny logins automatically. You receive no advance warning message before the account expiration date, so it is important to know in advance your account duration. The account expiration resides in the UAF record, which can be accessed and displayed only through the use of the Authorize utility (AUTHORIZE) by users with the SYSPRV privilege or equivalent-normally, your system manager or security administrator. When your account expires, you receive an authorization failure message at your next attempted login. If you need an extension, follow the procedures defined at your site.
3-12 Using the System Responsibly 3.8 Guidelines for Protecting Your Password
3.8 Guidelines for Protecting Your Password Illegal system accesses involving the use of a correct password are more often traced to disclosure of the password by its owner than to surreptitious discovery. It is vital that you do not reveal your password to anyone. You can best protect your password by observing the following rules: • Select reasonably long passwords that cannot be guessed easily. Avoid using words in your native language that appear in a dictionary. Consider including numbers in your password. Alternatively, let the system generate passwords for you automatically. • Never write down your password. • Never give your password to another user. If another user obtains your password, change it immediately. • Do not include your password in any file, including the body of an electronic mail message. (If anyone else reveals a password to you, delete the information promptly.) The character strings that appear in conjunction with your actual password can make it easy for someone to find your password in a file. For example, a quotation mark followed by two colons("::) always comes after a user name and password in an access control string. Someone attempting to break into the system could obtain your password by searching inadequately protected files for this string. Another way in which you might reveal your password is by using the word "password" in a text file, for example: My password is GOBBLEDYGOOK. • If you submit a batch job on cards, do not leave your password card where others may be able to obtain your password from it. • Do not use the same password for accounts on different systems. An unauthorized user can try one password on every system where you have an account. The account that first reveals the password might hold little information of interest, but another account might yield more information or more privileges, ultimately leading to a far greater security breach. • Before you log in to a terminal that is already on, invoke the secure terminal server feature (if enabled) by pressing the Break key. This is particularly relevant when you are working in a public terminal room. A password grabber program is a special program that displays an empty video screen, a screen that appears to show the system has just been initialized after a crash, or a screen that shows a nonexistent logout. When you attempt to log in, the program runs through the normal login sequence so you think you are entering your user name and password in a normal manner. However, once the program receives this key information and passes it on to the perpetrator, it displays a login failure. You might think you mistyped your password and be unaware that you have just revealed it to someone else. To eliminate this possibility, your security administrator might advise you to press the Break key before logging in. Pressing the Break key invokes the secure terminal server feature for the terminal, if it has been enabled by the security administrator. The secure server ensures that the OpenVMS login program is the only program able to receive your login.
3-13 Using the System Responsibly 3.8 Guidelines for Protecting Your Password
• Unless you share your password, change it every 3 to 6 months. Digital warns against sharing passwords. If you do share your password, change it every month. • Change your password immediately if you have any reason to suspect it might have been discovered. Report such incidents to your security administrator. • Do not leave your terminal unattended after you log in. You might think the system failed and came back up again, when actually someone has loaded a password stealing program. Even a terminal that displays an apparently valid logout message might not reflect a normally logged out process. • Check your last login messages routinely. The password stealing program cannot actually increase the login failure count, although it looks like a login failure to you. Be alert for login failure counts that do not appear following your failure or that are one less than the number you .experienced. If you observe this or any other abnormal failure during a login, change your password immediately, and notify your security administrator.
3.9 Network Security Considerations This section describes how to use access control strings in file specifications and how to use proxy logins to help make network access more secure. 3.9.1 Protecting Information in Access Control Strings Network access control strings can be included in the file specifications of DCL commands working across the DECnet for OpenVMS network. They permit a user on a local node to access a file on a remote node. An access control string consists of the user name for the remote account and the user's password enclosed within quotation marks, as follows: NODE"username password"::disk:[directory]file.typ Because access control strings include sufficient information to allow someone to break in to the remote account, they create serious security exposure. To protect access control string information, do the following: • Avoid revealing the information on either hardcopy or video terminals. If you use a hardcopy terminal, dispose of the output properly. If you use a video terminal, clear the screen and empty the recall buffer with the DCL command RECALL/ERASE when the network job is completed. This prevents another user from seeing the password, either by displaying the command line with the Ctrl/B sequence or with the DCL command RECALUALL. DECwindows users can clear the screen with the "Clear Lines Off Top" option from the Commands menu. Otherwise, a DECwindows user could use the scroll bar to view previously entered text. • Do not place networking commands that include access control strings in command procedures where they would be likely targets for discovery. • If you must put access control strings in your command procedures, provide these files with optimum file protection by using the techniques described in Chapter 4. To avoid the need for access control strings, you might prefer to use proxy login accounts, which are described in Section 3.9.2.
3-14 Using the System Responsibly 3.9 Network Security Considerations
3.9.2 Using Proxy Login Accounts to Protect Passwords Proxy logins let you access files across a network without specifying a user name or password in an access control string. Thus, proxy logins have the following security benefits: • Passwords are not echoed on the terminal where the request originates. • Passwords are not passed between systems where they might be intercepted in unencrypted form. • Passwords are not needed in command files to perform the remote access steps. Before you can initiate a proxy login, the system or security· administrator at the remote node must create a proxy account for you. Proxy accounts, like regular accounts, are created with the Authorize utility (AUTHORIZE). They are usually nonprivileged accounts. Security administrators can allow you access to one default proxy account and up to 15 other proxy accounts. While proxy logins require more setup effort on the part of system managers, they provide more secure network access and eliminate the need for users to enter access control strings. The following examples illustrate the differences between a normal network login request and a proxy login request. For each example, the following conditions exist: • The user KMAHOGANY has two user accounts: An account on node BIRCH with the password "XYZ123ABC" An account on node WALNUT with the password "A25D3255" • KMAHOGANY has logged in to node BIRCH. • KMAHOGANY wants to copy the file BIONEWS.MEM from the default device and directory of the account on the node WALNUT. The following diagram illustrates these conditions:
At Home Node Remote Node BIRCH WALNUT
Username: KMAHOGANY Username: KMAHOGANY Password: XYZ123ABC Seeks from Password: A25D3255
STAFFDEV: [ KMAHOGANY] STAFFDEV: [ KMAHOGANY]
BIONEWS.MEM A copy of the file
ZK-2036-GE
The user KMAHOGANY could use an access control string to copy the file BIONEWS.MEM, as follows: $COPY WALNUT"KMAHOGANY A25D3255"::BIONEWS.MEM BIONEWS.MEM
3-15 Using the System Responsibly 3.9 Network Security Considerations
Notice that the password A25D3255 echoes. Anyone who observes the screen can see it. In contrast, if KMAHOGANY has proxy access from node BIRCH to the account on node WALNUT, the command for copying the file BIONEWS.MEM is as follows: $COPY WALNUT::BIONEWS.MEM BIONEWS.MEM KMAHOGANY does not need to specify a password in an access control string. Instead, the system performs a proxy login from the account on node BIRCH into the account on node WALNUT. There is no exchange of passwords. Using a General Access Proxy Account Your security administrator can also authorize groups of users from foreign nodes to share in the use of a general access proxy account. For example, the security administrator at node WALNUT can create a general access account with the following conditions: • The user name GENACCESS. • Access limited to network logins. • A password known only to the owner of the account. (None of the remote users need to know it.) This helps to protect the account. • The default device and directory STAFFDEV:[BIOSTAFF]. If the security administrator grants BIRCH::KMAHOGANY proxy access to the GENACCESS account, the user KMAHOGANY can copy the file BIONEWS.MEM by entering the following command: $COPY WALNUT::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM Note that KMAHOGANY must specify the directory [KMAHOGANY] because the file BIONEWS.MEM is not in the default device and directory for the GENACCESS account (STAFFDEV:[BIOSTAFF]). In addition, the protection for the file BIONEWS.MEM must permit access to the GENACCESS account. Otherwise, the command fails. When You Need to Specify the Name of a Proxy Account If you have access to more than one proxy account on a given node and you do not want to use the default proxy account, specify the name of the proxy account. For example, to use a proxy account called PROXY2 instead of the GENACCESS account (the default), KMAHOGANY enters the following command: $COPY WALNUT"PROXY2"::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM This command uses the PROXY2 account to copy the file BIONEWS.MEM from the [KMAHOGANY] directory on node WALNUT. 3.10 Auditing Access to Your Account and Files Although it is the security administrator's job to monitor the system for possible break;-in attempts, you can assist the security administrator in auditing access to your account and files. This section describes how to monitor your last login time for possible break-ins. It also describes how to work with your security administrator to enable certain types of auditing.
3-16 Using the System Responsibly 3.10 Auditing Access to Your Account and Files
3.10.1 Observing Your Last Login Time The operating system maintains information in your UAF record about the last time you logged in to your account. Your security administrator decides whether the system should display this information at login time. Sites with medium to high security requirements frequently display this information and ask users to check it for unusual or unexplained successful logins and unexplained failed logins. If there is a report of an interactive or a noninteractive login at a time when you were not logged in, report it promptly to your security administrator. Also change your password. The security administrator can investigate further by using accounting files and audit logs. If you receive a login failure message and cannot account for the failure, it is likely that someone has been trying to access your account unsuccessfully. Check your password to ensure that it adheres to all recommendations for password security described in Section 3.8. If not, change your password immediately. If you expect to see a login failure message and it does not appear or if the count of failures is too low, change your password. Report either of these indications of login failure problems to your security administrator. 3.10.2 Adding Access Control Entries to Sensitive Files If you have key files that may have been accessed improperly, you may want to develop a strategy with your security administrator to audit access to the files. Once you review the situation and ensure that you have done everything possible to protect your files with standard protection codes and general ACLs (described in the Chapter 4), you may conclude that security auditing is required. To specify security auditing, you can add special access control entries (ACEs) to files you own or to which you have control access. Keep in mind, however, that the audit log file is a systemwide mechanism, so Digital recommends that a site security administrator control the use of file auditing. Although you can add auditing ACEs to files over which you have control, the security administrator has to enable auditing of files on a system level. For example, if user RWOODS and his security administrator concur that they must know when a highly confidential file, CONFIDREVIEW.MEM, is being accessed, RWOODS can add an entry to the existing ACL for the file CONFIDREVIEW.MEM, as follows: $ SET SECURITY/ACL=(AUDIT=SECURITY,ACCESS=READ+WRITE _$ +DELETE+CONTROL+FAILURE+SUCCESS) CONFIDREVIEW.MEM After RWOODS adds the security-auditing entry, the security administrator enables file-access auditing, as Section 3.10.3.1 describes. An access violation of one file frequently indicates access problems with other files. Therefore, the security administrator may need to monitor access to all key files having security-auditing ACEs. When undesired access is gained to key files, the security administrator must take immediate action.
3-17 Using the System Responsibly 3.1 O Auditing Access to Your Account and Files
3.10.3 Asking Your Security Administrator to Enable Auditing A security administrator can direct the operating system to send an audit to the system security audit log file or an alarm to terminals enabled as security operator terminals whenever security-relevant events occur. For example, the security administrator might identify one or more files for which write access is prohibited. An audit can be enabled or an alarm can be set to indicate attempted access to these files. 3.10.3.1 Auditing File Access If you suspect break-in attempts to your account, the security administrator may temporarily enable auditing for all file access. The security administrator can also enable auditing to monitor read access to your files to catch file browsers. For example, assume you decide to audit the file CONFIDREVIEW.MEM, which has a security-auditing ACE (see Section 3.10.2). If user ABADGUY accesses CONFIDREVIEW.MEM and has delete access, the following audit record is written to the system security audit log file: %%%%%%%%%%% OPCOM 7-DEC-1993 07:21:11.10 %%%%%%%%%%% Message from user AUDIT$SERVER on BOSTON Security audit (SECURITY) on BOSTON, system id: 19424 Auditable event: Attempted file access Event time: 7-DEC-1993 07:21:10.84 PID: 23E00231 Username: ABADGUY Image name: BOSTON$DUAO:[SYS0.SYSCOMMON.][SYSEXE]DELETE.EXE Object name: BOSTON$DUAl:[RWOODS]CONFIDREVIEW.MEM;l Object type: file Access requested: DELETE Status: %SYSTEM-S-NORMAL, normal successful completion Privileges used: SYSPRV The auditing message reveals the name of the perpetrator, the method of access (successful deletion accomplished by using the program [SYSEXEJDELETE.EXE), time of access (7:21 a.m.), and the use of a privilege (SYSPRV) to gain access to the file. With this information, the security administrator can take action. Note that the security audit message is written to the security audit log file every time any file is accessed and meets the conditions specified in the audit entry of the ACL for that file (see Section 3.10.2). Access to the file CONFIDREVIEW.MEM, as well as access to any file on the system that is protected with security auditing, prompts an audit record to be written to the security audit log file. After auditing has been introduced, check with your security administrator periodically to see if any additional break-ins have occurred.
3-18 Using the System Responsibly 3.10 Auditing Access to Your Account and Files
3.10.3.2 Additional Events to Audit In addition to file auditing, the security administrator can select other types of events that warrant special attention when they occur. Events triggering an audit or alarm may include the following:
Events Initiating Security Audits or Alarms Logins, logouts, login failures, and Modifications to: break-in attempts System and user passwords System time Volume mounts and dismounts. System authorization file Network proxy file Rights database SYSGEN parameters Connection or termination of logical Execution of: links to remote nodes SET AUDIT command NCP commands Creation and deletion of selected Installation of images protected objects , Selected types of access and Access event requested by an ACL on a protected deaccess to selected protected object objects Successful or unsuccessful use of Use of the process control system services, a privilege or an identifier including $CREPRC and $DELPRC
3.11 Logging Out Without Compromising System Security Logging out of a session conserves system resources and protects your files. Leaving a terminal on line represents one of the greatest sources of inside break-ins. When you leave your terminal on line and your office open, you have effectively given away your password and your privileges and have left your files and those of the other members of your group unprotected. Any user can easily and quickly transfer all files accessible through your account. A malicious insider could rename and delete your files and any other files to which you have write access. If you have special privileges, especially privileges in the Files or All category, a malicious user can do major damage. Log out when you leave your office even for a brief period of time. If you have performed remote logins, you must log out of each node. The following sections describe security considerations for logging out of specific types of terminals or sessions. 3.11.1 Clearing Your Terminal Screen You may want to clear your screen each time you log out from a terminal to ensure that your user name, node name, and operating system are not revealed to anyone else. If you are logging out after a remote login, the name of the node to which you return (the local node) is also revealed. If you access multiple accounts remotely (over the network), the final sequence of logout commands reveals all the nodes and user names that are accessible to you on each node (excluding the name of the furthest node reached). To those who can recognize the operating system from the prompt or a logout message, these displays also reveal the operating system.
3-19 Using the System Responsibly 3.11 Logging Out Without Compromising System Security
At some sites, it may be important to leave nothing but the logout message on your screen, as follows: • If you are using a VT200- or later series terminal, you can clear the screen by pressing the Set-Up key and selecting the item from the resulting menu that corresponds to Clear Display. • If you are using a VTlOO-series terminal, press the Set-Up key. Then press the key marked for reset (the 0 key) followed by the Return key. Alternatively, to preserve temporary parameters, press the Set-Up key, and then press the key marked 80/132 columns (the 9 key) twice. After the screen clears, the cursor is positioned at the top of the screen, next to the DCL prompt. Enter the DCL command LOGOUT at the prompt. The only information remaining after you log out is your logout command and the logout completion message, for example: $ LOGOUT RDOGWOOD logged out at 14-AUG-1993 19:39:01.43 3.11.2 Disposing of Hardcopy Output After you log out from a hardcopy terminal, properly remove, file, or dispose of all hardcopy output that might reveal sensitive information. Your security administrator should provide direction on preferred procedures. Many sites use paper shredders or locked receptacles for this purpose. Handle output that you plan to save just as carefully. You should also dispose of hardcopy output if the system fails before you log out. In addition, if you will not be present when the system is initialized, turn your terminal off. 3.11.3 Removing Disconnected Processes The system automatically removes your disconnected processes after a certain interval. You can conserve system resources, however, if you directly log out of any disconnected processes, as follows: 1. Enter the DCL command SHOW USERS to determine if you have other disconnected jobs. 2. Enter the DCL command CONNECT/LOGOUT to log out of the current process. Connect back through each of the associated virtual terminals (as noted by the terminal prefix of VTA) until you reach the last existing process. 3. Enter the DCL command LOGOUT. 3.11.4 Breaking the Connection to a Dialup Line Your security administrator may ask you to break the connection to a dialup line when you log out. If you anticipate no further immediate use of the line, use the LOGOUT command with the /HANGUP qualifier. The /HANGUP qualifier directs the system to automatically break the connection to the dialup line after you log out.
Note ______~
The effectiveness of the /HANGUP qualifier depends on how your system manager configures your modem line and how the line connects to the computer. It does not work on lines connected to a terminal server.
3-20 Using the System Responsibly 3.11 Logging Out Without Compromising System Security
Breaking the connection to a dialup line prevents someone from taking advantage of an open access line. To access the line, someone must know the access number and must personally redial. Breaking the connection is especially important if the dialup line you use is in a public area or where someone might use the terminal after you. This practice also saves resources by reducing the required number of dialup lines. 3.12 Checklist for Contributing to System Security Although security features are implemented by the security administrator as requirements for all users, this chapter has described ways in which you can contribute to system security. The following list reviews voluntary security actions: D Choose a secure password by following the guidelines in Section 3.1. D Protect your password, and change it often. D Check your last login messages each time you log in and report any unexplained messages to your security administrator (Section 3.4.2). D Use proxy logins when possible (Section 3.4). D Log out and lock up when you leave your terminal and area (Section 3.11). D Use the /HANGUP qualifier with your final LOGOUT command from a dialup line (Section 3.11.4). D Properly dispose of hardcopy output from your terminal (Section 3.11.2). D Clear your screen, or turn off your video terminal to erase revealing displays (Section 3.11.1). D Lock up backup media. Anyone who has the media in hand can access the information that is stored on the tape or disk. D Ask your security administrator to enable security auditing for any protected objects, such as files, that you suspect have been accessed improperly (Section 3.10.3.1).
3-21
4 Protecting Data
This chapter extends the discussion of security design introduced in Chapter 2. It describes how the operating system controls the way a user process or an application can access a protected object. To summarize, the operating system controls access to any object that contains shareable information. These objects are known as protected objects. Devices, volumes, logical name tables, files, common event flag clusters, group and system global sections, resource domains, queues, capabilities, and security classes fall into this category. An accessing process carries credentials in the form of rights identifiers, and all protected objects list a set of access requirements specifying who has a right to access the object in a given manner. This chapter: • Describes the types of identification the· system assigns to processes to define their access rights to objects (Section 4.1) • Looks at the access controls that objects can hold (Section 4.2) • Shows how the operating system processes access requests (Section 4.3) • Explains how to control access to objects (Sections 4.4, 4.5, 4.6, 4. 7) • Discusses the unique features of each class of protected object: files, volumes, devices, and so on (Section 4.8)
4.1 Contents of a User's Security Profile User processes and applications as well as objects have security profiles, which contain a consistent set of elements. Before a process can access a file, device, global section, or any other protected object, the operating system checks to ensure that the requesting process has the authority to access the object in the manner requested. To establish this, the operating system examines the security profile of both the requesting process and the object.
The profile of a user process or application includes the following elements: • User identification code (UIC) identifying the user • Rights identifiers held by the process • Privileges, if any
4-1 Protecting Data 4.1 Contents of a User's Security Profile
4.1.1 User Identification Code (UIC) The first element of a subject's security profile is the user identification code (UIC). Your UIC tells what system group you belong to and what your unique identification is within that group. 4.1.1.1 Format of a UIC A UIC specification always appears in brackets, but its format can differ. Valid formats include the following: • Alphanumeric DIC-Consists of a member name and, optionally, a group name: [member] or [group,member] The group and member names can each contain up to 31 alphanumeric characters, at least one of which is alphabetic. The names can include upper and lowercase characters A through Z, dollar signs ( $ ), underscores ( _ ), and the numbers 0 through 9. • Numeric DIC-Contains a group number and a member number: [group,member] The group number is an octal number in the range of 1 through 37776; the member number is an octal number in the range of 0 through 177776. You can omit leading zeros when you are specifying group and member numbers. Digital reserves group 1 and groups 300-377 for its own use. The following table illustrates several UICs in proper UIC notation:
Type of UIC Example Meaning Alphanumeric [USER,FRED] Group USER, member FRED [EXEC,JONES] Group EXEC, member JONES [JONES] Group EXEC, 1 member JONES Numeric [200,10] Group 200, member 10 [3777 ,3777] Group 3777, member 3777
10nly one user can have the member name JONES; therefore JONES must belong to the EXEC group.
4.1.1.2 Guidelines for Creating a UIC UICs cannot be arbitrarily assigned. A security administrator has to observe the following guidelines when creating them: • Member names must be unique for each user on the system. • No member can participate in more than one UIC group. These guidelines exist because the system translates a UIC to a 32-bit value that represents a group number and a member number; the high-order 16 bits contain the group number, and the low-order 16 bits contain the member number. When translating an alphanumeric UIC such as [J_JONES], the operating system equates the member part of the alphanumeric UIC to both the group and member parts of a numeric UIC. The resulting 32-bit numeric UIC is kept in the rights
4-2 Protecting Data 4.1 Contents of a User's Security Profile
database (which is a file containing information about identifiers, their attributes, and holders). For example, you could not have the two UICs [GROUPl,JONES] and [GROUP2,JONES] on the same system because the member JONES can have only one associated numeric UIC. 4.1.1.3 How Your Process Acquires a UIC When you log in to a system, the operating system copies your UIC from your user authorization (UAF) record in the system user authorization file (SYSUAF.DAT) and assigns it to your process. It serves as an identification for the life of the process. By default, detached processes (created by the DCL command SUBMIT or RUN) and subprocesses (created by the DCL command SPAWN) take the same UICs as their creators. If you have DETACH privilege, you can create a detached process with a different UIC (by using the /UIC qualifier of the RUN command). 4.1.2 Rights Identifiers The second element of a subject's security profile is a set of rights identifiers. A rights identifier represents an individual user or a group of users. Using the Authorize utility (AUTHORIZE), security administrators create and remove identifiers and assign users to hold these identifiers. Rights identifiers can be a temporary way of identifying a group of users because users hold certain identifiers only as long as they are necessary. 4.1.2.1 Types of Identifiers The operating system supports several types of rights identifiers. Table 4-1 shows the identifiers that are most commonly used in access control.
Table 4-1 Major Types of Rights Identifiers Type Description Format Example
Environmental Describe different types Alphanumeric strings BATCH, NETWORK, identifiers of users based on their automatically created INTERACTIVE, initial entry into the by the system. See LOCAL, DIALUP, system. Section 3.4 for details. REMOTE
General Defined by the security Alphanumeric strings of 1 SALES, identifiers administrator. through 31 characters PERSONNEL, with at least one DATA_ENTRY, alphabetic character. RESERVE_DESK Valid characters include numbers 0 through 9, characters A through Z and a through z, the dollar sign ( $ ) and the underscore ( _ ).
(continued on next page)
4-3 Protecting Data 4.1 Contents of a User's Security Profile
Table 4-1 (Cont.) Major Types of Rights Identifiers Type Description Format Example
UIC identifiers Based on a user's Alphanumeric UICs, with [GROUPl,JONESJ, identification code (UIC), or without brackets. Valid [JONES], which uniquely identifies characters are the same GROUPl, a user on the system and as those for a general JONES defines the group to which identifier. the user belongs.
In addition to the identifiers listed in Table 4-1, a system node identifier of the form SYS$NODE_node_name is created by the system startup procedure (STARTUP.COM in SYS$SYSTEM). Applications can use yet another type of identifier, a facility identifier. The Open VMS Programming Concepts Manual describes its format and the procedure for assigning one. 4.1.2.2 Displaying the Rights Identifiers of Your Process You can display the identifiers for your current process with the SHOW PROCESS command, for example: $ SHOW PROCESS/ALL 25-JUN-1991 15:23:18.08 User: GREG Process ID: 34200094 Node: ACCOUNTS Process name: 11 TWA2: 11 Terminal: TWA2: User Identifier: [DOC,GREG] 0 Base priority: 4 Default file spec: WORKl:[GREG.FISCAL_91] Devices allocated: ACCOUNTS$TWA2: Process Quotas:
Process rights: INTERACTIVE f) LOCAL Q SALES 0 MINDCRIME resource 0 System rights: SYS$NODE_ACCOUNTS 0 Output from SHOW PROCESS command displays all three types of identifiers: 0 UIC identifier, indicating user Greg is a member of the DOC group f) Environmental identifier, indicating user Greg is an interactive user 0 Environmental identifier, indicating user Greg is logged in locally 0 General identifier, indicating user Greg is also a member of the SALES group 0 General identifier, indicating Greg holds the MINDCRIME identifier with the resource attribute so he can charge disk space to the identifier 0 Environmental identifier, indicating user Greg is working from the ACCOUNTS node
4-4 Protecting Data 4.1 Contents of a User's Security Profile
4.1.2.3 How Rights Identifiers Appear in the Audit Trail The rights identifiers of a process also appear in audit records. If a security administrator chooses to audit access to objects, then the operating system can produce a record of which users accessed objects and when. Although a single audit record rarely tells very much, the trail of records can, over a period of time, reveal a pattern of behavior that tells a story. The following audit record shows that user Greg attempted to delete a file but was prevented from doing so because he holds the identifier MINDCRIME. The file 93_FORECAST.DAT has an ACE preventing access by processes with the identifier MINDCRIME. (Relevant lines in the audit record are highlighted.) Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) and security audit (SECURITY) on ACCOUNTS, system id: 19662 Auditable event: Object deletion Event information: file deletion request (IO$ DELETE) Event time: 24-APR-1992 13:17:24.59 - PIO: 34200094 Process name: TWA2: Username: GREG Process owner: [DOC,GREG] Terminal name: TWA2: Image name: DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE Object class name: FILE Object owner: [SYSTEM] Object protection: SYSTEM:RWEDC, OWNER:RWEDC, GROUP:RE, WORLD:RE File name: DSA2200:[GREG]93 FORECAST.DAT;l File ID: (17481,6299,1) - Access requested: DELETE Matching ACE: (IDENTIFIER=MINDCRIME,ACCESS=NONE) Sequence key: 00008A41 Status: %SYSTEM-F-NOPRIV, no privilege for attempted operation 4.1.3 Privileges A third (optional) element of a subject's security profile is a set of privileges. Privileges let you use or perform system functions that you ordinarily would be denied. Security administrators can grant privileges to users under special circumstances so they can perform necessary tasks without changing existing protection authorizations. Privileges vary in power. Some allow normal network operations; for example, NETMBX and TMPMBX let you send and receive mail across the network. But others, such as SYSNAM, grant the ability to influence system operations. A user with the SYSNAM privilege can modify the system logical name table. A user's privileges are recorded in the user's UAF record in a 64-bit privilege mask. When a user logs in to the system, the user's privilege vector is stored in the process security profile. You can use the DCL command SET PROCESS/PRIVILEGES to enable and disable privileges for which you are are authorized, thus controlling the privileges available to the images you run. Example 4-1 shows user Puterman has a large number of authorized privileges, which are available for use when necessary, yet Puterman's process runs by default with only two privileges enabled: NETMBX and TMPMBX.
4-5 Protecting Data 4.1 Contents of a User's Security Profile
Example 4-1 Authorized Versus Default Process Privileges $ SHOW PROCESS/PRIVILEGE
8-0CT-1992 16:58:58.77 User: PUTERMAN Process ID: 27E00496 Node: FNORD Process name: 11 Hobbit 11 Authorized privileges: ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL DETACH DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT LOG IO MOUNT NETMBX OPER PFNMAP PHY IO PRMCEB PRMGBL PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD Process privileges: NETMBX may create network device TMPMBX may create temporary mailbox
Puterman can enable specific authorized privileges as he needs them; for example, he needs ALLSPOOL to allocate a spooled device and LOG_IO to perform logical I/O operations. 4.2 Security Profile of Objects
..... 01011- Because the operating system supports many users 0101011• 0101011• simultaneously, it has built-in security mechanisms to prevent one user's activities from interfering with •001-00010. another's. Protection codes, access controls, and ....10010 ... hardware design together protect the use of memory, ••11010001- shareable devices, and data so many users can share • 1000100 100 the system. 4.2.1 Definition of a Protected Object The objects of the OpenVMS operating system that require protection are all passive repositories that either contain or receive information. These objects are protected because once you have access to the object, you have access to the information it holds. Some examples of protected objects include: • A file in memory or on a storage device • A hardware device or a virtual device • A data structure, such as a common event flag cluster or a logical name table Section 4.2.5 lists the classes of objects that OpenVMS protects; refer to Section 4.8 for an in-depth description of each class. 4.2.2 Contents of an Object's Profile The security elements of any object comprise its security profile. An object's security profile contains the following types of information: • The owner of the object. The system uses this element in interpreting the protection code. • The protection code defining access to objects based on the categories of system, owner, group, and world. This protection code controls broad categories of users. • The access control list (ACL) controlling access to objects by individual users or groups of users.
4-6 Protecting Data 4.2 Security Profile of Objects
With the exception of files, a new object inherits its security elements from a system-supplied template profile, which the site security administrator may modify. Files have a more complicated inheritance mechanism, one that affords greater control over the security elements of new objects. In all cases, you can assign security elements during object creation rather than use the operating system defaults. This section gives an overview of protection codes and ACLs. Section 4.4 and Section 4.5 explore these protection mechanisms in greater detail. Refer to Section 4.8 for a description of individual object classes. 4.2.2.1 Owner The first element of an object's security profile is the UIC of its owner. In most cases, if you create an object, you are its owner. As the owner, you can modify its security profile. The system automatically assigns your UIC to the object and uses it in making access decisions. There are some exceptions to the ownership rule. Files owned by resource identifiers do not have a UIC. When a user creates a file in the directory of .a resource identifier, the file may be owned by the resource identifier and not the user who created the file (see Section 4.8.4.5). Refer to Section 4.8 for an explanation of the ownership rules for each object class. The owner of any object except a file can reassign ownership to another user with the SET SECURITY/OWNER command, as described in Section 4.2.4. Changing the owner of a file usually requires privilege (see Section 4.8.4.2). 4.2.2.2 Protection Code The second element of an object's security profile is the object's protection code. The system automatically assigns a protection code to each new object. The protection code associated with an object determines the type of access allowed to a user, based on the relationship between the user UIC and the owner UIC. With the exception of files, the code a protected object receives is derived from a template profile for the class. (A file's protection code originates from another source, described in Section 4.8.4.) Typically, you rely on the protection code to protect an object if the object is to be accessed by: (a) only the owner, (b) all users on the system, or (c) a specific VIC-based group of users. If you want to grant access to specific groups of users outside the UIC group but not to all users on the system, then you need to add an ACL (see Section 4.2.2.3). Interpreting a Protection Code A protection code defines the access rights for four categories of users: (a) the owner, (b) the users who share the same group UIC as the owner (the group category), (c) all users on the system (the world category), and (d) those with system privileges or rights (the system category). A code lists access rights in a fixed order: the system category (S), then owner (0), then group (G), and then world (W). It has the following syntax: [user category: access allowed (,user ·category: access allowed, ... )] When the operating system processes a request to use a protected object, it compares the user's UIC to the UIC of the object's owner. If the user's UIC is the same as the UIC of the object's owner, the user is granted the access of the owner protection field. Failing a match of UICs, the system progresses through the other user categories. The system tries to find a match of the group fields to
4-7 Protecting Data 4.2 Security Profile of Objects
determine if there is a common group membership. The system may also evaluate whether the UIC group number indicates the user belongs to the system category of users. For example, user Jones has a UIC of [14,1], and he tries to read a file that is owned by UIC [14,5]. Because Jones is in the same group (14), the system might grant access to the file. The final decision depends on the access rights specified in the protection code. , See Section 4.5 for a complete description of how to interpret and create protection codes. 4.2.2.3 Access Control List (ACL) The third (optional) element of an object's security profile is the object's access control list. An access control list (ACL) is a collection of entries that define the access rights a user or group of users has to a particular protected object, such as a file, directory, or device. ACLs may be created by default when an object is created, they may be created · by the security administrator, or they may be created by users for objects to which they have control access (see Section 4.6.2). Because security administrators can set up default ACLs, some users may be unaware that their objects have ACLs and may never change ACLs themselves. (You can use the DCL command DIRECTORY/SECURITY or SHOW SECURITY to see if there are ACLs on your files.) Other users are actively involved in creating and maintaining their own ACLs. Using ACLs is optional. Although AC Ls can enhance the security of objects in any installation through a more detailed definition of who is allowed what kind of access, users have to spend time creating and maintaining the ACLs. You use the DCL commands SET SECURITY and SHOW SECURITY for creating and displaying ACLs, although the access control list editor (ACL editor) is an important utility for more extensive work. Section 4.4 continues the discussion of ACLs and how to use them. 4.2.3 Displaying a Security Profile To see the security profile of any protected object, use the DCL command SHOW SECURITY. For example, the following command requests security information about the file 93_FORECAST.TXT: $ SHOW SECURITY 93_FORECAST.TXT WORK DISK$:[GREG]93 FORECAST.TXT;l object of class FILE - Owner: [ACCOUNTING,GREG] Protection: (System: RWED, Owner: RWED, Group: RE, World) Access Control List:
4-8 Protecting Data 4.2 Security Profile of Objects
4.2.4 Modifying a Security Profile You can provide new values for the owner, protection code, or ACL of a protected object or even copy a profile from one object to another by using the SET SECURITY command. For example, the SHOW SECURITY display in Section 4.2.3 shows the file 93_ FORECAST.TXT is owned by user Greg. As owner, he can change the protection code for that file. Originally, the code gave no access to users in the world category. Now, Greg changes that to allow read and write access to world users: $ SET SECURITY/PROTECTION=(W:RW) 93_FORECAST.TXT The SHOW SECURITY command verifies the new protection code for the file: $ SHOW SECURITY 93_FORECAST.TXT 93_FORECAST.TXT object of class FILE Owner: [GREG] Protection: (System: RWED, Owner: RWED, Group: RE, World: RW) Access Control List:
4-9 Protecting Data 4.2 Security Profile of Objects
Table 4-2 Classes of Protected Objects Class Name Definition Capability A resource to which the system controls access; currently, the only defined capability is the vector processor. Common event flag A set of 32 event flags that enable cooperating processes to post cluster event notifications to each other. Device A class of peripherals connected to a processor that are capable of receiving, storing, or transmitting data. File Files-11 On-Disk Structure Level 2 (ODS-2) files and directories. Group global section A shareable memory section potentially available to all processes in the same group. Logical name table A shareable table of logical names and their equivalence names for the system or a particular group. Queue A set of jobs to be processed in a batch, terminal, server, or print job queue. Resource domain A namespace controlling access to the lock manager's resources. Security class A data structure containing the elements and management routines for all members of the security class. System global A shareable memory section potentially available to all processes section in the system. Volume A mass storage medium, such as a disk or tape, that is in ODS-2 format. Volumes contain files and may be mounted on devices.
Refer to Section 4.8 for a detailed description of each class. 4.2.6 Access Required to Modify a Profile To modify a security profile, you need control access to the object. An ACL grants control access explicitly, whereas a protection code grants it implicitly to anyone who belongs to the owner or system category. (Refer to Section 4.6.2 for a full description of how you can acquire control access.) 4.3 How the System Determines If a User Can Access a Protected Object When a user tries to access a protected object, the operating system calls the Check Protection ($CHKPRO) system service to compare the security profile of the user process with the security profile of the object. In the protection check, $CHKPRO compares the user's security profile against the protected object's profile using the following sequence: 1. Evaluate the access control list (ACL). If the object has an ACL, the system scans it, looking for an entry that matches any of the user's rights identifiers. If a matching access control entry (ACE) is found, it either grants or denies access, and further checking of the ACL stops. When the matching ACE denies access, a user can still gain access through the system and owner fields of the protection code or through privilege. When an ACL has no matching ACE, the system checks all fields of the protection code.
4-10 Protecting Data 4.3 How the System Determines If a User Can Access a Protected Object
2. Evaluate the protection code. If the ACL did not grant access and the object's owner UIC is not zero, 1 the operating system evaluates the protection code. The operating system grants or denies access based on the relationship between the user's identification code (UIC) and the object's protection code. For cases where an ACL has denied access, the system examines two fields in the protection code-the system and owner fields-to determine if the user is allowed access. The user can still acquire access by being a member of the system or owner categories or by possessing privileges. A user holding GRPPRV (with a matching group UIC) or SYSPRV is granted the access specified for the system category of the protection code. 3. Look for special privileges. If access was not granted by the ACL or the protection code, privileges are evaluated. Users with certain system privileges may be entitled to access regardless of the protection offered by the ACLs or the protection code. The bypass privilege (BYPASS), group privilege (GRPPRV), read all privilege (READALL), or system privilege (SYSPRV) amplifies the holder's access to objects. (See Section 4.6.1 for more information on how privileges affect access.) 4. Consider access overrides. For some object classes, access may be granted based on alternate privileges. For example, the queue object allows full access to all queues for users with operator privilege (OPER), and the logical name table object allows access to the system table for users with system name privilege (SYSNAM). Figure 4-1 charts the sequence the operating system follows when it evaluates an access request and shows how the controlling components (ACLs, protection codes, privileges, and access overrides) interact.
1 When an object has an owner UIC of zero, the protection code is not checked. Users have all but control access to the object, provided the ACL has no Identifier ACEs. If Identifier ACEs are present, then access has to be granted explicitly through the ACL or through privilege.
4-11 Protecting Data 4.3 How the System Determines If a User Can Access a Protected Object
Figure 4-1 Flowchart of Access Request Evaluation
A request is made for a type of access to an object.
Check for an Identifier ACE.
ZK-2039.1-GE
(continued on next page)
4-12 Protecting Data 4.3 How the System Determines If a User Can Access a Protected Object
Figure 4-1 (Cont.) Flowchart of Access Request Evaluation
Check the protection code.
ZK-2039.2-GE
(continued on next page)
4-13 Protecting Data 4.3 How the System Determines If a User Can Access a Protected Object
Figure 4-1 (Cont.) Flowchart of Access Request Evaluation
Check for access through the system field.
Check for BYPASS or READALL privileges.
(continued on next page)
4-14 Protecting Data 4.3 How the System Determines If a User Can Access a Protected Object
Figure 4-1 {Cont.) Flowchart of Access Request Evaluation
Check for access through the owner field.
10
'- ~
Access granted; exit.
Access denied; Check for any exit. class-specific access method. -(
Access denied; exit.
Access granted; exit.
ZK-2039.4-GE
4-15 Protecting Data 4.4 Methods of Controlling Access with ACLs
4.4 Methods of Controlling Access with ACLs Section 4.2.2.3 introduced access control lists (ACLs) as one element of an object's security profile. This section explores this protection mechanism in depth and provides examples of how to use ACLs effectively to protect objects. Many users do not need to bother with ACLs because the protection codes that the operating system automatically assigns to objects are often sufficient. But there are times when you need to allow specific users access to your files, for example, when you are working on a common project. Because ACLs are an effective mechanism for protecting critical system files, devices, volumes, and other protected objects, system managers and security administrators use ACLs more often than general users. 4.4.1 Using Identifier Access Control Entries (ACEs) Each entry in an access control list (ACL) is called an access control entry (ACE). An ACL can have many entries, each of which defines some attribute of an object. There are many kinds of ACEs, which you can read about in the Open VMS System Management Utilities Reference Manual. Of interest here is the Identifier ACE, which controls access to objects. An Identifier ACE includes one or more rights identifiers and a list of the types of access the users holding the identifier have permission to exercise. When the system evaluates a user's rights to an object, it scans the object's ACL until it finds an Identifier ACE that matches the rights identifiers held by the accessing user;1 it grants or denies access based on that entry. The types of access that are granted (or denied) by an ACE depend on the object you are protecting. For example, you can read, write to, execute, and delete a file, whereas you can perform physical and logical operations on a device as well as reading and writing to it. Thus, a file supports read, write, execute, and delete access, and a device supports read, write, physical, and logical access. See Section 4.8 for information on the types of access other object classes support. To create an ACL with an Identifier ACE, use the DCL command SET SECURITY in the following format: SET SECURITY/ACL=(IDENTIFIER=identifier,ACCESS=access-type) For example, to let user Fred read your file PROJECT-DATA. TXT, you would enter the following command: $ SET SECURITY/ACL=(IDENTIFIER=FRED,ACCESS=READ) PROJECT-DATA.TXT The term FRED is the member name of a user identification code (UIC). As such, it serves as a UIC identifier for the entry that grants user Fred read access to the file PROJECT-DATA. TXT. 4.4.2 Granting Access to Particular Users Because identifiers define the rights of individual users or groups of users (see Section 4.1.2.1), you use them in an Identifier ACE to define the access granted (or denied) to those who hold them. A UIC identifier easily identifies an individual user or a group of users on the system. When a group of users from diverse functional groups (and therefore, diverse UIC groups) all need access to a protected object, a security administrator creates a general identifier and grants the identifier to all the users who need access.
1 If an Identifier ACE holds the Default attribute, the ACE is ignored in access evaluations. See Section 4.4. 7.
4-16 Protecting Data 4.4 Methods of Controlling Access with ACLs
For example, the following command grants user Pat, who is identified by the UIC identifier [PAT], read, write, and execute access to a file located in the ROBERTS directory on DISKl. The ACL denies Pat delete and control access because it omits them from the access statement. $ SET SECURITY/ACL=(IDENTIFIER=[PAT],ACCESS=READ+WRITE+EXECUTE) _$ DISKl:[ROBERTS]JULY-SALES.TXT A security administrator uses the Authorize utility to create a general identifier and grant it to all users who need to use it. Assume, for example, that a security administrator has created and assigned the identifier PAYROLL to employees who need access to a payroll file. For the holders of the identifier to actually access the file, the administrator has to add an Identifier ACE to the file. For example, the following command creates an ACL for the PAYROLL file that gives holders of the PAYROLL identifier read access to the file: $ SET SECURITY/ACL=(IDENTIFIER=PAYROLL,ACCESS=READ) PAYROLL.DAT The order of ACEs in an ACL is important because of the operating system's processing rules. See Section 4.4.6 for information on ordering ACEs. 4.4.3 Preventing Users from Accessing an Object Besides providing access to objects, an Identifier ACE is often used to deny certain users access to an object. Some sites might use an ACL to restrict users who log in from a modem or over the network. Other sites might place a restricting ACE on expensive equipment or volumes containing sensitive files. To deny all access to holders of a particular identifier, use the NONE keyword as the access type name. For example, the following command denies holders of the environmental identifier DIALUP any access to the files in the PROJECT ACCOUNTS directory: $ SET SECURITY/ACL=(IDENTIFIER=DIALUP,ACCESS=NONE) _$ /CLASS=FILE PROJECT-ACCOUNTS.DIR Denying access with the NONE keyword requires some additional planning. You must position the ACE correctly in the ACL, as Section 4.4.6 describes, because the operating system grants or denies access based on the first matching ACE. (Alternatively, you can eliminate any access allowed through the group or world category of the protection code [see Section 4.3 and Section 4.5.5, in particular].) Security administrators may also want to rescind privileges that can override the matching ACE. 4.4.4 Limiting Access to a Device Although a security administrator may want to provide access to a common file, such as the payroll file described in Section 4.4.2, the administrator would want to ensure that only a limited number of people could use the letter-quality printer designated for printing checks. Otherwise, any holder of the payroll identifier could access the check forms that are always loaded in the printer TTA8. Because the check printer in the current example is never used for logins and no queues are directed to it, the security administrator can add an ACL to the printer to ensure that only one user, McGrey, is allowed read and write access. At the same time, the administrator must block printer access for all other identifier holders. The following command sequence creates such an ACL: $SET SECURITY/ACL=((IDENTIFIER=MCGREY,ACCESS=READ+WRITE)- _$ (IDENTIFIER=*,ACCESS=NONE))/CLASS=DEVICE TTAB
4-17 Protecting Data 4.4 Methods of Controlling Access with ACLs
While McGrey acquires read and write access, all other users are denied access with the NONE keyword, explained in Section 4.4.3. Still, the ACL on the printer TTA8 might not work exactly as intended until the security administrator modifies the printer's protection code. See Section 4.5.5 for details. 4.4.5 Limiting Access to an Environment With an Identifier ACE, it is possible to provide conditional access by combining certain kinds of identifiers. A common situation is to use a UIC identifier with one of the environmental identifiers like batch or interactive. (For a complete list of environmental identifiers, see Section 4.1.2.1.) Thus, a user can access a protected object only when running in batch mode or interactively but never over a dialup line. For example, the next command grants user Fred both submit and manage access to a print queue, but only while he is running a batch job: $ SET SECURITY/ACL=(IDENTIFIER=[FRED]+BATCH,ACCESS=SUBMIT+MANAGE)- _$ /CLASS=QUEUE SYSTEM6$LPAO 4.4.6 Ordering ACEs Within a List An ACL can contain one entry or many entries. With multiple ACEs, the order of the entries is critical because the system determines access based on the first matching ACE. The operating system searches an ACL sequentially and grants a user the access specified in the first matching ACE, thus ignoring all subsequent entries. See Section 4.3 for a description of the evaluation process. When writing ACLs, keep the following principles in mind: • ACEs giving access to critical users belong at the top of the list. • ACEs giving specific access to smaller groups belong before ACEs giving access to larger groups. The following ACL on the directory file PROJECT-ACCOUNTS.DIR demonstrates how to order entries in an ACL. It places ACEs giving access to critical users (Jones and Fred) at the top of the list and places general ACEs after them. The ACE denying access goes at the end. $ SET SECURITY/ACL=( - $ (IDENTIFIER=[ACCOUNTING,JONES],ACCESS=READ+WRITE+EXECUTE), -$ (IDENTIFIER=[FRED]+BATCH,ACCESS=READ+WRITE+EXECUTE),- -$ (IDENTIFIER=PAYROLL,ACCESS=READ),- =$ (IDENTIFIER=DIALUP,ACCESS=NONE)) PROJECT-ACCOUNTS.DIR The ACL on the project accounts directory allows read, write, and execute access to Jones all the time and to Fred while he is running a batch job. It gives read access to users holding the PAYROLL identifier. All users who are logging in from a modem are denied access unless they gain access through an earlier ACE. For example, Jones, Fred, or holders of the PAYROLL identifier might be dialing in, but, because their ACE precedes the DIALUP ACE, they would be granted access. The next example shows an ACL for the data file STAFFING.DAT. It demonstrates how you place the entry providing the greatest amount of file access at the top of an ACL. $ SET SECURITY/ACL=( - $ (IDENTIFIER=SECURITY,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL), -$ (IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE+EXECUTE+DELETE),- -$ (IDENTIFIER=SECRETARIES,ACCESS=READ+WRITE),- -$ (IDENTIFIER=[PUB,*],ACCESS=READ),- -$ (IDENTIFIER=NETWORK,ACCESS=NONE),- =$ (IDENTIFIER=[SALES,JONES],ACCESS=NONE)) STAFFING.DAT
4-18 Protecting Data 4.4 Methods of Controlling Access with ACLs
In this ACL, any users holding the SECURITY identifier obtain maximum access rights through the first ACE, and users holding the PERSONNEL identifier have the next greatest access. User Jones is prohibited from any access to the file unless Jones also happens to hold one of the general identifiers. (This might be an oversight on the part of the creator of the ACL.) If you want to be ab.solutely certain that user Jones cannot gain access to the file, move the entry at the bottom of the ACL to the top. 4.4.7 Establishing an Inheritance Scheme for Files You can create a plan for controlling access to files within a directory or a directory structure, develop an appropriate ACL for the files, and then direct the operating system to automatically assign this ACL to new files. To do this, create an Identifier ACE with the Default attribute, and then add the ACE to the directory file cataloging the files you want to affect. Use the OPTIONS keyword to include the Default attribute. For example, if you want all new files in the directory [MALCOLM] to have an ACL entry that permits read and write access to users with the PERSONNEL identifier, you can add the following ACE to the file MALCOLM.DIR: $ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,- _$ ACCESS=READ+WRITE) MALCOLM.DIR As a result of this ACE, any file created in the [MALCOLM] directory has the following ACL: $ SHOW SECURITY APRIL_INTERVIEWS.TXT WORK_DISK$:[MALCOLM]APRIL_INTERVIEWS.TXT;l object of class FILE Owner: [SALES,MALCOLM] Protection: ••• Access Control List: (IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)
Notice that the Default attribute does not appear within a new file's ACL but only in the ACL of directory files. However, any subdirectory created in the MALCOLM directory automatically has the entry (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE) as part of its ACL. In this way, the ACE is propagated throughout the entire directory tree. The ACE is not applied retroactively to existing versions of files in MALCOLM.DIR. To attach an ACE to existing files, you can use the /DEFAULT qualifier, ·described in Section 4.5. 7, or use the following command: $ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)- _$ [MALCOLM]*.*;* Any ACE with a Default attribute controls only the propagation of the ACE; it has no effect on access control. To control access to the directory as well as all its files, you have to insert two ACEs in the directory's ACL, as follows: $ SET SECURITY/ACL=- $ ((IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE),- =$ (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE)) MALCOLM.DIR
4-1Q Protecting Data 4.4 Methods of Controlling Access with ACLs
4.4.8 Displaying ACLs The DCL command SHOW SECURITY displays an object's ACL. When working with objects other than files, you must supply a class name as well as the object name. For example, the following display shows the security attributes of a device called PPAO. It is owned by the operating system, its protection code gives full access (read, write, physical, and logical) to users in the system and owner categories but no access to group and world users; its ACL gives control access to user Svensen. $ SHOW SECURITY /CLASS=DEVICE PPAO: _ACCOUNTS$PPAO: object of class DEVICE Owner: [SYSTEM] Protection: (System: RWPL, Owner: RWPL, Group, World) Access Control List: (IDENTIFIER=[ADMIN,SVENSEN],ACCESS=CONTROL) There are many other ways of displaying ACLs. The access control list editor (ACL editor) is a useful tool for extensive work with ACLs; see the ACL editor documentation in the Open VMS System Management Utilities Reference Manual. But any of the following DCL commands display ACLs: SHOW SECURITY DIRECTORY/ACL DIRECTORY/SECURITY DIRECTORY/FULL SHOW LOGICAL/FULUSTRUCTURE SHOW DEVICE/FULL SHOW QUEUE/FULL Applications sometimes add a Hidden attribute to an ACE to indicate that the ACE should be changed only by the application that adds the ACE. Unless users have the SECURITY privilege, they cannot display a hidden ACE by using DCL commands. The ACL editor does display ACEs holding the Hidden attribute but only to show its relative position within the ACL; however, unauthorized users cannot edit the ACE. Sometimes you see other kinds of ACEs, unrelated to access control, in an ACL. For example, if the security administrator places a security-auditing ACE on the LN03$PRINT queue, you will see an ACE at the top of the list that has the format (AUDIT=SECURITY,ACCESS=access-types). Such an ACE is part of the security-auditing system and has no effect on access, so you can ignore it. 4.4.9 Adding ACEs to an Existing ACL Section 4.4.2 through Section 4.4.5 discussed how to add entries to an empty ACL with the DCL command SET SECURITY. To modify ACLs extensively, use the ACL editor; however, in many cases the SET SECURITY command is ,, more appropriate. This section and those that follow describe how to use SET SECURITY to change an ACL. To add more entries to an ACL, you can use the I ACL qualifier with the SET SECURITY command and specify the new ACEs. For example, to give the writers access to the print queue LN03$PRINT, use the following command: $ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=WRITERS,- _$ ACCESS=READ+WRITE) LN03$PRINT Protecting Data 4.4 Methods of Controlling Access with ACLs
By default, the system places the new ACE at the top of the ACL, as you see in the following SHOW SECURITY display: $ SHOW SECURITY /CLASS=QUEUE LN03$PRINT _LN03$PRINT: object of class QUEUE Owner: [SYSTEM] Protection: (System: RWPL, owner: RWPL, Group, World) Access Control List: (IDENTIFIER=WRITERS,ACCESS=READ+WRITE) (IDENTIFIER=[PUB,*],ACCESS=READ) (IDENTIFIER=NETWORK,ACCESS=NONE) Because the default behavior for SET SECURITY is to place a new ACE at the top of an ACL, you need to use the /AFTER qualifier if you want to put the ACE in another position. For example, to position the TRADERS ACE in the queue's ACL after the WRITERS ACE: $ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=TRADERS,ACCESS=WRITE) _$ /AFTER=(IDENTIFIER=WRITERS,ACCESS=READ+WRITE) LN03$PRINT The resulting display confirms the effectiveness of the /AFTER qualifier. The new ACE is put second in the list. $ SHOW SECURITY /CLASS=QUEUE LN03$PRINT _LN03$PRINT: object of class QUEUE Owner: [SYSTEM] Protection: (System: RWPL, Owner: RWPL, Group, World) Access Control List: (IDENTIFIER=WRITERS,ACCESS=READ+WRITE) (IDENTIFIER=TRADERS,ACCESS=WRITE) (IDENTIFIER=[PUB,*],ACCESS=READ) (IDENTIFIER=NETWORK,ACCESS=NONE) 4.4.1 O Deleting an ACL The /DELETE qualifier on the SET SECURITY command erases an ACL. Depending on how the qualifier is used, you can delete all or part of an ACL. For example, the following command deletes a disk's ACL: $ SET SECURITY/CLASS=DEVICE/ACL/DELETE DUAO An ACE can be protected against inadvertent deletion if it holds the Protected attribute. To eliminate a protected ACE, you need to delete it explicitly or use the /DELETE=ALL qualifier on the SET SECURITY/ACL command. 4.4.11 Deleting ACEs from an ACL You can eliminate a subset of an ACL by listing the unwanted ACEs with the /ACL qualifier and including the /DELETE qualifier. For example, the following command deletes the ACEs giving holders of the TRADERS identifier and the NETWORK identifier write access to volume DBAO: $ SET SECURITY/CLASS=VOLUME/ACL=- $ (IDENTIFIER=TRADERS,ACCESS=WRITE),- =$ (IDENTIFIER=NETWORK,ACCESS=WRITE)/DELETE DBAO:
4-21 Protecting Data 4.4 Methods of Controlling Access with ACLs
4.4.12 Replacing Part of an ACL To replace one contiguous set of ACEs within an ACL with another set, specify the new ACEs with the /REPLACE qualifier and the ACEs to be deleted with the /ACL qualifier, as follows: $ SET SECURITY/CLASS=VOLUME/ACL=(IDENTIFIER=TRADERS,ACCESS=WRITE)- $ /REPLACE=((IDENTIFIER=RESEARCH,ACCESS=WRITE)- -$ (IDENTIFIER=STATE DEPARTMENT,ACCESS=READ+WRITE),- -$ (IDENTIFIER=ENERGY DEPARTMENT,ACCESS=READ+WRITE)- =$ DBAO: - The TRADERS ACE specified by /ACL is deleted. Following the deletion, the ACEs specified by the /REPLACE qualifier (RESEARCH, STATE_DEPARTMENT, ENERGY_DEPARTMENT) are inserted at the location of the old ACE. 4.4.13 Restoring a File's Default ACL If you want to restore the default ACL to a file, you can use the /DEFAULT qualifier to the SET SECURITY command. This qualifier regenerates the full security profile for a file. See Section 4.5. 7 for a description. 4.4.14 Copying an ACL You can copy the security profile of one object to another by using the /LIKE qualifier to the SET SECURITY command. For example, you can save a complicated ACL on a nonpermanent object like a logical name table by copying it to a permanent object such as a file. Some administrators create a file to serve as a template in copy operations. This way, they can easily transfer an ACL from one object to another. For example, the following command copies the ACL from file ACL_TEMPLATE.TXT to the logical name table LNM$GROUP: $ SET SECURITY/LIKE=NAME=ACL TEMPLATE.TXT- _$ /COPY_ATTRIBUTE=ACL/CLASS~LOGICAL_NAME_TABLE LNM$GROUP If you add the /COPY_ATTRIBUTE qualifier to /LIKE qualifier, then you can copy one or two elements rather than the complete profile. Notice the ACL on the following directory, KITE_FLYING: $ SHOW SECURITY [OOOOOO]KITE_FLYING.DIR;l - WORK_DISK$:[000000]KITE_FLYING.DIR;l object of class FILE Owner: [PROJECTX] Protection: (System: RWED, Owner: RWED, Group:, World) Access Control List: IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE The following command copies the ACL from directory KITE_FLYING to the directory KITE_DESIGNS: $ SET SECURITY/LIKE=KITE FLYING.DIR;l - _$ /COPY_ATTRIBUTE=ACL KlTE_DESIGNS.DIR;l $ SHOW SECURITY [OOOOOO]KITE_DESIGNS.DIR;l - WORK_DISK$:[000000]KITE_DESIGNS.DIR;l object of class FILE Owner: [ENGINEERING] Protection: (System: RWED, Owner: RWED, Group:R, World:R) Access Control List: IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE
4-22 Protecting Data 4.4 Methods of Controlling Access with ACLs
The SET SECURITY/LIKE command does not always duplicate the entire ACL of the source object. For example, the command does not copy any ACEs from the source ACL that have the Nopropagate attribute. The command also does not overwrite protected ACEs. It preserves protected ACEs on the target object and adds them to the ACL being copied. (For example, applications often use a special type of protected ACE to explain how to display file data correctly, and these ACEs have to be preserved.) Refer to the ACL editor documentation in the Open VMS System Management Utilities Reference Manual for details on the different attributes an ACE can have, and refer to the Open VMS Programming Concepts Manual for a description of all ACE types.
4.5 Controlling Access with Protection Codes A protection code controls the type of access allowed (or denied) to a particular user or group of users. Access types identify the capabilities required to perform an operation on a protected object. OpenVMS security policy can have multiple access· requirements to complete an operation (see Section 4. 7 .2). A user can gain access to an object as soon as the operating system finds a category within the protection code for which the user qualifies that allows the access requested (provided an ACL does not deny access). · 4.5.1 Format of a Protection Code A protection code has the following format: [user category: list of access allowed (, user category: list of access allowed, ... )] user category User categories include system (S), owner (0), group (G), and world (W). Each category can be abbreviated to its first character. Categories have the following definitions: • System: Members of this category can include any of the following: Users with low group numbers, usually from 1 to 10 (octal). These group numbers are generally for system managers, security administrators, and system programmers. (The exact range of system group numbers is determined by the security administrator in the setting of the system parameter MAXSYSGROUP. It can range as high as 37776 (octal).) Users with the SYSPRV privilege. Users with the GRPPRV privilege whose UIC group matches the UIC group of the object's owner. In access requests to files on a disk volume, users whose UIC matches the UIC of the volume'ff owner. • Owner: The user with the same UIC as the user who currently owns the object. In general, the creator of an object is entitled to owner access unless explicit action is taken to secure the object from its creator. • Group: All users who are in the same UIC group as the object's owner. • World: All users, including those in the first three categories. When specifying more than one user category, separate the categories with commas, and enclose the entire code in parentheses. You can specify user categories and access types in any order.
4-23 Protecting Data 4.5 Controlling Access with Protection Codes
A null access specification means no access, so when you omit an access type for a user category, that category of user is denied that type of access. To deny all access to a user category, specify the user category without any access types. Omit the colon after the user category when you are denying access to a category of users. When you omit a user category from a protection code, the current access allowed that category of user remains unchanged. access-list Access types are object-dependent and are described in Section 4.8. For files, the access types include read (R), write (W), execute (E), and delete (D). The access type is assigned to each user category and is separated from its user category by a colon (:), for example, SET SECURITY/PROTECTION=(S:RWE,O:RWE,G:RE,W). 4.5.2 Types of Access in a Protection Code Each category of user can be allowed or denied different types of access. The exact type is dependent on the object being protected. Each object class defines access types appropriate for its class and representative of the ways in which users operate on the data. For example, while the file object supports read, write, execute, and delete access, devices (such as terminals, printers, and disks) support read, write, physical I/O, and logical I/O access. See Section 4.8 for a listing of the access types each object class supports. All protected objects also support control access, which allows a user to examine and modify the security elements (ACL, protection code, UIC) and possibly other attributes of the object. Control access is explicitly stated in an ACL but never appears in the UIC-based protection code. All users who qualify for the system or owner categories of a protection code have control access. Users in the group and world categories never receive control access through a protection code, but they could receive access through an ACL. See Section 4.6.2 for more information. The capabilities conveyed by the access types read, write, execute, delete, and control vary depending on the situation where they apply. For example, execute access permits different operations depending on whether it is granted for file access or directory access. Section 4.8 explains the capabilities that each access type allows. 4.5.3 Processing a Protection Code When the system evaluates a protection code, it looks first at the owner field, then at the world field, the group field, and finally the system field. As soon as a user qualifies as a member of the category and that category grants the necessary access, the operating system stops processing the code (see Figure 4--1). The following protection code specifies that users in the system and owner categories have read (R), write (W), execute (E), and delete (D) access, while users in the group and world categories have only read and execute access: $ SET SECURITY/PROTECTION=(SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE) _$ TAXES_91.DAT When you want to deny access to a user category, you must deny access to all the outermost categories. As Section 4.5.1 shows, any user process or application qualifies for world access. The group category is more restrictive yet not as restrictive as the owner and system categories.
4-24 Protecting Data 4.5 Controlling Access with Protection Codes
The following protection code, for example, appears to deny delete access to the owner category: $ SHOW SECURITY TAXES_91.DAT WORK_DISK$:[GREG]TAXES_91.DAT;l object of class FILE Owner: [FINANCE,GREG] Protection: (System: RWED, Owner: RW, Group:RW, World:RWED) Access Control List: ••• However, the owner of the file can still delete the file. Although delete access is not allowed through the owner category, the system continues to check the remaining categories for permission to grant access. Because the owner also fits in the world category (which applies to all users) and the world category is permitted delete access, the system grants delete access to the owner. 4.5.4 Changing a Protection Code You can change the UIC-based protection on an existing object with the SET SECURITY command. The following command modifies the protection code of the file SURVEY.DIR so that anyone in the system and owner categories has read, write, execute, and delete access, whereas members of the group and world categories have read and execute access: $ SET SECURITY/PROTECTION=(SYSTEM:RWED,OWNER:RWED, - _$ GROUP:RE,WORLD:RE) SURVEY.DIR Whenever you omit a category from a protection code, the current access remains unchanged. For example, consider the protection code for the file RECORDS_ 91.DAT: $ SHOW SECURITY RECORDS_91.DAT WORK DISK$:[GREG]RECORDS 91.DAT object of class FILE -Owner: [VMS,GREG] - Protection: (System: RWED, Owner: RWED, Group: RWED, World: RE) As it stands, the file RECORDS_91 allows read, write, execute, and delete access to users in the system, owner, and group categories; it allows read and execute access to users in the world category. The following DCL command resets the protection code for RECORDS_91.DAT to deny write and delete access to the group category and to deny all access to the world category: $ SET SECURITY/PROTECTION=(G:RE,W) RECORDS_91.DAT The next command confirms the modified protection code. It shows that the system and owner categories of users continue to hold read, write, execute, and delete access, while the group category of users have only read and execute access and the world category of users have no access. $ SHOW SECURITY RECORDS_91.DAT WORK DISK$:[GREG]RECORDS 91.DAT object of class FILE -Owner: [VMS,GREG] - Protection: (System: RWED, Owner: RWED, Group: RE, World:) 4.5.5 Enhancing Protection for Sensitive Objects Section 4.4.4 described how to place an ACL on an important printer so that only one user would have access to it. Before the ACL can be effective, however, the security administrator has to eliminate all access provided through the printer's
4-25 Protecting Data 4.5 Controlling Access with Protection Codes
protection code by using the following command: $ SET SECURITY/PROTECTION=(S,O,G,W)/CLASS=DEVICE TTA8: The security administrator then uses an ACL to assign access explicitly. For example, to limit access to a queue, you can remove submit access for the world category. Then you can set up an ACL that specifies which users (from the world category) are permitted to submit jobs to the queue. The following command stipulates that only holders of the identifier PROJECTX can submit jobs to the LN03$PRINT queue: $ SET SECURITY/CLASS=QUEUE/PROTECTION=(W) - $ /ACL=(IDENTIFIER=PROJECTX,ACCESS=SUBMIT) - ~) LN03$PRINT Important files frequently need special protection. You can prevent users from seeing the contents of a directory by denying them read access. To further protect the files, you can add a Default Protection ACE to the directory file, as Section 4.5.6 describes. 4.5.6 Providing a Default Protection Code for a Directory Structure To specify default protection for new files in a particular directory, place a Default Protection ACE in the ACL of the directory file. The Default Protection ACE affects files that are subsequently created in the directory and in any subdirectories under that directory unless protection is specified for one of those files individually. This ACE type has the following format: (DEFAULT_PROTECTION[,options],protection-code) For example, the following ACE specifies that users in the system and owner categories have read, write, execute, and delete access to any files subsequently created in the directory and that group and world users have no access: $ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) ARCHIVE.DIR Be aware that the default protection is associated only with newly created files not existing files in the current directory and its subdirectories. If you add a Default Protection ACE to a directory file and want the same protection applied to existing files, you must explicitly change the protection with the following command: $ SET DEFAULT [ARCHIVE] $SET SECURITY/PROTECTION=(S:RWED,O:RWED,G,W) [ ••• ]*.*;* 4.5.7 Restoring a File's Default Security Profile The /DEFAULT qualifier of the SET SECURITY command regenerates the security profile of a file. The /DEFAULT qualifier changes the protection code, the ACL, and the owner elements of a file to what it would be if the file had just been created. The profile is recreated according to the following rules: • The protection code is propagated from the Default Protection ACE on the directory (if one exists), or else it is propagated from the process default. • The ACL is propagated from the parent directory for those ACEs that have the Default attribute. • The owner is set to the owner of the parent directory. (Be aware that modifying a file's owner generally requires privilege; see Section 4.8.4.2.) \
4-26 Protecting Data 4.5 Controlling Access with Protection Codes
With subdirectory files, SET SECURITY assigns the owner, protection, and ACL elements of the parent directory. SET SECURITY does not copy any ACE on the source object if it holds the N opropagate attribute, nor does it change any ACE on the target object if it holds the Protected attribute. To apply new elements to all versions of the file, specify ;* in the object name. Refer to Section 4.8.4.5 for more information on propagation rules.
4.6 Understanding Privileges and Control Access Although an object can be carefully protected by an ACL and a protection code, a user can still gain access through the use of privilege or control access. 4.6.1 How Privileges Affect Protection Mechanisms Security administrators can assign privileges to users when they create or modify user accounts. The system privileges READALL and BYPASS affect user access, regardless of the access dictated by either an ACL for the object or its protection code. The privileges SYSPRV and GRPPRV are controlled through the system category of the protection code. The privileges have the following meanings: BYPASS A user with BYPASS privilege receives all types of access to the object, regardless of its protection. GRPPRV A user with GRPPRV privilege whose UIC group matches the group of the owner of the object receives the same access accorded to users in the system category. Thus, the user with GRPPRV privilege is able to manage any of the group's objects. READ ALL A user with READALL privilege receives read access to the object, even if that access is denied by the ACL and the protection code. In additfon, the user can receive any other access granted through the protection code. SYSPRV A user with SYSPRV privilege receives the access accorded to users in the system category. When you define ACLs or protection codes for your objects, remember that users with amplified privileges are entitled to special access to objects throughout the system. For example, there is no way to stop a user with the BYPASS privilege from accessing your files. Users with GRPPRV privilege have the power to perform many system management functions for other members of their QIC group. Protection of your objects depends on the judgment of your security administrator in granting these privileges. 4.6.2 Using Control Access to Modify an Object Profile Any user with control access to an object can change its protection code and ACL and thereby gain access to an object. For all object classes but files, control access also allows a user to modify the object's owner. To modify the owner of a file generally requires privilege (see Section 4.8.4.2). You obtain control access in any of the following ways: • You hold an identifier to which the object's ACL gives control access. • You have the same UIC as the owner of the object. • You qualify as a member of the system user category, and the object has an owner with a nonzero UIC. For example, you hold GRPPRV (with a matching group UIC) or SYSPRV. (Refer to Section 4.5 for a full description of system users.)
4-27 Protecting Data 4.6 Understanding Privileges and Control Access
• You hold BYPASS privilege. Sometimes object classes allow control access through other means. Refer to Section 4.6.3 and to the individual descriptions of classes in Section 4.8 for any special conditions that may apply. There are limitations to control access. A user with control access cannot adjust the security profile of an object with a UIC of zero; to modify such an object requires BYPASS privilege or the access rights of a system user. 4.6.3 Object-Specific Access Considerations For some objects, access can be granted by a special privilege (beyond those listed in Section 4.6.1) or by an all-inclusive type of access. This is particularly true of a queue. A user with operator (OPER) privilege is granted all types of access to a queue. A user with manage access implicitly possesses the three other types of queue access: read, submit, and delete. Section 4.8 lists each object class with its access types and meanings and any special privilege.
4.7 Auditing Protected Objects Whenever a process uses an object or modifies its security profile (see Section 4.2.4), the system can send an alarm to an operator terminal or write a message to the audit log file. By reading the log file, a security administrator can review system activity to see how protected objects are being used, when they are being used, and who is using them. Exactly which type of information is reported through the auditing system depends on how the security administrator defines the site's requirements. If system administrators choose to have object use audited, they can enable auditing for the appropriate categories of events. The operating system can filter security-related events and send system administrators messages only when objects are accessed in certain ways. Sites are often more interested in the privileged use of a file or the failure to access a file than in every file access. Such a site can request auditing messages whenever a process fails in accessing a file, but not when it is successful. The system can report how the process exercised, or failed to exercise, the right to access the object in the first place: through a protection code, an ACE, or a privilege. 4.7.1 Kinds of Events the System Audits Each object class has its own auditing profile, described in Section 4.8, and so it is possible to receive more information on some classes of objects than on others. For any object, the system can send an auditing message whenever a user or application accesses the object or modifies its security elements. In some instances, the system can send a notification when a process creates an object, stops using it (deaccesses it), or deletes it. 4.7.2 Enabling Auditing for a Class of Objects When you are auditing object access events, keep in mind that the operating system may check a user's right to an object several times during a single operation. A file operation, for example, can involve checks for both directory and file access. Before a user deletes a file, the system checks for delete access to the file and write access to the directory.
4-28 Protecting Data 4.7 Auditing Protected Objects
For this reason, it is best to enable auditing for all types of object access events. For example, to track all instances where a user tries to access a file but fails, a security administrator would use the /ENABLE=ACCESS=FAILURE=ALL qualifier to the SET AUDIT command. For object classes that support deaccess auditing (for example, the file class), once a process gains access to an object, the system does not audit subsequent accesses to the object unless the process attempts an operation that is incompatible with the access modes previously granted. When this occurs, the system performs an additional protection check that is audited. This access window continues until the object is deaccessed (for example, the file is closed). 4. 7.3 Adding Security-Auditing AC Es Rather than audit an entire class of objects, security administrators and users with control access to an object can single out a specific object for auditing by attaching an Alarm or Audit ACE to it (see Section 3.10.2). Although you can add an auditing ACE to any file that you own or have control access to, it is best to consult your system administrator before doing so. As with object classes, the system administrator has to enable the ACL auditing category before any auditing messages are generated. 4.8 Descriptions of Object Classes This section describes each class of protected object. Each class description contains information on the following topics:
Topic Description Naming rules A summary of naming conventions for objects in the class. Types of access Access types supported for the class. Boldface type indicates the abbreviation of an access type, such as R for read access. Template profile The default profile applied to new objects of the class. Site security administrators can modify the default profiles. Use the SHOW SECURITY command to display current template settings. Privilege requirements Privileges, if any, required for certain operations on the object. Kinds of auditing performed Events that trigger an audit event message (assuming the event class is enabled). Permanence of the object Explains if the security elements are stored from one system startup to another and if so, where the elements are stored.
If a given topic does not apply to a class, the topic is omitted. 4.8.1 Capabilities A capability is a resource to which a site controls access, using the standard access control mechanisms. In OpenVMS systems, the ability to execute vector instructions is a capability object. Only sites with a vector processor have such an object.
4-29 Protecting Data 4.8 Descriptions of Object Classes
4.8.1.1 Naming Rules The only valid name for a capability object is VECTOR. 4.8.1.2 Types of Access The capability class supports the following types of access: Use Gives a process the right to make use of the vector processor Control Gives you the right to change the protection and ownership elements of the object 4.8.1.3 Template Profile The capability class provides the following template profile:
Template Name Owner UIC Protection Code DEFAULT [SYSTEM] S:U,O:U,G:U,W:U
Modifications to the VECTOR template take effect the next time you boot the system. If you want to change the elements of the VECTOR object after the system is booted, you must modify the object directly. For example, $ SET SECURITY/CLASS=CAPABILITY/PROTECTION=(S:U,O:U,G:U,W) VECTOR 4.8.1.4 Kinds of Auditing Performed The operating system can audit the following type of event:
Event Audited When Audit Occurs Access The first time after image activation that the process uses a vector instruction.
4.8.1.5 Permanence of the Object The capability object's security profile needs to be reset each time the system starts up. 4.8.2 Common Event Flag Clusters A common event flag cluster is a set of 32 event flags that enable cooperating processes to post event notifications to each other. Event flags in the cluster can be set or cleared to indicate the occurrence of an event. All event flags are contained within clusters of 32 event flags, and each process has access to four clusters (numbered 0 through 3). Two of the clusters are local to a single process. Event flag clusters 2 and 3 are called common event flag clusters, and they are used for interprocess synchronization. A subject may be associated with up to two common event flag clusters. Each common event flag in a cluster is referenced by an event flag number. 4.8.2.1 Naming Rules The name of the object is whatever character string was supplied as an argument to the Associate Common Event Flag Cluster system service ($ASCEFC).
4-30 Protecting Data 4.8 Descriptions of Object Classes
4.8.2.2 Types of Access The common event flag cluster class supports the following types of access: Associate Gives a process the right to establish an association with the named cluster so the process can access event flags. Delete Gives a process the right to mark a permanent event flag cluster for deletion with the Delete Common Event Flag Cluster ($DLCEFC) system service. The actual deletion occurs once all processes disassociate from the cluster. Control Gives you the right to modify the protection elements of the common event flag cluster. 4.8.2.3 Template Profile The common event flag cluster class provides one template profile. Although the template assigns an owner UIC of [0,0], this value is only temporary. As soon as the object is created, the operating system replaces a 0 value with the value in the corresponding field of the creating process's UIC.
Template Name Owner UIC Protection Code DEFAULT [0,0] S:AD,O:AD,G:A,W
When the process creating the common event flag cluster supplies a prot argument to $ASCEFC that has a value of 1, then the system modifies the template so the process UIC is the owner, and the protection code denies group access. 4.8.2.4 Privilege Requirements Creation of a permanent common event flag cluster requires the PRMCEB privilege. This privilege also grants delete access for permanent clusters. 4.8.2.5 Kinds of Auditing Performed The system can audit the following types of events:
Event Audited When Audit Occurs Creation When the first process to associate with a particular cluster calls $ASCEFC Access Whenever subsequent callers to $ASCEFC associate with the cluster Deaccess When a process calls $DACEFC or associates with another cluster, or at image rundown Deletion When the process calls $DLCEFC
4.8.2.6 Permanence of the Object A common event flag cluster and its security profile need to be reset each time a system starts up. 4.8.3 Devices A device is a peripheral, physically connected or logically known to a processor and capable of receiving, storing, or transmitting data. A device can be physical, like a disk or terminal, or it can be virtual, like a mailbox or pseudoterminal. Virtual devices are implemented entirely in software.
4-31 Protecting Data 4.8 Descriptions of Object Classes
4.8.3.1 Naming Rules A physical device name has the following format: ddcu It consists of three parts: the device code (dd), a controller designator (c), and the unit number (u). The maximum length of the device name field, including the controller and the unit number, is 15 characters. See the Open VMS User's Manual for information on device names. 4.8.3.2 Types of Access Devices can be shared and thus have concurrent users or be unshared and have a single user. Shared devices support the following types of access: Read Gives you the right to read data from the device Write Gives you the right to write data to the device Physical Gives you the right to perform physical 1/0 operations to the device Logical Gives you the right to perform logical 1/0 operations to the device Control Gives you the right to change the protection elements and owner of the device Unshared devices support only read, write, and control access. The device driver rather than the operating system's security policy defines the access requirements for other types of operations. 4.8.3.3 Access Requirements for 1/0 Operations Access requirements for I/O operations on devices can be quite complex. The following list explains access requirements for typical operations: • Assigning a channel with $ASSIGN Assigning a channel to a nonspooled, nonshareable device requires read access, write access, control access, or any combination. Assigning a channel to a shareable device has no access requirement. • $QIO to spooled devices Access is handled as described for OpenVMS mounted volumes. See the next list item, $QIO to file-oriented devices. • $QIO to file-oriented devices: disks and tapes With file-oriented devices, logical I/O and physical I/O functions have common elements. Any logical I/O function requires physical or logical access plus read access to read a block (READLBLK) or write access to write a block (WRITELBLK). Any physical I/O function requires physical access plus either read access to read a block (READPBLK) or write access to write a block (WRITEPBLK). Beyond this, access requirements depend on how the volume is mounted: OpenVMS supported volumes Any virtual I/O to the volume has the same access requirements as the File or Volume class (see Section 4.8.4 and Section 4.8.10). Volumes mounted foreign (/FOREIGN) Virtual read and write functions are converted to logical I/O. All other functions are not processed by the operating system and are sent to the device driver for processing.
4-32 Protecting Data 4.8 Descriptions of Object Classes
Devices without a mounted volume Access to devices without mounted volumes requires privilege. • $QIO to devices that are not file-oriented With non-file-oriented devices, OpenVMS converts virtual read and write 1/0 requests to logical 1/0 before processing them. Other kinds of access requests are not processed by OpenVMS; instead, the request is passed to the device driver for processing. In general, access requirements for devices that are not file oriented depend on whether the device is shareable or nonshareable: Shareable devices With shareable devices, such as mailboxes, any virtual 1/0 function other than READVBLK/WRITEVBLK is handled by the system 1/0 driver program. Any logical 1/0 function requires privilege or logical access to the device. Any physical 1/0 function requires privilege or physical access to the device. U nshareable devices With unshareable devices, such as terminals or printers, the operating system checks only for read or write access to perform virtual and logical 1/0 functions. Any physical 1/0 function requires privilege. Table 4-3 show the access requirements for devices that are not file oriented.
Table 4-3 Access Requirements for Non-File-Oriented Devices
Functions Requiring Read Access READ HEAD READVBLK TTYREADALL READPBLK REREADN TTYREADPALL READLBLK REREADP READTRACKD READ PROMPT
Functions Requiring Write Access WRITE CHECK WRITELBLK WRITETRACKD WRITECHECKH WRITEPBLK WRITEVBLK WRITE HEAD WRITERET
4.8.3.4 Template Profile The device class provides the following template profiles:
Template Name Device Type Owner UIC Protection Code BUS DC$_BUS [SYSTEM] S:RWPL,O:RWPL,G,W CARD READER DC$_CARD [SYSTEM] S:RWPL,O:RWPL,G,W COMMUNICATION DC$_SCOM [SYSTEM] S:RWPL,O:RWPL,G,W DEFAULT [SYSTEM] S:RWPL,O:RWPL,G:RWPL,W:RWPL DISK DC$_DISK [SYSTEM] S:RWPL,O:RWPL,G:R,W MAILBOX DC$_MAILBOX [SYSTEM] S:RWPL,O:RWPL,G:RWPL,W:RWPL
4-33 Protecting Data 4.8 Descriptions of Object Classes
Template Name Device Type Owner UIC Protection Code
PRINTER DC$_LP [SYSTEM] S:RWPL,O:RWPL,G,W REALTIME DC$_REALTIME [SYSTEM] S:RWPL,O:RWPL,G:RWPL,W:RWPL TAPE DC$_TAPE [SYSTEM] S:RWPL,O:RWPL,G:R,W TERMINAL DC$_TERM [SYSTEM] S:RWPL,O:RWPL,G,W WORKSTATION DC$_ [SYSTEM] S:RWPL,O:RWPL,G:RWPL,W:RWPL WORKSTATION
4.8.3.5 Setting Up Profiles for New Devices A device usually derives its security profile from the template profile associated with its device type; however, the template is often modified. The following list describes how the operating system assigns a profile to different types of devices: • Devices created during system configuration Devices introduced during system configuration with the system commands CONNECT and LOAD (for example, pseudodevices and workstations) take their profiles from the template appropriate for the device type. • Disks and tapes Disk or tape devices take their profile from the DISK or TAPE template profile, respectively. Once the device is visible within a cluster, its profile, with any modifications, is retained across system restarts. Changes to the DISK or TAPE template profile after a device has its security profile do not apply to that device; therefore, it is necessary to reset the specific object profile by using the DCL command SET SECURITY (see Section 4.2.4). • Devices cloned from template devices Devices cloned from template devices (for example, Ethernet devices) assume the security profile of the template device from which they are cloned. Template devices are loaded during the autoconfiguration process; at this time, their profile is taken from the profile template appropriate for the device. • Mailboxes Mailbox devices assume a modified version of the MAILBOX template profile. The system modifies the template so the UIC of the creating process becomes the owner and the protection code is set to the value of the promsk argument to the Create Mailbox ($CREMBX) system service (provided the value is nonzero). To maintain compatibility with earlier versions of the operating system, the MAILBOX template has a protection code of zero (allowing all access). Some applications may need a more restrictive default than the template provides. If you do choose to restrict mailbox access, be aware that the more restrictive access can cause applications to fail in ways that are difficult to diagnose. • Terminals Terminal devices assume a modified version of the TERMINAL template profile. When LOGINOUT.EXE runs, the operating system modifies the profile so the owner becomes the UIC of the process logging in to the terminal. The original security profile for the terminal is restored when the user logs out.
4-34 Protecting Data 4.8 Descriptions of Object Classes
4.8.3.6 Privilege Requirements All logical or physical I/O to a spooled device requires privilege. The LOG_IO privilege allows the user's process to execute the Queue I/O Request ($QIO) system service to perform logical-level I/O operations. LOG_IO privilege is also required for certain device-control functions, such as setting permanent terminal elements. The PHY_IO privilege allows the user's process to execute the Queue I/O Request ($QIO) system service to perform physical-level I/O operations. The PHY_IO privilege also grants LOG_IO privilege. To create a permanent mailbox or mark it for deletion requires PRMMBX privilege. 4.8.3.7 Kinds of Auditing Performed The following types of events can be audited, provided the security administrator enables auditing for the appropriate event class:
Event Audited When Audit Occurs Access For nonshareable devices, when the process calls $ASSIGN. For a shareable device, when the process calls $QIO. Creation When a process creates a virtual device like a mailbox. Deletion When a process deletes a virtual device like a mailbox.
4.8.3.8 Permanence of the Object The profile of clusterwide disks and tapes is stored in the object database VMS$0BJECTS.DAT, but other object profiles have to be reset each time the systems starts up. 4.8.4 Files A file is a named array of fixed-size (512-byte) data blocks with an associated set of attributes. In OpenVMS systems, the file class include both data files and directory files. The operating system provides full security protection for individual disk files stored on Files-11 On-Disk Structure Level 2 (ODS-2) volumes. Tape files are collectively protected by the protection code on the volume but are not protected on an individual basis. The file object differs from other- protected objects in one important way: because files provide more flexibility than any of the other object classes, files do not acquire their profiles from a template. Section 4.8.4.5 describes the rules the operating system applies in assigning a profile. 4.8.4.1 Naming Rules A file specification is a string of 1 to 255 characters. See the Open VMS User's Manual for a full description.
4-35 Protecting Data 4.8 Descriptions of Object Classes
4.8.4.2 Types of Access The file class supports the following types of access: Read Gives you the right to read, print, or copy a disk file. With directory files, read access gives you the right to read or list a file and use a file name with wildcard characters to look up files. Read access implies execute access. Write Gives you the right to write to or change the contents of a file but not delete it. Write access allows modification of the file elements that describe the contents of the file. With directory files, write access gives you the right to make or delete an entry in the catalog of files. Execute Gives you the right to execute a file that contains an executable program image or DCL command procedure. With a directory file, execute access gives you the right to look up files whose names you know. Delete Gives you the right to delete a file. To delete a file, you must have delete access to the file and write access to the directory that contains the file. Control Gives you the right to change the protection code and ACL. You need to satisfy one of the following conditions to change the owner: • Hold both the old and the new owner identifier • Hold the Resource attribute to the identifier that owns the object while also being allowed control access to the object through an ACL on the object • Qualify as a system user, hold SYSPRV or BYPASS privilege, or hold a UIC that matches that of the owner of the volume containing the file or directory • Hold the GRPPRV privilege while also holding a UIC in the same group as the object owner
4.8.4.3 Access Requirements The following conditions apply to file access: • General rules To access a file, you must have permission to access the file and the volume on which it resides. When attempting to access a file by name, read or execute access to the directory containing the file is also required. An access check of the volume is required before either a directory or a file access is considered. The protection of a directory file can restrict access to files in the directory, so even though a group of users has access to a file, they can be prevented from accessing it by name if they lack proper access to the directory in which the file is located.
Note It is possible to access a file by its file identifier. When users do so, they bypass the directory file protection. Therefore, you must not rely entirely on directory file protection to control access to a file.
• For write access To write to a file, the operating system requires that you have both read and write access. • For files owned by identifiers
4-36 Protecting Data 4.8 Descriptions of Object Classes
When a file is owned by a general identifier, you can change the file owner if you have control access to the file and you hold two identifiers with the resource attribute. You need to hold both the identifier currently owning the file and the identifier intended to own the file. 4.8.4.4 Creation Requirements Before you can create a file, the operating system checks to see that you have satisfied the following conditions: • You must have adequate disk space. This includes both available disk blocks and sufficient disk quota (assuming quotas are enabled). • You have write access to the previous file version. You must also have delete access to the oldest file version if the file has a nonzero version limit and the new version would exceed this number. • You have write access to the directory where the file is being created. • You have read, write, and create access to the volume on which the file is to be stored. 4.8.4.5 Profile Assignment A new file obtains its owner, protection code, and ACL from a number of sources. The sources are as follows: 1. The explicit assignment of elements at creation You can create a file with the CREATE command or the COPY command. You use the CREATE/DIRECTORY command in the case of a directory. As creator of the file, you become its owner. To change this default, use the /OWNER_UIC qualifier to the CREATE or COPY commands. To assign a protection code when creating a file, add the /PROTECTION qualifier to the COPY or CREATE command. After creating the file, you can use the SECURITY/ACL command to add an ACL. For example, the following command copies a file from the device USE 1 to your default disk directory. The protection code defines the protection for the newly created file PAYSORT.DAT so that users with system UICs can read and write to the file. As owner, you have all types of access, and other users in your group can read and write to the file. All other users have no access through the protection code. $COPY USEl:[PAYDATA]PAYROLL.DAT PAYSORT.DAT - _$ /PROTECTION=(SYSTEM:RW,OWNER:RWED,GROUP:RW,WORLD) 2. The profile of the previous version of the file, if one exists Whenever you create a new version of a file, the new version is created with you as its owner and the protection code and ACL of the earlier version (unless, of course, you make an explicit assignment). With sufficient privilege, you can reassign ownership to the owner of the previous version. 3. A Default Protection ACE on the parent directory Without either an explicit assignment or a previous version of a file, the operating system looks at the directory where the file is being created. With data files, the system looks for a Default Protection ACE and assigns the protection code specified by that ACE. (See Section 4.5.6 for an example.) The owner defaults to your UIC, unless you have privilege (SYSPRV, BYPASS, or GRPPRV with the same group UIC). If any ACE in the directory's ACL Protecting Data 4.8 Descriptions of Object Classes
has the Default attribute, then the file inherits that ACE as well. (Refer to Section 4.4. 7 for an example.) With directory files, the system assigns the protection code of the parent directory, less any delete access. If the directory happens to be a top-level directory, the protection is taken from the master file directory (MFD). Newly created subdirectories inherit the ACL of the parent directory, even ACEs with the Default attribute. Only ACEs with the Nopropagate attribute are omitted. The owner defaults to your UIC, unless you have privilege. On rare occasions, a directory name can be in numeric UIC format ([11,304]) rather than the customary alphanumeric format ([SALES,LOCAL]). In such cases, the ownership defaults to the UIC in the directory name. 4. The UIC and protection defaults of the process issuing the command If the directory ACL does not have a Default Protection ACE, the default process protection is used. The system parameter RMS_FILEPROT establishes this value, and the operating system assigns it to your process during login. However, the value derived at login may be changed with the DCL command SET PROTECTION/DEFAULT. (For example, you can put this command in your login command procedure to set default protection.) Use the DCL command SHOW PROTECTION to display the default process protection. 5. One of the above with provision for the user creating the file When you create a file in a directory owned by a resource identifier and you hold the identifier with the Resource attribute, the new file is owned by the identifier and inherits its protection code and ACL in the same way as any other file. The operating system modifies the file's ACL in some cases to provide you with access to the file you have created. If the directory ACL has a Creator ACE, that ACE defines the access you have to your file (if any). Without such an ACE, the operating system adds an ACE to the file's ACL that gives you control access plus the access specified in the owner field of the file's protection code. 4.8.4.6 Kinds of Auditing Performed The following types of events can be audited, provided the security administrator enables auditing for the appropriate event class:
Event Audited When Audit Occurs Access When a process opens, reads, writes, or executes a file or inquires about its attributes Creation When a process creates a file Deaccess When a process closes a file Deletion When a process deletes a file
4.8.4.7 Protecting Information When Disk Space Is Reassigned Ordinary file protection mechanisms control who can access a file, but they do not address the problem of protecting old data that remains on disk after a file is deleted.
4-38 Protecting Data 4.8 Descriptions of Object Classes
When a file is deleted, its header is removed from the directory, but its contents remain intact on disk until it is overwritten. Because data exists on a disk, it is necessary to protect deleted or purged file information from disk scavenging. The OpenVMS operating system solves the problem of disk scavenging with the combination of the two following techniques: • Overwriting disk blocks before they are allocated • Setting a highwater mark on allocated blocks 4.8.4.7.1 Overwriting Disk Blocks A security administrator or user can apply an erasure pattern to individual files on a volume or to a complete volume. An erasure pattern is a repeated sequence of bits written over a file when the file is deleted or purged. The security administrator can ensure that every block on a volume starts off with the erasure pattern by specifying the /ERASE qualifier when the volume is initialized, as follows: INITIALIZE/ERASE device-name[:] volume-label If the volume is mounted, the security administrator can automatically apply the erasure pattern to the space occupied by a file when it is deleted by specifying the /ERASE_ON_DELETE qualifier, as follows: SET VOLUME/ERASE_ON_DELETE device-spec[:] Note that this technique has no effect on existing files. Alternatively, the security administrator may ask users to specify the erasure pattern on a file-by-file basis by using the /ERASE qualifier when entering the DCL commands SET FILE, DELETE, and PURGE. Security administrators can also write an erase routine by using the $ERAPAT system service. The routine writes an erasure pattern into areas of memory or onto disks. 4.8.4.7.2 Setting a Highwater Mark When the operating system allocates disk blocks for a file, it automatically sets a highwater mark. The highwater mark indicates how far the file has been written in its allotted space on the disk. All blocks in the file up to the highwater mark are guaranteed to have been written since they were allocated to the file. Users are not permitted to read beyond the highwater mark and thus cannot read stale data that they did not actually write. A more conservative but costly technique is to erase all disk blocks before allocation. The erase-on-allocate technique is used when the file is open, allowing any form of shared access or nonsequential access. When blocks are erased on allocation, the file's highwater mark is set to point to the end of the newly allocated and erased space. By default, highwater marking is enabled when the volume is initialized. The security administrator can disable highwater marking for a specific volume by using the DCL command SET VOLUME/NOHIGHWATER_MARKING.
4-39 Protecting Data 4.8 Descriptions of Object Classes
4.8.4.7.3 Accessibility of Data in a File Once the file system allocates disk blocks for a file, users can read or write to them at any time. The highwater mark identifies the physical end of file, beyond which the user cannot read. However, an application can reposition the logical end-of-file mark and leave data in the area between the logical and the physical end of the file. Any block of file data can later be read, regardless of the logical end-~f-file mark. An application largely determines how allocated disk blocks are managed. For example, OpenVMS RMS services shorten a sequential file by resetting the logical end-of-file position to the beginning of the current record. It does not deallocate space between the end-of-file position and the physical end of the file, nor does it overwrite the records between the end-of-file position and the physical end of the file with an erase pattern. Thus, blocks written to a file can remain available regardless of the end-of-file mark. If you want to erase the data between the logical end of the file and the physical end of the file, your application program must overwrite the data you want deleted. On OpenVMS systems, a common way to accomplish this is to create a new version of the file using the DCL command COPY. 4.8.4.8 Suggestions for Optimizing File Security Use the following precautions to protect your files and directories: • Purge your files regularly. Delete unnecessary files. This keeps your directories to a minimum and simplifies the task of regularly checking the protection and ownership on your files. • Use the DCL command DIRECTORY/SECURITY regularly to monitor the ownership, protection code, and ACLs on your files. A user who succeeds in obtaining sufficient privilege may change the protection or ownership on your files, allowing access immediately and in the future. If you perform these checks frequently, you can detect and report unexplained changes in file protection or ownership. • Pay special attention to the protection on your mail files; normally, they should be accessible only to you and the system (for mail delivery and backups). • When you place ACLs on your files, be sure you know exactly which users hold the identifiers you have specified. (This generally requires consultation with your site security administrator.) • Follow your site security administrator's recommendations to prevent disk scavenging. You may be requested to use the /ERASE qualifier on the SET FILE, DELETE, and PURGE commands for some or all of your files. • Always protect files and directories that contain command procedures and executable programs. Carefully control the granting of write access to these directories and files. This is particularly important if you have any of the more powerful privileges or access to sensitive files.
Caution Do not run a command procedure or program given to you by another user unless you inspect it. Inspect a program or procedure to see if it tries to exercise your special privileges or access sensitive files. Test the software in an unprivileged account. Programs or command procedures offered under one guise, when actually intended to penetrate your defenses
4-40 Protecting Data 4.8 Descriptions of Object Classes
and disrupt your system security, are sometimes called Trojan horse programs.
4.8.5 Global Sections OpenVMS memory management services allow processes to communicate through shared memory pages called global sections. Using global sections, two or more processes can map the same page into their individual virtual address spaces, thereby sharing the same page of code or data. A global section can provide access to a disk file (called a file-backed global section), provide access to dynamically created storage (called a page file-backed global section), or provide access to specific physical memory (called a page frame number [PFN] global section). A global section object may be either temporary or permanent. The operating system supports two types of global section objects: • Group global sections are shareable memory sections potentially available to all processes in the same group. • System global sections are shareable memory sections potentially available to all processes in the system. 4.8.5.1 Naming Rules The name of the object is a string of 1 to 44 characters. With file-backed sections, the version number is associated with name. 4.8.5.2 Types of Access The global section class supports the following types of access: Read Gives you the right to map the section for read access. Write Gives you the right to map the section for write access. Execute Gives you the right to map the section for read access. Only software running in executive or kernel mode can request this access. Control Gives you the right to modify the protection elements of PFN global sections and page file-backed global sections. 4.8.5.3 Template Profile File-backed global sections share the security profile of the associated disk file. Whenever the profile of the backing file is modified, the global section's profile automatically changes. To modify the protection elements of file-backed global sections, you must modify the backing file instead. The global section class provides the following template profiles. Although the template assigns an owner UIC of [0,0], this value is only temporary. As soon as the object is created, the operating system replaces a 0 value with the value in the corresponding field of the creating process's UIC.
Type Template Name Owner UIC Protection Code System DEFAULT [0,0] S:RWE,O:RWE,G:RWE,W:RWE Group DEFAULT [0,0] S:RWE,O:RWE,G:RWE,W:RWE
The operating system modifies the templates according to the values provided in the prot argument to $CRMPSC. The prot argument is ignored for file-backed sections.
4-41 Protecting Data 4.8 Descriptions of Object Classes
To maintain compatibility with earlier versions of the operating system, the DEFAULT templates have protection codes allowing world access. Some applications may need a more restrictive default than the templates provide. If you do choose to restrict global section access, be aware that the more restrictive access can cause applications to fail in ways that are difficult to diagnose. 4.8.5.4 Privilege Requirements The SYSGBL privilege is required to create or delete a system global section. The PFNMAP privilege is necessary to create or delete a page frame section, and the PRMGBL privilege is required to create or delete a permanent global section. 4.8.5.5 Kinds of Auditing Performed The following types of events can be audited, provided the security administrator enables auditing for the appropriate event class:
Event Audited When Audit Occurs Creation When a page file-backed or a PFN global section is created by the Create and Map Section system service ($CRMPSC). Access When an existing page file-backed or a PFN global section is accessed with either $CRMPSC or the Map Global Section system service ($MGBLSC). The operating system audits access to a file-backed global section as a file access. Deaccess At image or process rundown when the process virtual address space is reset or deleted. Deletion If a process with PRMGBL privilege, PFNMAP privilege, or SYSGBL privilege (in the case of a system global section) deletes a permanent global section, the operating system audits the event through the use of privilege.
4.8.5.6 Permanence of the Object A global section and its security profile need to be reset after every system boot. 4.8.6 Logical Name Tables Logical name assignments are maintained in logical name tables. A logical name table can be accessible to only one process, or it can be shareable if its parent table is shareable. All shareable name tables are listed in the LNM$SYSTEM_ DIRECTORY, the system directory table. It is shareable logical name tables that the operating system protects. 4.8.6.1 Naming Rules The name of a logical name table is a string of 1 to 32 characters. 4.8.6.2 Types of Access The logical name table class supports the following types of access: Read Gives you the right to look up (translate) logical names in the table Write Gives you the right to create and delete logical names in the table Create Gives you the right to create a descendant logical name table, including the right to use a subset of the dynamic memory allocated to the parent logical name table when creating the descendant logical name table Delete Gives you the right to delete the table
4-42 Protecting Data 4.8 Descriptions of Object Classes
Control Gives you the right to modify the protection elements and owner of the table 4.8.6.3 Template Profile The logical name table class provides the following template profiles. Although the template assigns an owner UIC of [0,0], this value is only temporary. As soon as the object is created, the operating system replaces a 0 value with the value in the corresponding field of the creating process's UIC.
Template Name Owner UIC Protection Code DEFAULT [0,0] S:RW,O:RW,G:R,W:R GROUP [0,*J S:RWCD,O:R,G:R,W JOB [0,0] S:RWCD,O:RWCD,G,W
4.8.6.4 Privilege Requirements The operating system allows read and write access to the group logical name tables with GRPNAM privilege and to the system logical name table with SYSNAM privilege. Deletion of a shared table from the system directory requires SYSNAM privilege, and deletion of a logical name from the group directory requires GRPNAM privilege. Deletion of a parent logical name table results in the deletion of all its descendant logical name tables. Creation or deletion of an inner-mode logical name or logical name table requires SYSNAM privilege (or being in an inner mode). 4.8.6.5 Kinds of Auditing Performed The following events can be audited, provided the security administrator enables auditing for the event class:
Event Audited When Audit Occurs Access When translating a name, when creating a name or a descendent table, or when deleting a name or a descendent table Creation During access to a parent table for the right to create a table, or when the table itself is created
4.8.6.6 Permanence of the Object A logical name table and its security profile must be reset each time the system is rebooted. 4.8. 7 Queues A queue is a set of jobs to be processed. In general, queues are of two types, generic or execution. No processing takes place in generic queues. Generic queues hold jobs that will execute on an execution queue when one is available. Generic queues can be batch queues, printer queues, server queues, or terminal queues.
4-43 Protecting Data 4.8 Descriptions of Object Classes
4.8.7.1 Naming Rules A queue name is a string of 1 to 31 characters, including any alphanumeric character, the dollar sign($), or the underscore(_).
4.8. 7 .2 Types of Access The queue class supports the following types of access: Read Gives you the right to see the security elements of a queue or a job in the queue. Submit Gives you the right to place jobs in the queue. Delete Gives you the right to delete a job in the queue or modify the elements of a job. Manage Gives you the right to affect any job in the queue. You can start, stop, or delete a queue and change its status and any elements that are unrelated to security. Control Gives you the right to modify the protection elements and owner of a queue. Note: When a process receives read or delete access through a protection code, it can operate on only its job in the queue. However, when granted through an ACL, read and delete access allow a process to operate on all jobs in the queue. 4.8.7.3 Template Profile The queue class provides the following template profile:
Template Name Owner UIC Protection Code DEFAULT [SYSTEM] S:M,O:D,G:R,W:S
4.8.7.4 Privilege Requirements You need SYSNAM and OPER privileges to stop or start the queue manager. OPER is necessary to create and delete queues.
4.8.7.5 Kinds of Auditing Performed The following events can be audited, provided the security administrator enables auditing for the event class:
Event Audited When Audit Occurs Access When a job is submitted to the queue and when either a job or queue is modified. Creation When a queue is initialized. Deletion When a process deletes a job from the queue or when the queue itself is deleted. (To enable auditing for queue deletions, enable auditing for manage [M] access to the queue. )
If access auditing is enabled for both files and queues, one queue operation can generate a number of auditing messages because, within a single operation, the operating system performs several access checks. For example, before a job is executed on a print queue, the system checks to see if you have read access to the file, and it checks for read access again before printing the file.
4-44 Protecting Data 4.8 Descriptions of Object Classes
4.8. 7 .6 Permanence of the Object The system creates queues during system startup and assigns them the security elements that it has stored in the system queue database. 4.8.8 Resource Domains Processes that access shared resources can coordinate access using services of the lock manager. These services allow processes to associate a name with a resource, such as a file or a data structure, to arbitrate access to that resource, and to exchange limited information through a lock value block. The namespaces that catalog resources on which locks can be taken are called resource domains. A process must become a member of a resource domain to take and release locks and to read and write value blocks associated with resources in that resource domain. A process implicitly joins the system and group domains, but it explicitly joins other domains through a call to the $SET_RESOURCE_DOMAIN system service. Access to all locks and value blocks within a domain is controlled by access to the domain itself. 4.8.8.1 Naming Rules A resource domain is identified by an octal value (from 3 to 07776) within square brackets. You can provide any identifier within brackets. If you supply a UIC, then the operating system uses the group portion as the resource domain name. 4.8.8.2 Types of Access The resource domain class supports the following types of access: Read Gives you the right to read lock value blocks in the domain, including the right to use the $GETLKI system service to retrieve it Write Gives you the right to write to lock value blocks in the domain Lock Gives you the right to take locks using $ENQ, release locks using $DEQ, and obtain information about the lock database using $GETLKI Control Gives you the right to modify the protection elements of a resource domain 4.8.8.3 Template Profile The resource domain class provides the following template profile. The template assigns an owner UIC of [n,*] where n is the resource domain's number.
Template Name Owner UIC Protection Code
DEFAULT [n, *] S:RWL,O:RWL,G:RWL,W
4.8.8.4 Privilege Requirements The SYSLCK privilege allows lock access to the system resource domain (Domain 0).
4.8.8.5 Kinds of Auditing Performed The following events can be audited, provided the security administrator enables auditing for the event class:
Event Audited When Audit Occurs Access When a process calls $SET_RESOURCE_DOMAIN or $ENQ to join a domain
4-45 Protecting Data 4.8 Descriptions of Object Classes
Event Audited When Audit Occurs
Creation The first time a process joins the resource domain De access When a process called $SET_RESOURCE_DOMAIN or at image or process rundown
4.8.8.6 Permanence of the Object Both the resource domain and its security elements are saved in SYS$SYSTEM:VMS$0BJECTS.DAT. 4.8.9 Security Classes The security class is the parent of all classes of protected objects. It protects the template profiles associated with the various object classes. Each object in the security class holds the following information: • An object name • A security profile for new objects of the class • One or more template profiles • A set of access names • Auditing controls Chapter 5 discusses how to manage objects in the security class. 4.8.9.1 Naming Rules The security class has the following members: CAPABILITY QUEUE COMMON_EVENT_CLUSTER RESOURCE_DOMAIN DEVICE SECURITY_CLASS FILE SYSTEM_GLOBAL_SECTION GROUP_GLOBAL_SECTION VOLUME LOGICAL_NAME_TABLE 4.8.9.2 Types of Access Security class objects support the following types of access: Read Gives you the right to read a template profile. Template profiles contain the security elements assigned to new objects. Write Gives you the right to modify the values of a template profile. Control Gives you the right to modify the security profile of a security class object. Control access implies read and write access. 4.8.9.3 Template Profile The security object class provides the following template profile:
Template Name Owner UIC Protection Code DEFAULT [SYSTEM] S:RW,O:RW,G:R,W:R
4-46 Protecting Data 4.8 Descriptions of Object Classes
4.8.9.4 Kinds of Auditing Performed The following events can be audited, provided the security administrator enables auditing for the event class:
Event Audited When Audit Occurs Access When a process enters the DCL command SET SECURITY or SHOW SECURITY with the /CLASS=SECURITY_CLASS qualifier, or when it uses the name SECURITY_CLASS in a call to the system service $SET_ SECURITY or $GET_SECURITY
4.8.9.5 Permanence of the Object The security profiles of the security class object and all its members are stored in the security object database. 4.8.10 Volumes A volume object is one or more ODS-2 disk volumes. The object consists of multiple volumes when they are part of a bound volume set. Although you might have access to the directories and files on the volume, you cannot access them if you do not have access to the volume itself. For access information on tapes and foreign volumes, see the Open VMS System Manager's Manual and the Mount utility documentation in the Open VMS System Management Utilities Reference Manual. 4.8.10.1 Naming Rules A volume name can be the volume label, the name of device on which the volume is mounted, or a user-specified logical name. 4.8.10.2 Types of Access The volume class supports the following types of access: Read Gives you the right to examine file names and print and copy files on a volume. Write Gives you the right to modify or write to existing files on a volume. Whether the subject may perform the operation on a specific file is determined by the file's protection. To be meaningful, write access requires read access. Create Gives you the right to create files on a disk volume and to subsequently modify them. Create access also requires read and write access. Delete Gives you the right to delete files on a disk volume, provided the user has proper access rights at the directory and file level. Delete access requires read access. Control Gives you the right to change the protection and ownership elements of the volume. 4.8.10.3 Template Profile The class provides the following template profile and assigns the values during initialization. Although the template assigns an owner UIC of [0,0], this value is only temporary. As soon as the object is created, the operating system replaces a 0 value with the value in the corresponding field of the creating process's UIC.
4-47 Protecting Data 4.8 Descriptions of Object Classes
Template Name Owner UIC Protection Code DEFAULT [0,0] S:RWCD,O:RWCD,G:RWCD,W:RWCD
4.8.10.4 Privilege Requirements Users with the VOLPRO privilege always have control access to a volume. Mounting a file-structured volume as foreign requires VOLPRO privilege or control access. 4.8.10.5 Kinds of Auditing Performed All volume access can be audited, provided the security administrator enables auditing for the Access event class.
Event Audited When Audit Occurs Access During any file system operation
4.8.10.6 Permanence of the Object The security profile for a volume object is saved in the master file directory (MFD) of the disk as [OOOOOO]SECURITY.SYS.
4-48 Part Ill Security for the System Administrator
The chapters in this part discuss the following topics: • Securing the system and its data (Chapter 5) • Security auditing (Chapter 6) • Responding to security breaches (Chapter 7) • Creating a secure cluster (Chapter 8) • Considerations for systems using networking (Chapter 9) • Setup and management of protected subsystems (Chapter 10) This part of the manual also includes information on the following topics: • User privileges and who may need them (Appendix A) • Default UIC-based protection of critical system files (Appendix B) • Guidelines for operating in a C2 security environment (Appendix C) • Examples of security alarm messages (Appendix D)
5 Managing the System and Its Data
This chapter explains how you, as security administrator, can implement security features of the OpenVMS operating system. Descriptions are based on the security needs of a commercial installation with average security needs, where files and accounts require protection. Descriptions of above-average security needs are also noted. Digital recommends that you read the entire chapter before establishing any security measures. After reading the chapter, you will better be able to decide which security measures are appropriate for your site, and you will have the tools to implement them. The Authorize utility (AUTHORIZE) is the primary tool for implementing system security. AUTHORIZE is described fully in the OpenVMS System Management Utilities Reference Manual. The AUTOGEN command procedure and many DCL commands are also important security tools. For more information about AUTOGEN, see the Open VMS System Manager's Manual and the Open VMS System Management Utilities Reference Manual. DCL commands are described in the Open VMS DCL Dictionary. 5.1 Security Management Account You need an account with privileges to perform the tasks of a security administrator. In many cases, you may serve as both the security administrator and the system manager, so the same account can serve both functions. The Open VMS System Manager's Manual describes the necessary characteristics of a system management account. When the security administration and system management roles are performed by separate individuals, it is important that strong cooperation and open communication exist between you. You require the SECURITY privilege to enable security auditing and to set up security operator terminals.
5.2 Considerations for Establishing User Accounts It is your responsibility as security administrator to train users, assign accounts and passwords, and monitor user actions. This section describes guidelines for these tasks. Refer to Chapter 6 for guidelines on auditing user actions. You base decisions about setting up user accounts on the needs of the particular site. You have the option to develop one or more templates that work for many of your users. However, do not oversimplify the process of account creation to the point that you simply apply a template. The danger in relying solely on templates is that you might overlook special considerations that apply to individual users, thereby forfeiting important controls that only you can exercise. Examine templates regularly to be sure they are valid and reflect the way you want your operations to proceed. Templates become obsolete rapidly.
5-1 Managing the System and Its Data 5.2 Considerations for Establishing User Accounts
5.2.1 Introduction to Group Design As you design user groups, remember that the groups you establish have an impact on file protection and influence those who receive the GROUP, GRPNAM, and GRPPRV privileges. You may want to map out the functions you expect your users to perform. Look for groups of users involved with a common function, such as accounting, engineering, marketing, and personnel. Think ahead to future plans in your organization. Incorporate these ideas into your strategy. You can fine tune the group design at any time, but it is most important to gain a perspective on the logical groupings according to the functions your users perform. Following are two guidelines for determining the placement of users in UIC groups: • Sharing-Users who typically share data and control of processes should be arranged in the same group. • Protection-Users who should not have access to each other's data or control each other's processes should be assigned to separate groups. However, there are limitations to UIC group design. You may want to give only a few members of your UIC group access to files that you own, or you may want to grant access to your files to members of several UIC groups without having to grant world access. These limitations are described in Section 5.2.1.2. 5.2.1.1 Example of UIC Group Design The fictitious Rainbow Paint Company is a distribution company with five departments: executive, accounting, marketing, shipping, and administration. Table 5-1 identifies the employees in the various departments who need computer resources. The table also lists the job responsibilities of the employees.
Table 5-1 Employee Grouping by Department and Function Department Employee Function Executive Samuel Gibson President Olivia Westwood Treasurer Head of Computer Operations Accounting Carlo Ruiz Payroll Rich Smith Bookkeeping Rod Jacobs Clerk Ruth Crandall Clerk Marketi!lg Jason Chang Forecasting Alana Mack Sales Reporting Shipping Scott Giles Inventory Control Administration Jane Simon Correspondence Management Paycheck Printing
The fact that the company has been organized into departments suggests that individuals in the same department perform many of the same functions. For example, the advantage of grouping all the employees who perform bookkeeping tasks for the company in the accounting department is that employees can easily communicate with one another and gain access to the data they must share.
5-2 Managing the System and Its Data 5.2 Considerations for Establishing User Accounts
As the system manager of Rainbow Paint's computer resources, Olivia Westwood will set up UIC groups based on the existing organizational structure. For example, the employees in the accounting department (C. Ruiz, R. Smith, R. Jacobs, and R. Crandall) could be members of the UIC group ACCOUNTING. Setting up the UIC group in this way ensures that user C. Ruiz has easy access to data from user R. Smith, and so on. Effective department organization ensures that only selected employees will have access to all data and employees in the company. For example, one of the functions of the accounting department concerns payroll. Because payroll information is confidential, employees in the shipping and marketing departments should not have access to that information. As the system manager of Rainbow Paint's computer resources, Olivia sets up the UIC groups-ACCOUNTING, EXECUTIVE, MARKETING, SHIPPING, and ADMINISTRATION-corresponding to the various departments in the company. Members of a UIC group can be given common access to files, as shown in the following example: $ SET SECURITY/PROTECTION=G:RWE GROUP_STATS.DAT With this command, the owner of the file GROUP _STATS.DAT allows each member of the UIC group read, write, and execute access to the file. 5.2.1.2 Limitations to UIC Group Design In some cases, UIC-based protection does riot present the best solution to your file protection needs. If users in several UIC groups need access to common files on the system, the only UIC-based alternatives are to give world access to the object (all users can access the object) or to grant extended privileges to each user. Neither choice is desirable. You may also need to allow users in a UIC group several types of access to files; you may want to deny some users in the same group access to the object. Again, UIC-based protection does not offer a good solution to meet these needs. Access control lists (ACLs), described in the following sections, offer another way to protect files and other objects on the system. As the site security administrator, it is extremely important to familiarize yourself with the subtleties of the UIC categories, as described in Section 4.5. Putting users in certain UIC groups may grant them system privileges, and a user with system privilege has control access to any security object on the system. The SYSPRV privilege is given by default to all UIC groups less than or equal to 10, but the actual range for the system UIC category is determined by the value of the MAXSYSGROUP system parameter. Putting users with· the GRPPRV privilege in groups that own system files might also cause security problems. 5.2.2 Designing Access Control Lists (ACLs) and Identifiers Rather than attempting to restructure UIC groups to solve file protection problems, you may be able to achieve your goals by using access control lists (ACLs) on the files. For example, consider the following ACL that you might construct to allow specific users (across various UIC groups) to access the file PAYROLL.DAT: (IDENTIFIER=OWESTWOOD,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=CRUIZ,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=RSMITH,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=JSIMON,ACCESS=READ) (IDENTIFIER=SGIBSON,ACCESS=READ)
5-3 Managing the System and Its Data 5.2 Considerations for Establishing User Accounts
Notice that many of the users share the same access needs. To shorten the ACL, you could use AUTHORIZE to define a general identifier PAYROLL in the rights database. The holders of that identifier could be all users who need read, write, execute, and delete access to PAYROLL.DAT. Once the identifier and its holders are defined, you can use the following ACL to specify the same type of access to PAYROLL.DAT: (IDENTIFIER=PAYROLL,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=JSIMON,ACCESS=READ) (IDENTIFIER=SGIBSON,ACCESS=READ) Using shorter AC Ls with general identifiers has several advantages. The operating system processes shorter ACLs more rapidly. In addition, when employees change but the functions remain the same, you do not have to change every ACL across the system. Instead, you change the holders of the identifier. If employees leave the project, you can edit their records in SYSUAF.DAT so they no longer hold the identifier, or if they leave the company, you can remove their user authorization file (UAF) records altogether. When new employees are hired for the same jobs, grant the new users the right to hold the identifier. The new users then have the same ACL-based access as the former users. Your overall design should consider the types of files and other objects on your system and the protection needs of each. If you have successfully designated groups and identifiers, you should be able to easily design ACLs and define standard protection. Time spent clarifying the common access needs of your users simplifies the design of identifiers and ACLs. You will also simplify the job for your users who place ACLs on their files. Do not use ACLs indiscriminately. They consume paged system dynamic memory when files are open. They also require additional processing time. ACLs are best applied where protection is really needed. If your ACLs become too long (for example, more than 200 entries or so), you might consider grouping users into discrete categories and creating general identifiers. For more information on defining identifiers, see the description of AUTHORIZE in the Open VMS System Management Utilities Reference Manual. For more information about creating and maintaining ACLs, see Chapter 4. For extensive work, using the access control list editor (ACL editor) is appropriate; the ACL editor is described in the Open VMS System Management Utilities Reference Manual. 5.3 Creating and Maintaining a Rights Database Once you have designed the names of the identifiers you want on your system and composed the set of holders for the identifiers, use AUTHORIZE to add the identifiers to the rights database and assign the identifiers to the intended users. These associations are kept in the rights database (RIGHTSLIST.DAT), which you maintain as you add or remove users and identifiers. Initially, the rights database is created at system installation and is located in the [SYS$SYSTEM] directory. At creation, it contains the names of the environmental identifiers and one identifier for each authorized user. The identifier, called a UIC identifier, is associated with the user's UIC and user name.
5-4 Managing the System and Its Data 5.3 Creating and Maintaining a Rights Database
There is also an identifier in the rights database equivalent to each UIC group name. When you add a new user as the first member of a new UIC group and you specify an accounting group name with the user, an identifier corresponding to the accounting group name is added to the rights database, as shown in the following example: $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD ROB/PASSWORD=SP0152/UIC=[Ol4,006] - UAF> /DIRECTORY=WORK:[ROB]/ACCOUNT=MGMT UAF-I-ADDMSG, user record successfully added UAF-I-RDBADDMSGU, identifier ROB value: [000014,000006] added to RIGHTSLIST.DAT UAF-I-RDBADDMSGU, identifier MGMT value: [000014,177777] added to RIGHTSLIST.DAT Because the account name MGMT is specified when adding ROB's account and no UIC group of that name exists, the MGMT identifier is added to the rights database. Each site adapts its own rights database according to actual use and needs. Note that when you use AUTHORIZE to add, remove, or change user names in the system user authorization file (SYSUAF.DAT), AUTHORIZE makes corresponding changes for you in RIGHTSLIST.DAT, so that the rights list corresponds to SYSUAF.DAT. Because of the automatic creation and maintenance of the rights database, you seldom need to use the AUTHORIZE command CREATE/RIGHTS. However, if the rights database is damaged or deleted, you can create a new one with this command. (See the Open VMS System Management Utilities Reference Manual for more information.) 5.3.1 Adding Identifiers You add identifiers to the rights list with the AUTHORIZE command ADD /IDENTIFIER, for example: UAF> ADD/IDENTIFIER PAYROLL identifier PAYROLL value %X80080011 added to RIGHTSLIST.DAT If you accidentally deleted the rights list and it cannot be recovered from a backup copy, recreate RIGHTSLIST.DAT by entering the CREATE/RIGHTS command, followed by the ADD/IDENTIFIER command, as follows: UAF> CREATE/RIGHTS {message} UAF> ADD/IDENTIFIER/USER=* or ADD/IDENTIFIER/USER=[*,*] {messages} The ADD/IDENTIFIER command generates a UIC identifier in the rights list corresponding to each user name in SYSUAF.DAT. To complete the task, use the ADD/IDENTIFIER command to add all general identifiers that were lost. Then redefine the holders of the identifiers with GRANT/IDENTIFIER commands, as described in Section 5.3.2.
5-5 Managing the System and Its Data 5.3 Creating and Maintaining a Rights Database
5.3.2 Assigning Identifiers to Users After adding identifiers, you associate users as holders of the existing identifiers by using the AUTHORIZE command GRANT/IDENTIFIER, as shown in the following example: UAF> GRANT/IDENTIFIER PAYROLL MARTIN . UAF-I-GRANTMSG, identifier PAYROLL granted to MARTIN UAF> GRANT/IDENTIFIER PAYROLL IPPOLITO UAF-I-GRANTMSG, identifier PAYROLL granted to IPPOLITO To give user Martin the EXECUTIVE identifier in addition to the PAYROLL identifier would require another use of the GRANT/IDENTIFIER command. You can introduce only one holder association at a time with the GRANT /IDENTIFIER command. In all cases shown above, AUTHORIZE associates the PAYROLL identifier with the UIC identifier corresponding to the user, specifically Martin and Ippolito. Both the identifiers must exist in the rights database. 5.3.3 Removing Identifiers and Holders When a user leaves the company, remove the UAF record for that user. Notify the managers of all sites where that user has access to proxy accounts to remove proxy access information in the remote node's NETPROXY.DAT file. When you run AUTHORIZE to remove a user's UAF record, AUTHORIZE also removes the user's connections as a holder of identifiers in the rights database. However, if a departed user is the only remaining holder of a given identifier, remove that identifier to avoid future confusion. For example, use the following AUTHORIZE command to remove the identifier 87TERM3: UAF> REMOVE/IDENTIFIER 87TERM3 {message} Before you remove an identifier from the rights database, remove all occurrences of the identifier from ACLs on the system. For example, the following command removes the obsolete identifier 87SUMMER from the ACL of multiple files: $ SET SECURITY/ACL=(IDENTIFIER=87SUMMER)- _$/DELETE/LOG *.*;* You receive errors for files that do not contain the ACE, but the ACE is deleted from all files that do contain it. Next, remove the identifier 87SUMMER from the rights database with the AUTHORIZE command REMOVE/IDENTIFIER. Identifiers in hexadecimal format in an ACE indicate that a general identifier has been deleted from the rights database. Similarly, if you see an identifier displayed as a numeric UIC, the original identifier was a UIC that has been removed. Delete ACEs with numeric UIC or hexadecimal identifiers. It is wise not to reuse UICs after an employee leaves. The new employee may gain some or all of the access rights of the previous employee through ACL entries that still reference the old UIC in numeric format. To rename an identifier, use the AUTHORIZE command RENAME/IDENTIFIER in the following format: · RENAME/IDENTIFIER old-identifier new-identifier
5-6 Managing the System and Its Data 5.3 Creating and Maintaining a Rights Database
Renaming identifiers affects existing ACLs; those that have ACEs specifying renamed identifiers are updated with the new identifier name. 5.3.4 Displaying the Rights Database You should regularly display the rights database to check that it is correct and current. Two AUTHORIZE commands are used for this: SHOW/IDENTIFIER and SHOW/RIGHTS. To display all holders of an identifier, use the SHOW /IDENTIFIER command, as show~ in the following example: UAF> SHOW/IDENTIFIER/FULL NETWORK Use the wildcard asterisk (*) to display all holders of all identifiers on the system, as follows: UAF> SHOW/IDENTIFIER/FULL * To display the identifiers held by a particular user, use the SHOW/RIGHTS command, as follows: UAF> SHOW/RIGHTS/USER=ROBIN Use the wildcard asterisk character to display all identifiers held by all users, as follows: UAF> SHOW/RIGHTS/USER=* UAF> SHOW/RIGHTS/USER=[*,*] The first command displays users alphabetically. The second command displays users according to UICs. 5.3.5 Modifying a System or Process Rights List As a privileged security administrator, you can use the SET RIGHTS_LIST command to modify the rights list of any process on the system or to modify identifiers in the system rights list. The command can also be used to add attributes to existing identifiers. For example, the following command adds the SALES identifier to the process rights list of the process DEDNAM. Specifying the Resource attribute allows the holders of the SALES identifier to charge disk space to it. $ SET RIGHTS_LIST/ENABLE/ATTRIBUTES=RESOURCE/PROCESS=DEDNAM SALES
5.4 Modifying Identifiers for Different Users A final step in designing ACLs and identifiers is to consider how and when different identifiers are going to be used. Users often need to hold an identifier for different reasons, such as updating databases or performing system operations. For this reason, you may want to qualify the use of an identifier. There are several ways to qualify identifiers. One way is to use environmental identifiers, and another is to add special attributes to identifiers. 5.4.1 Using Environmental Identifiers Environmental identifiers describe different types of users based on their initial entry into the system. These identifiers-local, dialup, remote, interactive, network, and batch-let you define a large potential group of users according to their use of the system. Typically, these types of identifiers are used in combination with other identifiers.
5-7 Managing the System and Its Data 5.4 Modifying Identifiers for Different Users
For example, the following ACE permits user Martin to have read, write, execute, and delete access to the object only when logged in from a local terminal: (IDENTIFIER=MARTIN+LOCAL,ACCESS=READ+WRITE+EXECUTE+DELETE) You can use the environmental identifiers in ACLs to deny access to an entire class of logins. For example, the following ACE denies access to all dialup users: (IDENTIFIER=DIALUP,ACCESS=NONE) In assigning these environmental identifiers to users in a DECwindows environment, remember that DECwindows processes can be virtually any type of process. For example, a batch process running DECW$MAIL has the same access capabilities as an interactive or a local process running mail. 5.4.2 Adding Special Attributes to Identifiers Whenever you add identifiers to the rights list or grant identifiers to users, you can stipulate that the identifier carry special characteristics called attributes. Although there are many possible attributes, most sites commonly use the following ones: Dynamic attribute Allows holders of the identifier to remove and to restore the identifier from the process rights list by using the DCL command SET RIGHTS_LIST. Resource attribute Allows holders of the identifier to charge disk space to the identifier. It is used for file objects. Subsystem attribute Allows holders of the identifier to create and maintain protected subsystems by assigning the Subsystem ACE to the application images in the subsystem. No Access attribute Makes any access rights of the identifier null and void. This attribute is intended as a modifier for a resource identifier or the Subsystem attribute. Sites with high security requirements are likely to use two other attributes, which discourage users from scanning the rights database: Holder Hidden attribute Prevents someone from getting a list of users who hold an identifier unless that person owns the identifier. Name Hidden attribute Allows holders of an identifier to have it translated (either from binary to ASCII or vice versa), but prevents unauthorized users from translating the identifier. The following sections describe each attribute and explain when you might want to add them to some of your site's identifiers. 5.4.2.1 Dynamic Attribute Once you grant an identifier to a user, processes created by that user hold the identifier for the life of the process. However, if you grant the identifier with the Dynamic attribute, the user who holds the identifier can use the DCL command SET RIGHTS_LIST to add or remove the identifier or its attributes from the process rights list as needed. To allow users to modify an identifier, specify the Dynamic attribute when adding the identifier to the rights database by using AUTHORIZE, as shown in the following example: $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=DYNAMIC
5-8 Managing the System and Its Data 5.4 Modifying Identifiers for Different Users
To allow specific holders of the identifier to modify the identifier, include the Dynamic attribute when granting the identifier, as follows: UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=DYNAMIC SCHWARTZ User Schwartz could then use the following command to remove the MGMT101 identifier from the process rights list: $ SET RIGHTS_LIST/DISABLE MGMT101 Users who hold identifiers with the Dynamic and Resource attributes can also use the SET RIGHTS_LIST command to remove only the Resource attribute on the identifier. Because users might be able to circumvent intended security policy by removing their identifiers, be careful when granting users an identifier with the Dynamic attribute. If a user who holds an identifier with the Dynamic attribute removes the identifier from the rights database and holders of the identifier were explicitly denied access in an ACL, the user can then gain access to the object through another entry in the ACL. 5.4.2.2 Holder Hidden Attribute Sites with high security requirements can conceal the holders of certain identifiers, thereby preventing malicious users from determining which accounts are more interesting to target for break-ins. You place the attribute on an identifier the user holds by using the AUTHORIZE command MODIFY/IDENTIFIER, for example:
UAF> MODIFY/IDENTIFIER /ATTRIBUTES=HOLDER- HIDDEN SECRET - PROJECT Now the prober cannot discover who is on the secret project. 5.4.2.3 Name Hidden Attribute Sites with high security requirements can hide the names of identifiers. For example, sites implementing mandatory access controls can hide the names of identifiers associated with their security categories. This prevents people from seeing the names of identifiers unless they personally hold them. When an identifier holds the Name Hidden attribute, the operating system refuses to translate the identifier from its binary value to ASCII or from ASCII to the binary value unless the requesting process holds the identifier. To assign the attribute to an identifier, system managers use the AUTHORIZE command, MODIFY/IDENTIFIER, as follows: UAF> MODIFY/IDENTIFIER SECRET NEWS /ATTRIBUTES=NAME HIDDEN
5.4.2.4 No Access Attribute The No Access attribute allows a process to hold an identifier but not have the identifier considered in determining access rights to the object. For example, a user with the Resource and No Access attributes can charge disk space to the identifier but not have access to objects owned by the identifier. Or a system manager can manage data and perform tasks connected with the data but cannot read from or write to any of the files.
S:::_Q Managing the System and Its Data 5.4 Modifying Identifiers for Different Users
You can allow file space to be owned by and charged to an identifier yet prevent the files from being accessed in any way. To do this, specify the No Access attribute with the Resource attribute when adding the identifier to the rights database by using AUTHORIZE, as shown in the following example: UAF> ADD/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS)- UAF> MGMT101 To limit the rights of users holding an identifier with the Resource attribute, grant the identifier with the No Access attribute as well as the Resource attribute to all desired users, as follows: UAF> GRANT/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS) UAF> MGMT101 SCHWARTZ 5.4.2.5 Resource Attribute Consumption of disk space is generally charged to the creator of each file by subtracting the disk space from the file owner's disk quota. System managers and security administrators might prefer to track the use of disk space according to logical groups of users (such as departments or projects) rather than individual users. General identifiers are used to specify these groups. Thus, when general identifiers own directories, disk space used by files created in the directories may be charged to the identifier rather than the UIC of the file's creator. To allow file space to be owned by and charged to an identifier, specify the Resource attribute when adding the identifier to the rights database by using AUTHORIZE, as shown in the following example: UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=RESOURCE To allow specific holders of the identifier to charge disk space to the identifier, perform the following steps: 1. Grant the identifier with the Resource attribute to all desired users, as follows: UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=RESOURCE SCHWARTZ 2. Modify the directory to allow read and write access to the resource identifier, as follows: $ SET SECURITY/ACL=(- $ (IDENTIFIER=MGMTlOl,ACCESS=READ+WRITE ) - -$ (IDENTIFIER=MGMT101,0PTIONS=DEFAULT,ACCESS=READ+WRITE)) =$ INVENTORY.DIR Because resource identifier MGMT101 is going to own any file you create in directory INVENTORY.DIR, you use ACEs to determine the type of file access you receive. Include a Creator ACE (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE) to set the access granted to the file's creator. Alternatively, you can let the system assign an ACE; its ACE grants control access to the file's creator plus the access specified in the owner field of the protection code. You can set up the protection code by including a Default Protection ACE in the ACL for INVENTORY.DIR; for example, (DEFAULT_PROTECTION, ACCESS=O:RW). (Refer to Section 5.5.1.2 for further information.) Not everyone who holds the identifier will also hold the Resource attribute associated with that identifier. If you create a file in a directory owned by an identifier but you do not have the Resource attribute for that identifier, the required disk space is subtracted from your disk quota.
~-10 Managing the System and Its Data 5.4 Modifying Identifiers for Different Users
5.4.2.6 Subsystem Attribute You can authorize users to manage protected subsystems by granting them a subsystem identifier with the Subsystem attribute. This empowers users to enable images to access the objects managed by the subsystem. (See Chapter 10 for a discussion of protected subsystems.) In the following example, user Schwartz is given the authority to create a subsystem with the identifier MAIL_SUBSYSTEM. Schwartz is also given control access to the application image to set access controls. $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/IDENTIFIER MAIL SUBSYSTEM /ATTRIBUTES=SUBSYSTEM UAF> GRANT/IDENTIFIER MAIL SUBSYSTEM - UAF> /ATTRIBUTES=SUBSYSTEM SCHWARTZ UAF> Exit $ SET SECURITY/ACL=(IDENTIFIER=MAIL SUBSYSTEM,ACCESS=CONTROL)- _$ MEMBER_LIST.EXE -
5.5 Setting Object Protection and Ownership Defaults for Users After designing user groups and identifiers, you need to address which protected objects your users need permission to access and which ones can be unrestricted. Become familiar with the default protection of new objects, shown in Section 4.8, and when necessary modify the defaults, as shown in the following sections. The procedure for setting up object protection and ownership defaults varies, depending on whether the object is a file or another class of protected object. 5.5.1 Setting File Defaults If you know that a user will be using a directory or file that demands special protection, you must determine which of a number of possible protection defaults will affect the user. Exert additional control where the default protection is deemed inadequate. Section 4.8.4 describes default protection in detail. There are four possible areas where you can specify protection defaults that would affect the user. In order of increasing influence, they are as follows: • The system parameter RMS_FILEPROT sets the systemwide default for file protection. You can change the value of RMS_FILEPROT with AUTOGEN. However, the effectiveness of this value may be overridden by any of the following defaults. • The DCL command SET PROTECTION/DEFAULT can specify the file protection placed on files created or modified by the user during the terminal session. While the command typically appears in the user's login command procedure, the user can also enter this command at any time during a session to override the value set by a previous SET PROTECTION/DEFAULT command. The SET PROTECTION/DEFAULT command negates the influence of the systemwide protection for this user. • The default protection for the specific directory can be specified in an ACL applied to the directory. If a Default Protection ACE exists for the directory, all new files added to the directory, including subdirectories and their files, are subject to this protection code. This code overrides the systemwide default and the user-specified default (if any).
5-11 Managing the System and Its Data 5.5 Setting Object Protection and Ownership Defaults for Users
• In special cases where the file being created is not owned by the user identification code (UIC) of the process creating the file (for example, when a directory is owned by a resource identifier), the default protection for the new file can be modified by a Creator ACE within the directory's ACL. Refer to Section 4.8.4.5 for a discussion of the Creator ACE. Also consider the protection imposed on the volume through the DCL command SET VOLUME/PROTECTION. This protection code, if specified, prevents a user from accessing any part of the volume, regardless of the protection code on the directory or the file. If no volume protection is specified with the SET VOLUME command, the volume is accessible to all users. As Section 4.8.4 explains, the assignment of file ownership affects the outcome of any protection check. The operational effect of this combined protection structure is depicted in Figure 5-1.
5-12 Managing the System and Its Data 5.5 Setting Object Protection and Ownership Defaults for Users
Figure 5-1 Flowchart of File Creation
User attempts to create a file.
Assign file protection.
Exit; file not written.
Exit; file not written.
Obtain the specified protection code; go to BB.
Obtain its protection code; go to BB.
Obtain this protection code; go to BB.
Obtain this protection code; go to BB.
ZK-2034.1-GE
(continued on next page)
5-13 Managing the System and Its Data 5.5 Setting Object Protection and Ownership Defaults for Users
Figure 5-1 (Cont.) Flowchart of Fiie Creation
Obtain the systemwide AA def ault from the parameter RMS_FILEPROT.
Create the file and apply the BB protection mask previously obtained.
No
Set owner from the directory file; go to CC.
Set owner to creator's UIC.
ZK-2034.2-GE
(continued on next page)
5-14 Managing the System and Its Data 5.5 Setting Object Protection and Ownership Defaults for Users
Figure 5-1 (Cont.) Flowchart of File Creation
Set up ACL. Copy ACL from the previous version, removing any ACEs marked Nopropagate; go to DD.
Copy all ACEs marked default from the directory's ACL, removing the default option.
DD
Copy protection from ACE; go to EE.
Place an ACE at the top of the ACL that gives the file's creator control access plus access available to file owner.
EE
Done; exit.
ZK-5228A-GE
5.5.1.1 Adjusting Protection Defaults You may want to make adjustments to control default behavior. The systemwide default protection code specified by the system parameter RMS_FILE PROT sets the user's default protection to the following: (S:RWED,O:RWED,G:RE,W) Assume that the volume protection has been set by the operator to the following: (S:RWED,O:RWED,G:R,W)
5-15 Managing the System and Its Data 5.5 Setting Object Protection and Ownership Defaults for Users
The file protection on the directory [PROJECT] has been set to the following: (S:RWED,O:RW,G:R,W) If all the files created in the subdirectory [PROJECT.DIARY] demand more protection, you, or any user who has the same access as the owner of the directory, could define a specific default protection code for this specific directory with an ACL consisting of a Default Protection ACE, as follows: (DEFAULT _PROTECTION ,S: RWED ,0: RWED ,G, W) The following DCL command would provide the desired default protection: $ SET SECURITY/ACL=(DEFAULT PROTECTION,S:RWED,O:RWED)- _$ [PROJECT]DIARY.DIR - Once this ACL is placed on the directory file, files created or modified in the directory are subject to the default protection code. However, default protection codes can be easily overridden by any user with the BYPASS privilege and can be circumvented under certain circumstances by users with SYSPRV, GRPPRV, or READALL privilege. Because they are only defaults, a user who acquires control access to a file in the directory can include a specific protection code as a replacement for the default value on the file by using the following DCL commands: • SET SECURITY/PROTECTION • COPY/PROTECTION • APPEND/PROTECTION • CREATE/PROTECTION Once the default protection code is replaced, the new code becomes the default and is propagated to subsequent versions of the file. If you provide a special login command procedure for some of your users, you may want to supplement the systemwide default process protection specified by the system parameter RMS_FILEPROT for this group of users. Add the SET PROTECTION/DEFAULT command to the login command procedure to specify the default process protection, as follows: SET PROTECTION=(S:RWED,O:RWED,G,W)/DEFAULT Files created in users' directories receive this default protection code unless explicitly overridden. 5.5.1.2 Setting Defaults for a Directory Owned by a Resource Identifier To allow for more flexible data management as well as more accurate accounting of disk space, you can set up a directory that is owned by a resource identifier and rely on ACLs to control access to the account and to files created within the directory. The ACL can limit file access to all project members holding the project identifier. To achieve this kind of access restriction, you add an Identifier ACE to define the group's access to files. A second Identifier ACE is added that duplicates the first yet holds the Default attribute. It is the Default attribute that ensures the ACE is copied to all files created within the directory. Sometimes a third ACE is necessary-a Default Protection ACE, depending on the default protection code for the directory. A Default Protection ACE establishes the protection code for the directory's files. (As Section 4.3 explains, if an ACL denies access to a file, it is still possible to gain access through a protection code.)
5-16 Managing the System and Its Data 5.5 Setting Object Protection and Ownership Defaults for Users
In addition to limiting the group's access to files, an ACL can control the type of access users have to files that they have created within the common directory. Because the file is created in the resource identifier's directory, the resource identifier owns the file. For users to access files they have created, the operating system normally gives control access to the file's creator plus the access specified in the owner field of the protection code. However, you can modify this behavior by adding a Creator ACE to the directory's ACL. A Creator ACE defines the type of access users have to files they have created in the project's directory. 5.5.1.2.1 Setting Up the Resource Identifier A security administrator used the following command sequence to set up the project identifier PROJECTX and grant it to members of the project. Notice that the identifier is added to the rights database with the resource identifier, and it is also granted to users with the resource identifier. The project identifier needs to carry the Resource attribute so it can own disk space. $ RUN SYS$SYSTEM:AUTHORIZE UAF> ADD/IDENTIFIER PROJECTX /ATTRIBUTES=RESOURCE UAF> GRANT/IDENTIFIER PROJECTX userl /ATTRIBUTES=RESOURCE UAF> GRANT/IDENTIFIER PROJECTX user2 /ATTRIBUTES=RESOURCE
5.5.1.2.2 Setting Up the Directory of a Resource Identifier When a project- or department-specific identifier is the owner of a directory, the space used by files created in the directory can be charged to the appropriate department or project rather than to the individual who creates them. When users work on multiple projects, they can charge their disk space requirements to the related project rather than to their personal accounts. In setting up a directory for a resource identifier, you first create the disk quota authorization for the project identifier. For example, the following command invokes the System Management utility (SYSMAN) and assigns the identifier PROJECTX 2000 blocks of disk quota with 200 blocks of overdraft: $ RUN SYS$SYSTEM:SYSMAN SYSMAN> DISKQUOTA ADD PROJECTX /PERMQUOTA=2000 /OVERDRAFT=200 After setting up the disk quota, you create the project directory. For example, the following DCL command creates the project directory [PROJECTX] and establishes the identifier PROJECTX as its owner: $ CREATE/DIRECTORY [PROJECTX] /OWNER=[PROJECTX] 5.5.1.2.3 Setting Up the ACL In setting up the directory [PROJECTX], you use an ACL to provide file access to project members. The following example shows how several ACEs are used to define access: $ SET SECURITY [PROJECTX] /ACL= (- $ (DEFAULT PROTECTION,S:RWED,O:RWED,G,W),- 0 -$ (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE),- f} -$ (IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE),- 6) =$ (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE)) C) 0 The Default Protection ACE sets up a protection code for files created within the directory. The ACE denies access to group and world users. @ The first Identifier ACE gives holders of the PROJECTX identifier read, write, and execute access to the directory.
5-17 Managing the System and Its Data 5.5 Setting Object Protection and Ownership Defaults for Users
0 The second Identifier ACE guarantees that all files created in the directory will carry the first Identifier ACE. 0 The Creator ACE specifies that a user who creates a file in the PROJECTX directory will receive read, write, execute, and delete access to it. Thus, when project member Crandall creates the file SEPTEMBER REPORTS. TXT in the [PROJECTX] directory, the file receives the following security profile:
$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT SEPTEMBER-REPORTS.TXT object of class FILE Owner: [PROJECTX] Protection: (System: RWED, Owner: RWED, Group, World) Access Control List: (IDENTIFIER=CRANDALL,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE) Project members are not allowed to delete (or control) files created by others; however, the Creator ACE gives them delete access to files they have created. Without a Creator ACE, project members each have complete access to files they have created in the directory. For example, Crandall would receive the following access to files created in the project directories:
$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT SEPTEMBER-REPORTS.TXT object of class FILE Owner: [CRANDALL] Protection: (System: RWED, Owner: RWED, Group, World) Access Control List: (IDENTIFIER=CRANDALL,OPTIONS=NOPROPAGATE,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE) To negate this behavior, you can add a Creator ACE to the ACL that specifies ACCESS=NONE. 5.5.2 Setting Defaults for Objects Other Than Files With the exception of files, all classes of protected objects offer one or more template profiles that provide security elements for new objects. You can thus use a single mechanism to establish the default protection code, ACL, and ownership elements for objects. The operating system always stores these values so they are available from one system startup to the next. The SHOW SECURITY command displays the current default values for your particular site. Refer to Section 4.8 for a listing of the operating system's default values. The operating system generates the security profiles of new objects from data stored by security class objects. These objects are all logical constructs used to keep track of such class elements as the valid access types, the templates, and the types of auditing that have been enabled. As Figure 5-2 shows, every class of protected object (except for files, which have their own rules) has a member in the security class.
5-18 Managing the System and Its Data 5.5 Setting Object Protection and Ownership Defaults for Users
Figure 5-2 Security Class Object
Common Event Flag Cluster Device File Group Global Section Logical Name Table Members Queue Resource Domain System Global Section Volume Security Class Object Capability
DCL Commands: SET SECURITY SHOW SECURITY Management Interface System Services: $SET_SECURITY $GET_SECURITY
ZK-2445A-GE
5.5.2.1 Displaying Class Defaults To display any class template, use the SHOW SECURITY/CLASS=SECURITY_ CLASS command. The following command, for example, displays templates available for logical name tables. The logical name table object has the following three templates:
$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE
Template: GROUP Owner: [TTSY,SYSTEM] Protection: (System: RWCD, OWner: R, Group: R, World:r) Access Control List:
5-19 Managing the System and Its Data 5.5 Setting Object Protection and Ownership Defaults for Users
5.5.2.2 Modifying Class Templates Security administrators and users with control access to a security class object can modify the elements of a given template with the following command: SET SECURITY/CLASS=SECURITY_CLASS/PROFILE= TEMPLATE=template-name The following command modifies the mailbox template for the device class. It changes the template values from a protection of S:RWPL,O:RWPL,G:RWPL,W:RWPL to a protection that disallows group and world access. $ SET SECURITY/CLASS=SECURITY CLASS/TEMPLATE=MAILBOX - _$ /PROTECTION=(S:RWPL,ORWPL,G,W) DEVICE The operating system applies this value to all new mailboxes. To change the protection for each existing mailbox, enter an explicit SET SECURITY command for each existing mailbox. For example: $ SET SECURITY/CLASS=DEVICE - _$ /PROTECTION=(S:RWPL,ORWPL,G,W) mailbox_name The operating system saves the default object protections specified in security templates, so rebooting the system automatically ensures that all objects created after the reboot are created with the new default protections. The DCL command SHOW SECURITY displays all available templates with the site values. Section 4.8 lists the default system values. 5.6 Password Management A site needing average security protection always requires use of passwords. Sites with more security needs frequently impose a generated password scheme (see Section 5.6.6) and possibly system passwords as well. This section describes password management. 5.6.1 Initial Passwords When you open an account for a new user with AUTHORIZE, you must give the user a user name and an initial password. When you assign temporary initial passwords, observe all guidelines recommended in Section 3.8. You may want to use the automatic password generator. Avoid any obvio0:s pattern when you assign passwords. To use the automatic password generator while using AUTHORIZE to open an account, add the /GENERATE_PASSWORD qualifier to either the ADD or the COPY command. The system responds by offering you a list of automatically generated password choices. Select one of these passwords, and continue setting up the account.
Note ~~~~~~~~~~~~~ There are restrictions on using the /GENERATE_PASSWORD qualifier with the /PWDMINIMUM qualifier. Generated passwords have an absolute length of 12 characters (see Section 5.6.4.3). Whenever there is a conflict between the value of /PWDMINIMUM and a generated password, the operating system uses the lesser of the two values.
5-20 Managing the System and Its Data 5.6 Password Management
You may want to use the AUTHORIZE qualifier /PWDEXPIRED to define the user's password as expired. This forces the user to change the initial password when first logging in. See Section 5.6.4 for more information. Be sure to include information on the first login in your user training so that users know what to expect. Preexpired passwords are conspicuous in the UAF record listing. The entry for the date of the last password change carries the following notation: (pre-expired) 5.6.2 System Passwords Section 3.2.1 introduces system passwords, which control access to particular terminals. System passwords are used to control access to terminals that might be targets for unauthorized use, as follows: • All terminals using dialup lines or public data networks for access • Terminals on lines that are publicly accessible and not tightly secured, such as those in computer laboratories at universities • Terminals not frequently inspected • Terminals intended for use only as spare devices • Terminals you want to reserve for security operations Implementing system passwords is a two-stage operation involving the DCL commands SET TERMINAL and SET PASSWORD: 1. Decide which terminals require system passwords. Then, for each terminal, enter the DCL command SET TERMINAL/SYSPWD/PERMANENT. When you are satisified that you have selected the right terminals, incorporate these commands in SYS$MANAGER:SYSTARTUP_VMS.COM so that the terminal setup work is done automatically at system startup. You can remove the restriction on a terminal at any time by invoking the DCL command SET TERMINAL/NOSYSPWD/PERMANENT for that terminal. 2. Choose a system password, and implement it with the DCL command SET PASSWORD/SYSTEM, which requires the SECURITY privilege. This command prompts you for the password and then prompts you again for verification, just as is done for user passwords. To request automatic password generation, include the /GENERATE qualifier. To enable the use of the system password for the remote class of logins (those accomplished through the DCL command SET HOST), set the appropriate bit in the default terminal characteristics parameter by using AUTOGEN. This is bit 19 (hexadecimal value 80000) in the parameter TTY_DEFCHAR2. Note that if you set this bit, you must invoke the DCL command SET TERMINAL/NOSYSPWD /PERMANENT to disable system passwords for each terminal where you do not want the feature. (As before, consider placing the SET TERMINAL commands you have tested in SYS$MANAGER:SYSTARTUP_VMS.COM.) Then follow the previously defined steps to set the system password. When choosing a system password, follow the recommendations presented in Section 3.8. Choose a string of characters and digits, with a minimum length of 6, that is not a valid word. Although the system password is not subject to expiration, change the password frequently. Always change the system password as soon as a person who knows the password leaves. Share the system password only with those who need to know.
5-21 Managing the System and Its Data 5.6 Password Management
The system password is stored in a separate UAF record and cannot be displayed. The DCL command SET PASSWORD/SYSTEM (the normal means of setting and changing the system password) requires that you enter the old system password before changing it. Use the AUTHORIZE command MODIFY/SYSTEM_ PASSWORD to change the system password without specifying the old password, as shown in the following command: UAF> MODIFY/SYSTEM PASSWORD=ABRACADABRA The primary function of the system password is to form a first line Qf defense for publicly accessible ports and to prevent potential intruders from learning the identity of the system. However, requiring system passwords can appear confusing when authorized users are unaware that they are required on certain terminals. To avoid false reports of defective terminals or systems, inform your users which terminals allocated for their use require system passwords. Where system passwords are not applied to either control access through dialup lines or on publicly accessed lines, few people may know the system password. Operations are hampered if the personnel who know the password are unavailable, incapacitated, or forget the password. Solve this problem by invoking AUTHORIZE and entering the MODIFY/SYSTEM_PASSWORD command. SYSPRV privilege is required. 5.6.3 Primary and Secondary Passwords Sites with high-level security concerns can require a second password on user accounts. Typically, the user does not know the secondary password, and a supervisor or other key person must be present to supply it. For certain applications, the supervisor may also decide to remain present while the account is in use. The effectiveness of a secondary password depends on the trustworthiness of the supervisor who supplies it because the supervisor can remove the secondary password by changing it to a null string. Although the use of dual passwords is cumbersome, they do offer the following three advantages: • When used on a widespread basis, dual passwords help verify the identity of each user at login time because the supervisor or other key person can check each user. • When used in limited cases, dual passwords single out accounts that can be logged in to only when two persons are present. • Dual passwords also prevent the use of access control strings when users access accounts through DECnet software. Sites with medium security requirements may use dual passwords as a tool when there are unexplained break-ins after the password has been changed and use of the password generator has been enforced. Select problem accounts, and make them a temporary target of this restriction. If the problem goes away when you institute personal verification through the secondary password, you know you have a personnel problem. Most likely, the authorized user is revealing the password for the account to one or more other users who are abusing the account. Implement dual passwords with the AUTHORIZE qualifier /PASSWORD. For example, to impose dual passwords on a new account, invoke AUTHORIZE and use the following form of the ADD command: ADD newusername /PASSWORD=(primarypwd, secondarypwd)
5-22 Managing the System and Its Data 5.6 Password Management
To impose a secondary password on an existing account, use the following form of the MODIFY command:
11 MODIFY username /PASSWORD=(" , secondarypwd) This command does not affect the primary password that already exists for the account but adds the requirement that a secondary password be provided at each subsequent login. The secondary password acquires the same password lifetime and minimum length values in effect for the primary password. If the /FLAGS=GENPWD qualifier has been specified for this account, the secondary password can be changed only under the control of the automatic password generator. You cannot use wildcards in the user name parameter to apply a secondary password to multiple users with a single command.
Note ------While you can specify secondary passwords for accounts requiring remote access through the DCL command SET HOST, you cannot specify them for accounts requiring network file access using access control strings. Do not specify secondary passwords on accounts that require network access, or request remote security administrators to set up proxy accounts for those users requiring file access to other nodes in the network.
5.6.4 Enforcing Minimum Password Standards Security administrators can use AUTHORIZE to impose minimum password standards for individual users. Specifically, qualifiers and login flags provided by AUTHORIZE control how soon passwords will expire, whether the user is forced to change passwords at expiration, and the minimum password length. 5.6.4.1 Password Expiration With the AUTHORIZE qualifier /PWDLIFETIME, you can establish the maximum length of time that can elapse before the user is forced to change the password or lose access to the account. By default, the value of /PWDLIFETIME is 90 days. You can change the frequency requirements for user password changes by specifying a different delta time value for the qualifier. For example, to require a user to change the password every 30 days, you would specify the qualifier as /PWDLIFETIME=30-0. The /PWDLIFETIME qualifier applies to both primary and secondary user passwords, but not to the system password. Each primary and secondary password for a user is subject to the same maximum lifetime. However, the passwords can change at separate times. As soon as the user completes a password change, that individual password's clock is reset; the new password value can exist unchanged for the length of time dictated by /PWDLIFETIME. AUTHORIZE also provides two login flags related to primary and secondary password expiration. These flags, PWD_EXPIRED and PWD2_EXPIRED, are specified with the /FLAGS qualifier. The first flag, PWD_EXPIRED, is set after the primary password expires and the user has had one last chance to change the password and has failed to do so. The second flag, PWD2_EXPIRED, is set after the secondary password expires and the user has had one last chance to change the secondary password and has failed to do so. If either PWD_EXPIRED or PWD2_EXPIRED is set, the account is disabled for logins because the user failed to employ the last chance to change the password during the last login.
5-23 Managing the System and Its Data 5.6 Password Management
As soon as the user successftilly changes the password, the system resets the flags, as appropriate. The flag PWD_EXPIRED becomes NOPWD_EXPIRED as soon as the primary password is changed. Similarly, the flag PWD2_EXPIRED becomes NOPWD2_EXPIRED as soon as the secondary password is changed. As security administrator, you may choose to invoke AUTHORIZE and reset the flags, giving the user another chance to reset the password. The use of a password lifetime forces the user to change passwords regularly. The lifetime can be different for different users. Users with access to critical files generally should have the shortest password lifetimes. System passwords have an unlimited lifetime. Therefore, change the system password regularly. 5.6.4.2 Forcing Expired Password Changes By default, users are forced to change expired passwords when logging in. Users whose passwords have expired are prompted for new passwords at login. This password feature is valid only when a password expiration date is specified with the /PWDLIFETIME qualifier. To disable forced password changes, specify the following qualifier to the ADD or the MODIFY command: /FLAGS=DISFORCE_PWD_CHANGE Once disabled, the forced password feature can be reenabled by clearing the login flag, as shown in the following example: /FLAGS=NODISFORCE_PWD_CHANGE Users who log in and are prompted to change expired passwords can cancel the login by pressing Ctrl/Y.
If secondary passwords are in effect and both primary and secondary passwords have expired, the user is forced to change both passwords. If the user changes the primary password and presses Ctrl/Y before changing the secondary password, the user is logged out, and no password change is recorded.
5.6.4.3 Minimum Password Length With the AUTHORIZE qualifier /PWDMINIMUM, you can direct that all password choices, both primary and secondary, must contain a minimum number of characters. (Users can still specify passwords up to the maximum length of 32 characters.) A user's minimum password length is either the default of 6 characters or another value established by the /PWDMINIMUM qualifier (provided the number is 10 or less). The length of a generated password (!GENERATE_PASSWORD or SET PASSWORD/GENERATE) can conflict with the value provided with the /PWDMINIMUM qualifier. The password generator creates passwords that range in length between n and n+2, where the minimum length n is a value ranging from 1 to 10.
5-24 Managing the System and Its Data 5.6 Password Management
When there is a conflict between n and the value set by the /PWDMINIMUM qualifier, the operating system uses the lesser value, but never more than 10. For example, if you specify a length of 25 with the /PWDMINIMUM qualifier, the operating system generates passwords of 10 to 12 characters. The system does not notify you of the difference in values. The length of a generated password produced by the AUTHORIZE qualifier /GENERATE_PASSWORD comes from the Pwdminimum field of the source UAF record: the DEFAULT record or the UAF record copied. The Pwdminimum field is updated with the value set by /PWDMINIMUM, and so passwords created with SET PASSWORD/GENERATE use the new value. The system password is not subject to a minimum length. Guidelines that apply to user passwords are equally applicable to system passwords. Choose system passwords that are 1 to 32 characters long. 5.6.5 Screening New Passwords The system generally compares new passwords against a system dictionary stored in SYS$LIBRARY to ensure that a password is not a native language word. It also maintains a history list of a user's passwords and compares each new password against this list to guarantee that an old password is not reused. You can screen passwords further by developing and installing an image that filters passwords for words that are particularly sensitive to a site. 5.6.5.1 System Dictionary The DCL command SET PASSWORD takes a user's proposed password, converts it to lowercase (if necessary), and compares it to entries in a system dictionary to ensure that a password is not a native language word. If a proposed password is found in the dictionary, it is rejected as a valid user password, and the user has to provide another. You may want to modify the system password dictionary to include words of significance to your site. The following procedure lets you add words to the system dictionary. The procedure also lets you retain a file of the passwords that you consider unacceptable. 1. Create a file containing passwords you would like to add to the dictionary. Each password should be on a separate line and in lowercase, as follows: $ CREATE LOCAL PASSWORD DICTIONARY.DATA sornef arnous - - localheroes lctrltZI 2. Enable SYSPRV and merge your local additions: $ SET PROCESS/PRIVILEGE=SYSPRV $ CONVERT/MERGE/PAD LOCAL PASSWORD DICTIONARY.DATA - _$ SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA You can disable the dictionary search by using AUTHORIZE with the DISPWDDIC option to the /FLAGS qualifier.
5-25 Managing the System and Its Data 5.6 Password Management
5.6.5.2 Password History List The operating system maintains a list of a user's passwords from the last 365 days and compares each proposed password against this list to ensure that passwords are not reused. Once a user successfully creates a new password, the system enters the old password on the history list and updates the file. The password history list can hold a large number of words, but it is limited to 60 by default. If this number is exceeded, the user has to use generated passwords. A password remains on the password history list for 365 days (or the default set by SYS$PASSWORD_ HISTORY_LIFETIME). Whenever a user account is deleted, the system removes all password records belonging to that account. Using the DCL command DEFINE, you can change the defaults for the capacity and lifetime of the password history list to any of the values indicated in Table 5-2.
Table 5-2 Defaults for Password History List System Logical Name Default Min Max Units SYS$PASSWORD_HISTORY_LIFETIME 365 1 28000 Days SYS$PASSWORD_HISTORY_LIMIT 60 1 2000 Absolute count
For example, to increase the capacity of the history list from 60 passwords to 100, add the following line to the command procedure SYLOGICALS.COM, which is located in SYS$MANAGER: $ DEFINE/SYSTEM/EXEC SYS$PASSWORD_HISTORY_LIMIT 100 There is a correspondence between the lifetime of a password history list and the number of passwords allowed on the list. For example, if you increase the password history lifetime to 4 years and your passwords expire every 2 weeks, you would need to increase the password history limit to at least 104 (4 years times 26 passwords a year). The password history lifetime and limit can be changed dynamically, but they should be consistent across all nodes on the cluster. Sites using secondary passwords may need to double the password limit to account for the secondary password storage. The password history list is located in SYS$SYSTEM. You can move the list off the system disk by using the logical name VMS$PASSWORD_ HISTORY. Define this logical name as /SYSTEM/EXEC, and place it in SYS$MANAGER:SYLOGICALS.COM. You disable the history search with the DISPWDHIS option to the /FLAGS qualifier in AUTHORIZE. 5.6.5.3 Site-Specific Filter You can develop a site-specific password filter to ensure that passwords are not words readily associated with your site; for example, product names or personnel names would not be accepted as passwords. A filter can also check for particular combinations of characters. To create a list of site-specific words, you write the source code, create a shareable image, install the image, and, finally, enable the policy by setting a system parameter. See the Open VMS Programming Concepts Manual for instructions.
5-26 Managing the System and Its Data 5.6 Password Management
Installing and enabling a site-specific password filter requires both SYSPRV and CMKRNL privileges. Multiple security alarms are generated when the password filter image is installed if INSTALL and SYSPRV file-access auditing are enabled and the required change to the system parameter is noted on the operator console. The shareable image contains two global routines that are called by the Set Password utility (SET PASSWORD) whenever a user changes a password.
______Warning The two global routines let you obtain both the proposed plaintext password and its equivalent quadword hash value. All security administrators should be aware of this feature because its subversion by a malicious privileged user will compromise the system's security. Digital recommends that you place security Alarm ACEs on the password filter image and its parent directory. See the Open VMS Programming Concepts Manual for instructions.
5.6.6 Requiring the Password Generator The /FLAGS=GENPWD qualifier in AUTHORIZE lets you force use of the automatic password generator when a user changes a password. At some sites, all accounts are created with this qualifier. At other sites, the security administrator may be more selective. If a user will have access to sensitive data that must not be compromised by a break-in, require them to use the password generator. If your policy is to request voluntary use of the password generator and users are not cooperating, you can force users to use the password generator by adding the /FLAGS=GENPWD qualifier to pertinent user accounts. You can also add the AUTHORIZE qualifier /FLAGS=LOCKPWD to user accounts to prevent users from changing passwords. Only you as system manager will be authorized to change passwords. 5.6.7 Specifying a Site-Specific Password Algorithm The operating system protects passwords from disclosure through encryption. OpenVMS algorithms transform passwords from plaintext strings into ciphertext, which is then stored in the system user authorization file (SYSUAF.DAT). Whenever a password check is done, the check is based on the encrypted password, not the plaintext password. The system password is always encrypted with an algorithm known to the operating system. You can encrypt the primary password, the secondary password, or both. The /ALGORITHM qualifier in AUTHORIZE allows you to define which algorithm the operating system should use to encrypt a user's password. Your choices are the current OpenVMS algorithm or a site-specific algorithm. The syntax is as follows: /ALGORITHM=keyword=type [=value] To assign the OpenVMS password encryption algorithm for a user, you would enter the following command: UAF> MODIFY HOBBIT/ALGORITHM=PRIMARY=VMS
5-27 Managing the System and Its Data 5.6 Password Management
If a site-specific algorithm is selected, you must give a value to identify the algorithm, for example: UAF> MODIFY HOBBIT/ALGORITHM=CURRENT=CUSTOMER=128 The Open VMS Programming Concepts Manual provides directions for using a customer algorithm. You must create a site-specific system service in which you write code that recognizes the algorithm number you choose and encrypts the password appropriately. This number has to correspond with the number used in the AUTHORIZE command MODIFY/ALGORITHM. Whenever a user is assigned a site-specific algorithm, AUTHORIZE reports this information in the display provided by the SHOW command. 5.6.8 Enabling the Console Password The console terminal controls operation of the CPU and, consequently, operation of the system. Sites with high security requirements should consider using the password security feature when it is available. (Certain VAXstation 3100s and later models offer it.) Once the password is enabled, operators must enter it before using any privileged command in console mode. Privileged commands include the following two types: • Commands that examine or modify memory and registers, such as SET, EXAMINE, DEPOSIT, FIND, and SHOW • Commands that transfer control of the CPU from the console monitor to another program, such as BOOT and START To enable the console password feature, take the following steps: 1. Enter the privileged command: >» SET PSWD 2. In response, the console prompts for a password: 1 »> Enter the new password, and press the Return key. Note that the console does not display the password as you enter it. The password must be a hexadecimal string of characters (0 through 9 and A through F) with a length of exactly 16 characters. 3. If the password character string is of the right length, the console prompts for you to reenter the new password for verification: 2 >» Reenter the new password, and press Return. Again, note that the password is not displayed. 4. Enable the password security feat,ure with the following command: »> SET PSE 1 To place the workstation in privileged mode and make all console commands accessible, use the LOGIN command. The SHOW PSE command displays the current status of the password feature. (If a 1 is displayed, the feature is enabled; a 0 indicates it is disabled.) To disable the feature, use the SET PSE command with a 0 argument.
5-28 Managing the System and Its Data 5.6 Password Management
Because the password is stored in nonvolatile memory, you must call the Customer Support Center if you forget it. 5.6.9 Protecting Passwords In addition to all the recommendations included in Section 3.8, observe the following guidelines to protect passwords: • Make certain the passwords on the standard accounts SYSTEM, FIELD, and SYSTEST are secure and changed regularly. You can disable the FIELD and SYSTEST accounts with the AUTHORIZE qualifier /FLAGS=DISUSER when they are not in use. • Do not permit an outside or in-house service organization to dictate the password for an account they use to service your system. Such service groups tend to use the same password on all systems, and their accounts are usually privileged. On seldom-used accounts, set the AUTHORIZE qualifier /FLAGS=DISUSER, and enable the account only when it is needed. Change the password immediately after each use, and notify the service group of the new password when they need it next. • Delete accounts no longer in use. • Do not leave listings where they can be read or stolen. • Maintain adequate protection of authorization files. Note that the system user authorization file (SYSUAF.DAT) and network proxy authorization file (NETPROXY.DAT) are owned by the system account ([SYSTEM]). Do not create any other user accounts in this group. Normally the default UIC-based file protection for these authorization files is adequate. (You might use ACLs on the listing files SYSUAF.LIS and NETPROXY.LIS to grant access only to selected individuals.) The following actions are not strictly for password protection but reduce the potential of password detection or limit the extent of the damage if passwords are discovered or bypassed: • Avoid giving multiple users access to the same account. • Protect telephone numbers for dialup lines connected to your system, and consider setting a system password (SET TERMINAUSYSPASSWORD) on dialup lines. • If your system has accounts available to outside users, such as guest accounts or Quality Assurance Reporting (QAR) accounts, make these accounts captive (limited-access) accounts contained by captive command procedures. (See Section 5.13.1 for information about setting up captive accounts.) • Make captive all accounts that do not require a password. • Extend privileges to users carefully. • Protect your own files using all the techniques recommended in Section 4.8.4.8. • Ensure that the files containing components of the operating system are adequately protected (see Appendix B). • Use the AUTHORIZE qualifiers /NO INTERACTIVE and /NO BATCH when setting up proxy login accounts to permit only file access from other nodes. Interactive and batch logins are disabled for the account.
5-29 Managing the System and Its Data 5.7 Login Options
5.7 Login Options This section describes how you can control the display of various pieces of information that appear by default at login time, such as announcement, welcome, last login, and new mail messages. So that you can understand the effect of login restrictions, it also describes how the operating system processes the login fields of the system user authorization file {SYSUAF.DAT). In addition, this section describes the use of the secure server and how to set up break-in detection and evasion. 5.7.1 Controlling the Announcement Message To provide an announcement message on your system, define the system logical name SYS$ANNOUNCE in the site-specific startup command procedure SYS$MANAGER:SYSTARTUP_VMS.COM. The Open VMS System Manager's Manual describes how to do this. The announcement message appears at login. The definition you provide here affects all users on the system. Because this message may provide a clue to the identity of the operating system, you may decide not to display it. 5.7.2 Controlling the Welcome Message Similar to the announcement message, the welcome message is controlled through a system logical name, SYS$WELCOME. If you do not define SYS$WELCOME, a standard welcome message is provided for all users. This welcome message reveals the operating system and version number, as well as the node if SYS$NODE is defined. To define another message for SYS$WELCOME, you can create a text file containing the message. To display the contents of this file, use the following line in SYSTARTUP_VMS.COM:
$ DEFINE/SYSTEM SYS$WELCOME 11 @SYS$MANAGER:WELCOME.TXT 11 To disable the welcome message, place the following DCL command in SYS$MANAGER:SYSTARTUP_VMS.COM. This command prints a blank line in place of the standard welcome message.
$ DEFINE/SYSTEM SYS$WELCOME II II If you prefer to selectively disable the message for individual users, you can use the AUTHORIZE qualifier /FLAGS=DISWELCOME on individual UAF records. 5.7.3 Controlling the Last Login Messages By default, the system displays three messages that provide information about the last logins and the number of failed login attempts (see Section 3.4.2). You can selectively disable the appearance of these three messages. Enter the AUTHORIZE qualifier /FLAGS=DISREPORT for specific users. 5.7.4 Controlling New Mail Announcements By default, the system tells users the number of new mail messages when they log in. You can prevent users from receiving this notice by specifying the AUTHORIZE qualifier /FLAGS=DISNEWMAIL. The new mail announcement is primarily a user convenience, not a security issue. If a user with a restricted account cannot invoke the Mail utility (MAIL), then you might want to disable the new mail message at the same time you prohibit mail access.
5-30 Managing the System and Its Data 5.7 Login Options
The following AUTHORIZE qualifier accomplishes both tasks: /FLAGS=(DISMAIL,DISNEWMAIL) 5.7.5 Controlling Disconnected Processes Virtual terminals let users maintain more than one disconnected process at a time. You may want to restrict the use of virtual terminals. For example, if you are concerned about the amount of nonpaged pool, you may not want to enable this feature on a systemwide basis. Virtual terminals can be disabled at the terminal, user, or system level: • To prevent particular terminals from being used as virtual terminals, use the DCL command SET TERMINAUPERMANENT/NODISCONNECT. • To prevent specific users from attaching to disconnected processes, set the AUTHORIZE qualifier /FLAGS=DISRECONNECT for those users. (An applications account used by multiple users is a good candidate for the DISRECONNECT flag to prevent the users from connecting to each other's processes.) • To disable virtual terminals on a systemwide basis, remove the DISCONNECT attribute from the system parameter TTY_DEFCHAR2. You can also set the amount of time allowed for reconnection to less than the default of 15 minutes with the system parameter TTY_TIMEOUT. Limiting the connection time tends to minimize the number of users who receive messages, but it also affects the usefulness of the connection feature. 5.7.6 Controlling Failed Login Attempts You can control the number oflogin attempts the user is allowed through a dialup line. To implement control of retries, use two of the LGI system parameters: LGI_ RETRY_TMO and LGI_RETRY_LIM. (See the Open VMS System Management Utilities Reference Manual for more information on these parameters.) If you do not change the parameters, the default values allow the users three retries with a 20-second interval between each. This means that users lose the connection only if they fail to specify a valid password in three tries or if they spend more than 20 seconds between two of their tries. If the user makes a typing mistake after obtaining the connection, the user does not automatically lose the connection. This option is useful for authorized users, while still restricting the number of unauthorized attempts. Note that these values apply to every user on the system who is permitted to access the system through a dialup line. The following example illustrates the commands you would add to SYS$SYSTEM:MODPARAMS.DAT to set the total number of retry attempts to six, allowing a 30-second interval between tries. These parameters are dynamic. You can use the System Management utility (SYSMAN) to temporarily change and test the values before adding these commands to MODPARAMS.DAT and running AUTOGEN: LGI RETRY LIM = 6 ! Total number of retry attempts LGI-RETRY-TMO- - = 30 ! 30-second interval between tries
5-31 Managing the System and Its Data 5. 7 Login Options
5.7.7 Restricting Login Functions In addition to specifying hourly login restrictions or the number of retries on login, you can also assign function restrictions to an account by using appropriate keywords with the /FLAGS qualifier in AUTHORIZE. By default, there are no restrictions. Table 5-3 lists possible options.
Table 5-3 Restricting Accounts Keyword Meaning AUDIT Audit all security-relevant actions. AUTO LOGIN Prevent access except by automatic login when automatic logins are enabled. CAPTIVE Prevent user from changing any defaults at login (implies DEFCLI and DISCTLY keywords), and deny user access to the DCL command level. DEFCLI Prevent user from changing default CLI or CLI tables. DISCTLY Disable CtrlN interrupts. DISIMAGE Prevent user from using the RUN or MCR command or from executing "foreign" commands. DISFORCE_PWD_ Remove the requirement that a user change an expired CHANGE password at login. DISNEWMAIL Suppress "New Mail ... "announcements. DISPWDDIC Disable automatic screening of new passwords against a system dictionary. DISPWDHIS Disable automatic checking of new passwords against a list of the user's old passwords. DISREPORT Report login information (last login date, login failures, and so on). DISUSER Disable the account completely. DISWELCOME Suppress "Welcome to ... " login message. GENPWD Require user to use generated passwords. LOCKPWD Prevent user from changing password. DI SMAIL Prevent mail delivery to the user. PWD_EXPIRED Mark password as expired. PWD2_EXPIRED Mark second password as expired. RESTRICTED Prevent user from changing any defaults at login, and provide access to DCL only.
5.7.8 User Authorization File Login Checks To help you understand the effect of login restrictions, this section describes how the system checks the login fields of a UAF record when a user attempts to log in. A user activates a terminal either by turning it on and pressing Return if directly connected or by dialing in to a system and observing the remote connect protocol. When a user activates a terminal and that terminal is not allocated by a user process, the system prompts for a name and password. The person using the terminal must enter a name and password combination that exists in a UAF record, or the system denies further access.
5-32 Managing the System and Its Data 5.7 Login Options
If the name and password are accepted, the system then performs the following operations: 1. The system examines the login flags, beginning with DISUSER. If DISUSER is set, the login attempt fails. Note that setting this flag for powerful, infrequently used accounts (such as SYSTEM, SYSTEST, and FIELD) eliminates the risk of guessed passwords for those accounts. 2. If the DISUSER flag is not set, the system verifies primary or secondary day restrictions. After checking the current day type, the system determines if hourly login restrictions are in effect (as defined by the /ACCESS, /DIALUP, /INTERACTIVE, /LOCAL, and /REMOTE qualifiers). If the current hour is restricted, the login fails immediately. Otherwise it succeeds. 3. If the login is successful, the system passes control to the command interpreter (for example, DCL) named in the user's UAF record. 4. The system checks whether SYS$SYLOGIN is defined. If so, the logical name is translated (in most cases to SYS$MANAGER:SYLOGIN.COM) and that procedure executes. (If SYS$SYLOGIN is not defined, the system does not execute a system login command procedure.) When the procedure finishes, the system searches for the name of a login command procedure in that user's UAF record. If a command procedure is spe~ified in the LGICMD field and that procedure exists, it executes. Otherwise, if the LGICMD field is blank, the user's command file named LOGIN (located in the SYS$LOGIN directory) executes automatically (if it exists). The system does not execute both a command procedure specified in the LGICMD field and a user's LOGIN.COM file; if a procedure is specified in the LGICMD field, the system uses that procedure by default. You can, however, instruct the system to execute a user's LOGIN.COM file by calling it from within the procedure specified in LGICMD. After a successful login, the command interpreter prompts for user input, and the user responds with commands acceptable to the command interpreter. For example, DCL displays the system prompt (by default, the dollar sign prompt) and accepts the commands documented in the Open VMS DCL Dictionary. However, the system prohibits activities that violate the user's privilege allowance or that exceed resource quotas. 5.7.9 Controlling Break-In Detection and Evasion Section 5. 7 .6 shows how to control the number oflogin retries for users dialing in. By limiting the number of retries to a reasonable number on each dialup login, you make the job of dialing up and trying every password combination more difficult for probing outsiders. However, this is insufficient to completely evade break-ins. First, an obstacle like redialing is not going to prove an effective deterrent. Second, this technique applies only to dialups. Through the use of system parameters in the LGI category, the operating system offers additional methods for discouraging break-in attempts. The following list describes these methods: • LGI_BRK_LIM defines a threshold count for login failures. When the count of login failures exceeds the LGI_BRK_LIM value within a reasonable time interval, the system assumes a break-in is in progress. Only login failures caused by specifying invalid passwords are counted, and they must be from a specific source. That source can be any of the following combinations: - A specific terminal and a specific valid user name
5-33 Managing the System and Its Data 5. 7 Login Options
You can override this default to count failures by user name only with the LGI_BRK_TERM parameter, described below. Attempted logins using invalid user names never trigger break-in detection; however, they are counted together as a single class per terminal and are used to trigger security alarms. (See Chapter 6 for information about security alarms.) A specific remote node and a specific remote user name The user name of the creator of a detached process By default, LGI_BRK_LIM permits five failed login attempts from one of these sources. (Security administrators can adjust the value of LGI_BRK_ LIM with AUTOGEN.) • LGI_BRK_TERM controls the association of terminals and user names for counting failures. By default, the operating system sets this parameter to 1 so that they are tracked together. If you set this parameter to 0, the terminal is not included in the association; the failures associate on user name only. • LGI_BRK_TMO controls the time period in which login failures are detected and recorded. The initial failure on each source is given an expiration time that represents the current time plus the delta time given by LGI_BRK_TMO. Each additional failure on that source adds another delta of LGI_BRK_TMO to that entry, thus extending the length of time that break-in detection is in effect. The cumulative effect is that the more failures made by a source, the greater the window of time in which additional failures will count toward the critical number defined by LGI_BRK_LIM. If no more failures occur by the time the expiration point is reached, all failures are forgiven for that source. Note, however, that the failure count is not reset by a successful login. For example, assume the default values are in effect. LGI_BRK_LIM specifies no more than five login failures from one source. LGI_BRK_TMO is set for 5 minutes. Assume that an outsider starts sending user names and passwords to the system. When the first password fails, the clock starts to run and the user has four more tries during the next 5 minutes. When the second attempt fails about 30 seconds later, the user has three tries left that will be counted over the next 9.5 minutes. When the third attempt fails 30 seconds later, the login failure observation time extends to 14 minutes. The fourth failure occurs about 1 minute later; the fifth failure occurs within another 30 seconds. By this time, the observation time has reached 22.5 minutes. As a result, the next login failure from that source within 22.5 minutes triggers evasive action. The system tolerates an average rate of login failures that is the reciprocal of the parameter LGI_BRK_TMO. For example, if the default value of LGI_BRK_TMO (300 seconds, or 5 minutes) is in effect, the average rate of tolerable login failures is one every 5 minutes. When the rate of login failures exceeds the tolerable rate, and the critical number of five failures is reached (the default value of LGI_BRK_LIM), the system concludes a break-in is in progress and initiates evasive action. The system stops accepting logins from the offending source for a period of time. When the source is a terminal (when LGI_BRK_TERM equals 1), for a period of time no one can log in from that terminal with the user name that is under suspicion. (However, other users may log in from that terminal.) A remote user triggering break-in evasion is prohibited from logging in from that node for a period of time. Consequently, login attempts that provide valid user name and password combinations that should otherwise succeed are rejected during this interval, but only from the presumed intruder at that
5-34 Managing the System and Its Data 5. 7 Login Options
source. Once the interval elapses, operations return to normal. As a result of this form of evasive action, outsiders are less likely to learn the correct password by using repetitive login attempts. • LGI_HID_TIM controls the duration of the evasive action. The length of time depends on an additional random number (in the range of 1 to 1.5) used as a multiplier. The product of LGI_HID_TIM and the random number yields the actual duration of evasive action. The formula is represented as follows: Evasion time = LGl_HID_TIM * (random number) The inclusion of a random amount of time helps obscure the true evasion time. An outsider who learned the value of LGI_HID_TIM could not be assured that the evasive action would persist for exactly that length of time. If the values of LGI_BRK_LIM and LGI_BRK_TMO can be learned or guessed, the outsider can attempt a system break-in over sufficiently long intervals that suspicion is not triggered. The outsider can also change terminals, nodes, and user names frequently enough to avoid detection. Do not rely on these break-in techniques as the sole means of security on your system. The technique of counting failures per terminal and user name raises the potential for break-in because the password guess rate for a particular user name is multiplied by the number of available terminals. Each terminal is counted as a separate source for break-in detection. The benefit of this approach, however, is that it sharply reduces the denial of service problem that could result from simply counting failures per terminal or per user name. A malicious user could disable an entire terminal room or user's account for a period of time if failures are counted for each user name alone. By setting LGI_BRK_TERM to 0, you can detect attempts more quickly, at the expense of increasing the risk of denial of service to legitimate users. • LGI_BRK_DISUSER makes the effects of break-in detection more severe. If you set this parameter to 1, the operating system sets the DISUSER flag in the UAF record for the account where the break-in was attempted. Thus, that user name is disabled until you manually intervene. However, the service denial effects of this option can be very severe. A malicious user can put all known accounts, including yours, out of service in a short time. To recover, you must log in on the system console where the SYSTEM account is always allowed to log in. The parameters LGI_BRK_LIM, LGI_BRK_TERM, LGI_BRK_TMO, and LGI_ HID_TIM affect all terminals, users, and nodes that access the system. Because they are dynamic, you can reset them without rebooting the system. The operating system stores information about login failures that originate from a specific source in the break-in database. Use the DCL command SHOW INTRUSION to display the contents of the break-in database, as shown in the following command: $ SHOW INTRUSION Intrusion Type Count Expiration Source NETWORK INTRUDER 6 12:27:26.08 BOSTON::JWILLIAMS TERM USER SUSPECT 3 12:42:09.11 AV34C2/LC-2-10:FORGETFUL
5-35 Managing the System and Its Data 5. 7 Login Options
Each entry contains the following type of information:
Field Description Intrusion Class of intrusion: network, terminal, term_user, username. Type Severity of intrusion as defined by the threshold count for login failures. The system parameter LGI_BRK_LIM defines the threshold count. Count Number of login failures associated with a particular source. Expiration Absolute time when the system stops keeping track of login failure. The system parameter LGI_BRK_TMO controls this time. Source Origin of the login failure.
The information in the break-in database is controlled by the system parameters in the LGI category. Use the DELETE/INTRUSION_RECORD command to remove entries from the break-in database. For example: $ DELETE/INTRUSION_RECORD BOSTON::JWILLIAMS If the source of the break-in is a device that is named in a syntax that conflicts with OpenVMS naming conventions or is case sensitive, you must enclose the name within quotation marks to delete the record from the break-in database. For example, the following command deletes a record generated by a terminal connected to a terminal server: $ DELETE/INTRUSION_RECORD "AV34C2/LC-2-10:FORGETFUL" See the Open VMS DCL Dictionary for additional information about the SHOW INTRUSION and DELETE/INTRUSION_RECORD commands. 5.7.10 Using the Secure Server Section 3.8 describes password grabbers as a class of programs designed to steal passwords from unsuspecting users who log in to terminals left on. The operating system provides a secure terminal server that stops any currently executing process before the start of a login at that terminal. Invoke the secure server separately for each terminal with the following DCL command: SET TERMINAUPERMANENT/SECURE/DISCONNECT term-id The user must then press the Break key followed by the Return key to start a login. The login proceeds as usual. If you apply the secure server to all terminals, you can make the login procedure consistent throughout the site by putting the SET TERMINAL commands in the site-specific startup command procedure. However, certain applications that may use the terminal as a communications line may need to use the Break key for their own purposes, which would be incompatible with the secure terminal server. The secure terminal server feature is also incompatible with autobaud handling. However, because autobaud handling is necessary only on modem terminals (switched or dialup terminals), the modem handling on such terminals performs
5-36 Managing the System and Its Data 5. 7 Login Options
the equivalent of secure server functions. For secure operation, set up the terminal characteristics as follows: ° For local terminals (direct-wired), use the following SET TERMINAL qualifiers: /NOMODEM/SECURE/DISCONNECT/NOAUTOBAUD • For switched terminals (data-switch and dialup), use the following SET TERMINAL qualifiers: /MODEM/AUTOBAUD/NOSECURE/DISCONNECT Specify the /DIALUP qualifier if the terminal port is accessible through a telephone line or the equivalent, regardless of the path (direct modem, data switch, concentrator, or public data network). Always specify the /DISCONNECT qualifier to guard against password grabbers. To prevent disconnected jobs from filling up your system, set the system parameter TTY_TIMEOUT to a low timeout value, which determines when disconnected processes are deleted. If you decide to apply the secure server to individual terminals, include directly wired terminals located in public areas or remote, unsecured areas. Terminals never used for local or dialup logins are not subject to this security problem. Terminals closely supervised during logins may also not require this measure. 5.8 Using the Automatic Login Facility (ALF) You can assign accounts to particular terminals to enable an automatic login feature. This feature permits users to log in without specifying a user name. The operating system associates the user name with the terminal (or terminal server port) and maintains these assignments in the file SYS$SYSTEM:SYSALF.DAT, referred to as the automatic login file or the ALF file. Maintain this file with the System Management utility (SYSMAN) commands ALF ADD, ALF REMOVE, and ALF SHOW. The ALF file consists of one record for each terminal on which automatic logins are enabled. Each record consists of two fields: the device name or terminal server port name of the terminal, followed by the user name of an account. The device names must be unique within the file. However, the same user name can occur in any number of records; that is, one account can be automatically logged in to an unlimited number of terminals. The ALF file is an indexed file that does not need to be purged, but it should be backed up after a modification. Use SYSMAN to add, remove, or display records in the ALF file. Invoke SYSMAN with the following commands: $ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET PROFILE/PRIVILEGES=SYSPRV The following sections describe the SYSMAN commands you can use to maintain the ALF file.
5-37 Managing the System and Its Data 5.8 Using the Automatic Login Facility {ALF)
5.8.1 Adding New Records Specify the following format of the SYSMAN ALF ADD command to add a terminal/user name association in the ALF file: ALF ADD device-name user-name For example, the following command assigns the terminal TTA5 to user RENOLDS: SYSMAN> ALF ADD TTAS RENOLDS If you enter an invalid terminal name, you receive an error message and are prompted again. The user name is not checked for validity. If a terminal is connected to a terminal server, you must include the port name and the /PORT qualifier with the ALF ADD command, as shown in the following example: SYSMAN> ALF ADD /PORT "MN34C3/LC-l-2" RENOLDS You can include the /LOG qualifier to echo the device name and terminal name added to the ALF database. 5.8.2 Deleting Records Specify the following format of the SYSMAN ALF REMOVE command to remove a terminal/user name association in the ALF file: ALF REMOVE device-name For example, the following command removes the record in the ALF file for terminal TTA3: SYSMAN> ALF REMOVE TTA3 The /USERNAME qualifier allows you to remove records in the ALF file by user name rather than by terminal (or port) name. For example, the following command removes all records assigned to user Douglas: SYSMAN> ALF REMOVE /USERNAME=DOUGLAS You can use wildcard characters with the /USERNAME qualifier. 5.8.3 Displaying Records Use the SYSMAN ALF SHOW command to display one or more records in the ALF database, as shown in the following example: SYSMAN> ALF SHOW TTAS The command in this example displays the user name in the ALF database associated with the terminal TTA5. You can also display records in· the ALF database based on user name by specifying the /USERNAME qualifier, as shown in the following example: SYSMAN> ALF SHOW /USERNAME=PONTRE The command in this example displays all records in the ALF database associated with user Pontre. You can specify wildcard characters in the terminal name or port name.
5-38 Managing the System and Its Data 5.8 Using the Automatic Login Facility (ALF)
Specify the /OUTPUT qualifier to direct the output from an ALF SHOW command to a file, as shown in the following command: SYSMAN> ALF SHOW /OUTPUT=SYSMAN 123189.LIS If you do not include a file specification with the /OUTPUT qualifier, SYSMAN writes the output to the file SYSMAN .LIS in your default directory. 5.8.4 Restricting ALF Users To force individuals at specific terminals to log in to an application program, create a separate, captive account for the application. Then set up automatic logins to the new account for the desired users. 5.8.5 Logging In to an Automatic Login Terminal Once you set up a terminal for automatic login, it can be used only for the designated account. This is most useful for applications terminals used by persons who may be unfamiliar with computers. Thus, an automatic login account will very likely also be a captive account. The automatic login feature suppresses the user name prompt. All other login features (system password, primary and secondary passwords, and messages) function normally, if enabled. Passwords are optional. If you want the account to be open to all users where the terminals are located, eliminate the password. When no password is required, the user has no data to enter at login. The operating system logs the terminal in automatically in response to the Break key or the Return key and immediately enters the application if the account is under the control of a captive login command procedure. 5.8.6 Protecting Automatic Login Accounts Automatic login accounts are potentially accessible from terminals and sources other than the terminals listed in the ALF file and, therefore, require protection, especially if they have no password. Use the following precautions: • Restrict network and dialup access, as appropriate, with the AUTHORIZE qualifiers /NODIALUP, /NONETWORK, and /NOREMOTE. • Set the AUTOLOGIN flag in the account's UAF record. This flag makes the account available only by autologin, batch, and network proxy.
5.9 Protecting System Programs and Databases This section discusses: • Augmenting the protection on system files (Section 5.9.1) • Precautions to take when installing new software (Section 5.9.2) • Encrypting files (Section 5.9.3) • Restricting command outputs (Section 5.9.4) See Chapter 10 for a description of protected subsystems.
5-39 Managing the System and Its Data 5.9 Protecting System Programs and Databases
5.9.1 Augmenting Protection on System Files Even on the most open system, you will want protection for the system software. Normally, Digital delivers system programs and databases with adequate UIC protection. However, if for any reason you are dissatisfied with the default protection, you can change it with the techniques outlined in Chapter 4, provided you have the necessary SYSPRV privilege. You might also add an ACL to any file that you decide needs additional protection. Appendix B presents the recommended protection codes for system files in four directories: the common system directory [VMS$COMMONJ, the system executables directory [SYSEXEJ, the system library [SYSLIB], and the system manager directory [SYSMGR]. Your OpenVMS software should have this set of protection codes following a correct installation. You can obtain a full listing of system files from the system manager's account during an OpenVMS installation with the following DCL command: $ DIRECTORY/SECURITY/OUTPUT=SYSTEM_FILES.LIS SYS$SYSROOT:[* ••• ] Digital recommends you generate such a listing and store it for reference. Regularly compare these values with current system file protection to ensure that no tampering has occurred. (The DCL commands DIRECTORY/SECURITY /OUTPUT and DIFFERENCES facilitate such checks.) Table 5-4 provides a summary of DCL commands you use to set up and display file protection; these commands are described in the Open VMS DCL Dictionary.
Table 5-4 DCL Commands Used to Protect Files Command Function DIRECTORY/ACL Displays the ACL for the file DIRECTORY/OWNER Displays the file owner's UIC DIRECTORY/PROTECTION Displays the file's protection code DIRECTORY/SECURITY Combines and displays file information produced by DIRECTORY/ACL, DIRECTORY/OWNER, and DIRECTORY/PROTECTION EDIT/ACL Invokes the access control list editor (ACL editor) SET PROTECTION/DEFAULT Establishes the default protection to be applied to all files subsequently created SET SECURITY Modifies the security profile of any object: the owner, protection code, and ACL SHOW SECURITY Displays the ownership, UIC protection code, and ACL of a protected object
As indicated, Digital provides default protection for the system programs that it provides. However, if you have a special requirement, you might examine the potential of ACLs for your needs. For example, you might use ACLs to restrict the use of system programs such as compilers. (Any number of considerations might prompt this action, ranging from performance to licensing issues.) You might also ask if there are cases where you do not want some or all of your users to be able to initialize media. If there are, you can put an ACL to good use on the system program SYS$SYSTEM:INIT.EXE. Ensure that you grant no access to the world category in the DIC-based protection code. Then create an ACL for the file that grants access to specific users.
5-40 Managing the System and Its Data 5.9 Protecting System Programs and Databases
Similarly, if a department in your company has paid for a license to a software product, you may want to make that software available to them, but not to others. Ensure that the world category receives no access through the standard UIC-based protection code, and create an entry in the ACL for that file that allows access through the department's identifier. You may also find that ACL protection is relevant to protect your applications databases, limiting the access to certain users or to protected subsystems. 5.9.2 Precautions to Take when Installing New Software When you install new software, you must address several security concerns. You want to ensure that you are not admitting software that will in any way corrupt or undermine your usual security precautions. You must also consider whether to install the software with any privileges. When you install privileged software, you allow users to execute it whether or not they personally possess the required privilege. In effect, you extend the privilege to the process while it runs the software. While this offers some advantages, it also introduces several security-related dangers. This section discusses the security aspects of installing new software. 5.9.2.1 Protecting Programs and Directories New software can contain programs that are potentially harmful to your system. These programs, called Trojan horse programs, are designed to do damage and frequently include features that do the following: • Pass privileges of the person running the program back to the author of the program • Allow unauthorized access to the system • Change protection of system files • Patch the system (add special software to the operating system) • Create jobs that scan for easily guessed passwords To protect your system from this type of break-in, always buy software from reputable sources. When training new users, stress the importance of avoiding use of software from an unknown source. Another risk to programs and directories is known as the worm. While Trojan horse software must rely on the innocent user to unwittingly accept the damaging software by using it, the worm requires no user cooperation. It is a program that takes advantage of faulty file protection, working its way through your system and modifying command procedures and executable programs. By modifying command procedures, it can propagate by making use of user access rights and privileges. The user's login command procedure is a prime target for this type of security breach. Login command procedures generally contain easily modified DCL commands and are executed regularly. ACLs are also targets. File protection designed with users sharing access privileges allows this type of program to run through many users' programs, acquiring new privileges along the way.
5-41 Managing the System and Its Data 5.9 Protecting System Programs and Databases
Well-designed file protection is critical for protection from this type of security breach. Make sure that likely targets cannot be modified by users. For example, set up file protection so that your login command procedure permits only read access to all other users. Also make sure the directory containing the login command procedure permits write access only to users in the system and owner categories. Because most damage occurs when programs like these reach a target account with privileges, users with privileges should be especially cautious with the protection of their root directory, executable files, and command procedures. To deter Trojan horse attacks, users should never execute a command procedure or run an image in a privileged account without inspecting the command procedure or the image's sources. Application images should be rebuilt from source to ensure that the binary image reflects the accompanying source.
5.9.2.2 Installing Programs with Privilege Some software requires privilege to run. You can extend the privilege to all users you expect will need to run the software, or you can install the program with the required privileges. Section 5.11 describes these options in greater detail. 5.9.3 Encrypting Files File encryption refers to the process of applying an algorithm to data to conceal its content. Decryption reverses the operation and converts encoded information back to its original content. If you need to copy proprietary software onto media for removal to another site, you might use file encryption. The software on the media is useless without the correct decryption code. To perform these tasks, there is a software facility available to users as an optional layered product. Consult the VAX Encryption Reference Manual for more information. · 5.9.4 Restricting Command Outputs Some DCL commands behave differently depending on the privileges that the user holds. For example, unless a user holds the GROUP or WORLD privilege, the SHOW PROCESS command limits the display of process information to the user's process. A user with GROUP privilege can display other processes in the user's UIC group; a user with WORLD privilege can display any process on the system. 5.10 Authorizing Usage As you authorize users, consider what restrictions to apply to provide additional control over their use of the system. You can restrict users to certain devices, commands, privileges, short account durations, working times, and modes of operation (batch, dialup, remote, network, local, or interactive). 5.10.1 Restricting Devices There are a number of ways to restrict the devices available to users. You may want to limit use to particular devices, or you may want to limit the amount of usage. The next sections describe the controls available for restricting the use of terminals, disk volumes, applications terminals, and miscellaneous devices.
5-42 Managing the System and Its Data 5.1 O Authorizing Usage
5.10.1.1 Restricting Disk Volumes Identify the user's default device and directory in the UAF record with the AUTHORIZE qualifiers /DEVICE and /DIRECTORY. You can limit the number of blocks available to the user on that disk (and any other disk) through the disk quota feature or the System Management utility (SYSMAN), as described in the Open VMS System Management Utilities Reference Manual. The volume protection in place on other disks controls how much access a user can obtain to the disks. The user's privileges, which can be extended or limited through the AUTHORIZE qualifier /PRIVILEGES, also influence the access available (see Section 5.11). 5.10.1.2 Restricting Terminal Use Through the device object class template TERMINAL, the operating system sets up terminals to be accessible to the SYSTEM account only. When a user logs in, the operating system transfers ownership from a system UIC to the UIC of the current process. You can limit logins on specific terminals in the following ways: • Assign a system password. • Set the terminal to /NOTYPE_AHEAD, making it impossible to log in. The application of system passwords limits the use of those terminals to users who know the system password.
5.10.1.3 Restricting Applications Terminals and Miscellaneous Devices To make terminals accessible to certain users as applications terminals, you may want to change any or all of the device's security characteristics. You can include the DCL command SET SECURITY/CLASS=DEVICE for specific terminals (with appropriate protection codes) in the command procedure SYS$MANAGER:SYSTARTUP_VMS.COM. This DCL command can limit access to any device that is not file structured. You might also place an ACL on the device to limit user access. 5.10.2 Restricting Work Times AUTHORIZE qualifiers let you restrict system use to certain periods of the day. Restricting work times is useful to better balance the workload on your system. Define primary and secondary days of the week with the /PRIMEDAYS qualifier, or conform to the default where primary days are Monday through Friday and secondary days are Saturday and Sunday. For example, if a user works Tuesday through Saturday, you would specify the /PRIMEDAYS qualifier as follows: /PRIMEDAYS=(NOMON,TUES,WED,THUR,FRI,SAT,NOSUN) Occasionally an operational change occurs that conflicts with the normal day assignments at your site, such as a holiday falling on a primary day. To override the normal day assignment, use the DCL command SET DAY, and specify the day-type interpretation you want for the current day. This requires OPER privilege. Note that this change applies to all logged-in users, as well as those who will log in during the day. Users who are currently logged in who are unauthorized for logins for the day-type once it changes will be logged out of the system at the next hour. (The job controller enforces time restrictions on an hourly basis.)
5-43 Managing the System and Its Data 5.1 O Authorizing Usage
Decide which types of login access should be restricted to certain hours. The login access qualifiers are: /LOCAL, /REMOTE, /DIALUP, /INTERACTIVE, /BATCH, and /NETWORK. However, if your site applies one set of primary and secondary hours for all types of logins, you can specify the /ACCESS qualifier, which applies to all modes of access. The following example shows how to apply the /BATCH qualifier to a user's account to disable the user from running batch jobs during normal working hours:
/NOBATCH=(PRIMARY, 9-17) This specification permits the user to run batch jobs only during the hours of 6:00 p.m. through 8:59 a.m. on primary days but all day on secondary days. 5.10.3 Restricting Mode of Operation The following concerns might cause you to prohibit network access for some of your users: • The user has data that should be accessed only through the local node. • Penetration attempts are more likely to occur over a network because of the increased anonymity of the connection. (This concern is also relevant to dialup connections.) Use the AUTHORIZE qualifier /NONETWORK to prevent specific users from having network access, as shown in the following example:
UAF> ADD JSMITH /NONETWORK, • • • Any of the AUTHORIZE access mode qualifiers (/LOCAL, /REMOTE, /DIAL UP, /INTERACTIVE, /BATCH, or /NETWORK) can be negated in this manner to restrict access to the system. 5.10.4 Restricting DCL Command Usage There are several ways that you can affect the use of DCL commands by your users. Among them are the following: • Impose ACLs on the system program files in the directories SYS$SYSROOT:[SYSEXE] and SYS$SYSROOT:[SYSLIB]. • Remove or modify DCL command definitions, and rebuild the DCL tables. (The Open VMS System Management Utilities Reference Manual describes how to create command definitions.) Use the /CLITABLES qualifier in the user's UAF record to specify the modified tables. Also specify /FLAGS=DEFCLI to ensure that the user can log in only with the specified command language interpreter (CLI) and tables. Protect the original DCL tables from unauthorized access by imposing ACLs on the system program files in the directories SYS$SYSROOT:[SYSEXE] and SYS$SYSROOT:[SYSLIB]. In particular, protect SYS$LIBRARY:DCLTABLES.EXE and SYS$SYSTEM:CDU.EXE.
5-44 Managing the System and Its Data 5.1 O Authorizing Usage
5.10.5 Restricting Account Duration It is good practice to set an account expiration time that matches the maximum length of time you expect the user to require access. When the expiration time arrives, the system automatically prohibits access to the account. You must still remove the UAF record and delete the user's files. To set the account expiration time, use the AUTHORIZE qualifier /EXPIRATION in the user's UAF record. For example, the following qualifier specifies that the user's account will expire on the 30th of December 1993: /EXPIRATION=30-DEC-1993 You may want to severely restrict the use of certain accounts. For example, you may want to disable specific accounts used only periodically, such as the SYSTEST and FIELD accounts, to limit possible misuse of these accounts. Disable the accounts with the /FLAGS=DISUSER qualifier. Temporarily enable the accounts with the /FLAGS=NODISUSER qualifier when needed. 5.11 Granting User Privileges Some system activities are limited to users who hold specific privileges. These restrictions protect the integrity of the operating system's performance and, thus, the integrity of service provided to users. Grant privileges to each user on the basis of two factors: ( a) whether the user has a legitimate need for the privilege and ( b ) whether the user has the skill and experience to use the privilege without . disrupting the system. Privileges are divided into the following seven categories according to the damage that the user possessing them could cause the system: • None-No privileges • Normal-Minimum privileges to effectively use the system • Group-Potential to interfere with members of the same group • Devour-Potential to consume noncritical systemwide resources • System-Potential to interfere with normal system operation • Objects-Potential to compromise object security • All-Potential to control the system A user cannot execute an image that requires a privilege the user does not possess unless the image is installed as a known image with the privilege in question. (See the Open VMS System Management Utilities Reference Manual for instructions on installing known images.) Execution of a known image with privileges grants those privileges to the user process executing the image for the duration of the image's execution. Thus, you should install user images with amplified privileges only after ensuring that the user needs the access and is unlikely to misuse it. A user's privileges are recorded in the user's UAF record in two privilege vectors. One vector stores the authorized privileges, and the other vector stores the default privileges. The default privileges are the subset of authorized privileges that a user process receives at login.
5-45 Managing the System and Its Data 5.11 Granting User Privileges
When a user logs in to the system, the user's privilege vector is stored in the header of the user's process. In this way, the user's privileges are passed on to the process created for the user. Users can use the DCL command SET PROCESS/PRIVILEGES to enable and disable privileges for which they are authorized. The operating system monitors and audits the use of privilege. You can enable auditing for specific privileges and examine the audit log file to see what privileges were used to execute DCL commands or system services. See Chapter 6 for further informatiOn. Rather than grant privilege to system users, you may sometimes set up protected subsystems to satisfy computing requirements. See Chapter 10 for details. Table 5-5 categorizes the privileges and includes a brief definition of the powers associated with each privilege.
Table 5-5 OpenVMS Privileges Category Privilege Activity Permitted None None Denied activities requiring privileges Normal NETMBX Create network connections TMPMBX Create temporary mailbox Group GROUP Control processes in the same group GRPPRV Gain access through object's system protection field Devour ACNT Disable accounting ALLSPOOL Allocate spooled devices BUGCHK Make bugcheck error log entries EXQUOTA Exceed disk quotas GRPNAM Insert group logical names in the name table PRMCEB Create/delete permanent common event flag clusters PRMGBL Create permanent global sections PRMMBX Create permanent mailboxes SHMEM Create/delete structures in shared memory System ALTPRI Set base priority higher than allotment AUDIT Generate audit records OPER Perform operator functions PSWAPM Change process swap mode WORLD Control any process SECURITY Perform security-related functions SYSLCK Lock systemwide resources
Objects DIAGNOSE Diagnose devices IMPORT Mount a nonlabeled tape volume MOUNT Execute mount volume QIO READ ALL Possess read access to all system objects SYSGBL Create systemwide global sections VOLPRO Override volume protection (continued on next page)
5-46 Managing the System and Its Data 5.11 Granting User Privileges
Table 5-5 (Cont.) OpenVMS Privileges Category Privilege Activity Permitted
All BYPASS Disregard protection CMEXEC Change to executive mode CMKRNL Change to kernel mode DETACH Create detached processes of arbitrary UIC DOWNGRADE Write to a lower secrecy object or lower an object's classification LOG_IO Issue logical I/O requests PFNMAP Map to specific physical pages PHY_IO Issue physical I/O requests SETPRV Enable any privilege SHARE Access devices allocated to other users SYS NAM Insert system logical names in the name table SYSPRV Access objects through the system protection field UPGRADE Write to a higher integrity object or raise an object's integrity level
5.11.1 Limiting User Privileges Granting privileges allows users those privileges until you remove them. To avoid such blanket permission, you may want to grant privileges on an as-needed basis. For example, certain users may need to run a program requiring any of the more powerful privileges. You can install the program with the necessary privilege by using the Install utility (INSTALL). Then put an ACL on the executable image file to clearly specify users allowed to execute it. The users would effectively possess the privilege only when they are actually executing the image. When the image stops running, the user no longer holds the privilege. Use caution when installing images with privileges. Images installed with privileges can cause damage because the privileges are always enabled. Following is an example of installing an image with privilege. The System Dump Analyzer utility (SDA) requires CMKRNL privilege to analyze the running system. 1. Install SDA.EXE with the CMKRNL privilege, as follows: $ INSTALL SDA.EXE /PRIVILEGED=CMKRNL 2. Place an ACL on SDA.EXE, and also set the VIC-based protection to deny all access to the world category of users, as follows: $ SET SECURITY/ACL=(IDENTIFIER=SDA,ACCESS=EXECUTE) $ SYS$SYSTEM:SDA.EXE $ SET SECURITY/PROTECTION=(WORLD) SYS$SYSTEM:SDA.EXE 3. Use the AUTHORIZE command to confirm that the users who hold the SDA identifier are those intended to run the program. If necessary, make adjustments to this list of users. Digital ensures that all system programs that are supplied with the operating system (such as the SDA) are linked with the /NOTRACEBACK qualifier to prevent online debugging or traceback.
Note ------ All images that you install with privilege must be linked with the /NOTRACEBACK qualifier to prevent online debugging and traceback.
5-47 Managing the System and Its Data 5.11 Granting User Privileges
An alternative to granting blanket privileges is to set up emergency or specialized privileged accounts. Users would log in to these privileged accounts only to perform specific functions. You have two options with this technique. • Establish a limited group who know about the account and are informed how to use it. • Create two accounts for the user, giving the privileges to one account but not to the other. In this case, the user would have the same UIC and the same default directory in each account. (This is the only case where Digital recommends shared UICs, because there is still only one actual user.) If you decide to adopt this dual account practice, avoid obvious user names that reveal which account is the privileged account. With both options, you can place special restrictions on the privileged account, such as long passwords, brief password lifetimes, restricted hours, and limited modes of operation (no dialup, network, remote, or batch logins). In addition, limited account durations would force frequent consideration of privilege requirements. Yet another alternative is to use protected subsystems, which are described in Chapter 10, and thereby eliminate the need for any system privileges. 5.11.2 Suggested Privilege Allocations Appendix A lists all user privileges and includes recommendations on when to grant them. When allocating user privileges, be conservative, and consult Table 5-5 for guidance. The summary guidelines in Table 5-6 indicate the minimum privilege requirements for common classes of system users.
Table 5-6 Minimum Privileges for System Users Type of User Minimum Privileges General TMPMBX,NETMBX Operator OPER Group manager GROUP,GRPPRV System manager/administrator SYSPRV Security administrator SECURITY, SYSPRV
5.11.3 Controlling Privileged Accounts Because abuse of privileged accounts can result in serious losses, consider imposing special controls on accounts with the most powerful privileges (except the SYSTEM account supplied with the operating system), as follows: • Limit access to the account. For example, you can prohibit dialup or network access with the /NODIALUP or /NONETWORK qualifier to discourage outsiders from attempting break-ins from remote locations. • Use the /PRIMEDAYS and /NOACCESS qualifiers to restrict the time of day or days of the week that logins can be performed. Select periods of time that can be monitored for appropriate use. • Disable the account when not in use with the AUTHORIZE qualifier /FLAGS=DISUSER.
5-48 Managing the System and Its Data 5.11 Granting User Privileges
• Use a captive login command procedure for additional validation. Captive login command procedures are described in Section 5.13.1. • Impose security alarms to detect use of the privileges pertaining to file protection: BYPASS, SYSPRV, READALL, and GRPPRV. For information about setting up and monitoring security alarms, see Chapter 6. Naturally, you also need to set controls on the SYSTEM account. The most secure practice is to disable it for all but batch access and perform system management through individual privileged user accounts, which provide accountability. 5.11.4 Special-Purpose Privileged Captive Accounts Although generally unadvisable, it is sometimes necessary to grant privileges to captive accounts rather than to give users access to unrestricted, privileged accounts. For example, users who perform backup operations require the READALL privilege. By making the account that performs backups captive, you can ensure that the procedures are carried out according to your system's backup policy. See Section 5.13 for guidelines for setting up captive accounts. 5.12 Examples of Establishing User Accounts This section illustrates the creation of three user accounts with options ranging from least to most restrictive. Chapter 9 includes a similar example that illustrates a number of principles involved in designing and implementing proxy login accounts. See Section 5.13 for a discussion of accounts that provide more limited access to the system and its resources. • The first user account (Example 5-1) represents highly privileged users, such as system managers, with minimum restrictions and maximum access to the system. • The second user account (Example 5-2) illustrates an interactive user account with moderate restrictions, typical of an account at a commercial site where security is a concern and the average user has limited access. • The third user account (Example 5-3) depicts an applications production account where the user is highly restricted. In all the following examples, any value not specified defaults to the value provided by the default record in SYSUAF.DAT. 5.12.1 System Manager's Account Example 5-1 illustrates a number of AUTHORIZE qualifiers appropriate for a system manager's account. Notice the following: 0 The requirement that the automatic password generator be used to change passwords. @ The use of a short password lifetime. Measures 1 and 2 are important to protect the account because it affords many valuable privileges and access rights. 0 The use of SYSPRV. With this privilege, the user has the power to access protected objects by the system protection field and to change the owner UIC and protection. The user can change an object's protection to gain access to it.
5-49 Managing the System and Its Data 5.12 Examples of Establishing User Accounts
Example 5-1 Sample Security/System Manager's Account $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD RIRONWOOD/PASSWORD=VALTERSY/UIC=[OOl,100] - UAF> /DEVICE=SYS$SYSDEVICE/DIRECTORY=[RIRONWOOD] - -UAF> /OWNER="Russ Ironwood"/ACCOUNT=SECURITY/FLAGS=GENPWD - 0 -UAF> /PWDLIFETIME=30-/PWDMINIMUM=8 - f) -UAF> /PRIVILEGES=SYSPRV 6) Identifier for value:[OOOOOl,000100] added to RIGHTSLIST.DAT UAF>
5.12.2 Interactive User's Account Example 5-2 illustrates the creation of an account of a typical interactive user. Notice the following: 0 Only one password is required. f) The password has a minimum length of 6 characters. 6) The user's password is valid for 90 days, a much longer lifetime than the manager's password shown in Example 5-1. 0 The user is allowed access during the week and on Saturdays. 0 During those six days, the user has access during a 15-hour period.
Example 5-2 Typical Interactive User Account $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD RDOGWOOD /PASSWORD=TRALAYAM/UIC=[231,010] - 0 UAF> /DEVICE=BOTANYDEV/DIRECTORY=[RDOGWOOD] - -UAF> /OWNER="Robert Dogwood"/ACCOUNT=BOTNYDPT - -UAF> /FLAGS=(GENPWD)/PWDMINIMUM=6 - f) -UAF> /EXPIRATION=l5-JUNE-1991/PWDLIFETIME=90- 6) =UAF> /PRIMEDAYS=(MON,TUES,WED,THURS,FRI,SAT,NOSUN) - 0 UAF> /NOACCESS=(PRIMARY,23-6,SECONDARY)/NODIALUP 0 Identifier for value:[000231,000010] added to RIGHTSLIST.DAT UAF>
5.12.3 Production Account Example 5-3 illustrates the creation of a production account. This account is designed to perform one function: to list the grades at State University and to produce mailings to each student's home. Notice the following: 0 This job can be run only from the captive account REPGRADES. f) The user who initiates the login must specify the password, GROBWACH. (Most likely only the security administrator will change the password.) 6) When the job is run through a local login, it is restricted to the hours of 8 a.m. through 5:59 p.m., Monday through Friday. (Notice that only batch and local logins are allowed, and batch mode does not have time restrictions.) 0 The job may not be run over dialup lines or as a remote job. The account also denies network access.
5-50 Managing the System and Its Data 5.12 Examples of Establishing User Accounts
0 The process runs under the control of a special login command procedure (GRADES.COM), which presumably provides the operator with a menu of functions. 0 The process is restricted to the commands defined in the CLI table, GRADES_ TABLES.
Example 5-3 Production Account $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD REPGRADES /DEVICE=ADMINDEV/DIRECTORY=[REPGRADES] - UAF> /FLAGS=(CAPTIVE,DISWELCOME,DISNEWMAIL,DISMAIL,DEFCLI) - ~ -UAF> /PASSWORD=GROBWACH/UIC=[777,031] - f} =UAF> /OWNER="Campus Admin"/ACCOUNT=ADMIN - UAF> /LOCAL=(PRIMARY, 8-17)/PRIMEDAYS=(MON,TUES,WED,THU, - =UAF> FRI,NOSAT,NOSUN) - 6)
UAF> /NONETWORK/NOREMOTE/NODIALUP - ~ UAF> /LGICMD=GRADES 0 /CLITABLES=GRADES TABLES - 0
user record successfully added identifier for value:[000777,000031] added to RIGHTSLIST.DAT
5.13 Using Limited-Access Accounts to Create a Restricted Environment Limited access accounts provide controlled login to the system and, in some cases, controlled access to user software. Limited-access accounts ensure that the system login command procedure and the process login command procedure, as well as any command procedures they call, are executed. There are four types of limited accounts: captive, restricted, guest, and proxy. • Captive accounts limit the functions available to users. They are appropriate for the following types of situations: Permitting unskilled or semiskilled users to perform routine computer tasks Running batch operations during unsupervised periods Running applications programs with information that you want to keep private • Restricted accounts provide a special environment for a user. They are appropriate for the following things: Network objects like MAIL Network proxy accounts User authentication systems like smart cards Accounts created as part of a layered product installation (such as the NOTES$SERVER account created during the installation of VAX Notes)
5-51 Managing the System and Its Data 5.13 Using Limited-Access Accounts to Create a Restricted Environment
• Guest accounts are a form of captive or restricted account that allow multiple remote users access to resources on your system through a common account. Digital does not recommend the practice of setting up guest accounts. • Proxy accounts are a form of restricted account. DECwindows software does not currently support captive or restricted logins in the traditional sense. Once a user is logged in and creates a DECterm window, however, the traditional environment of a captive or restricted account applies. 5.13.1 Captive Accounts A captive account limits the activities of the user and, when properly administered, denies the user access to the DCL command level. You can set up the account to limit the user to running under the complete control of a specific program or the captive login command procedure. The primary feature of the captive account is its login command procedure. This type of account ensures that the system login command procedure (SYLOGIN.COM) and the process login command procedure (specified by the /LGICMD qualifier in SYSUAF.DAT), as well as any command procedures they call, are executed. A user cannot modify the captive command procedures by specifying any of the. qualifiers shown in Table 5-7 when logging in. Once logged in to a captive account, a user cannot escape to the DCL command level through the Ctrl/Y sequence, the SPAWN command, or the INQUIRE command. Because the DISCTLY flag in the UAF record is turned on, any use of Ctrl/Y fails. If unhandled errors or attempted interrupts occur, a system error message is generated, and the session is logged out. Unless the SPAWN command carries the trRUSTED qualifier, it is ineffective within a captive account. SPAWN is also disabled from MAIL and the DEC Text Processing Utility (DECTPU) (as a built-in procedure). Lexical functions are also unavailable because the INQUIRE command is disabled.
Table 5-7 Login Qualifiers Precluded by Captive Accounts /CLI Specifies the name of an alternate command language interpreter /COMMAND Overrides the default login command procedure !NOCOMMAND Disables execution of the default login command procedure /DISK Requests an alternate default disk /TABLES Specifies the name of an alternate CLI table
5.13.1.1 Setting Up Captive Accounts You define a captive account with AUTHORIZE by including the following qualifier when creating the account: /FLAGS=(CAPTIVE) A captive account also requires the following qualifiers: • /LGICMD to identify the captive account login command procedure and override the default login command procedure (LOGIN.COM in the user's default directory). • /VIC to assign a unique UIC group. Use the following form of the AUTHORIZE command SHOW to verify the uniqueness of the UIC group: SHOW [groupuic, *]
5-52 Managing the System and Its Data 5.13 Using Limited-Access Accounts to Create a Restricted Environment
By keeping the account in a separate group, you can ensure that the captive users can access only world-accessible files and files owned by the captive account. Also ensure that the account is not a member of the system group (that is, has a group value less than or equal to 10s, unless modified by the system parameter MAXSYSGROUP). • /NOPASSWORD or /FLAGS=LOCKPWD to set up the password. With a captive account, either require no password or lock the password (LOCKPWD) so that only the security administrator can change it. Locked passwords are generally preferable to open captive accounts (those with no password). If you assign a locked password, give that password to all users of the captive account. • /PRCLM to set the subprocess limit to 0, thus preventing the user from spawning out of the account. (Verify that the system parameter PQL_ MPRCLM-the minimum subprocess limit-is set to 0.) In addition to the required settings, you may want to specify additional characteristics for the account: • You may want to disable the welcome announcement and electronic mail for the captive account. This is done by setting the DISWELCOME, DISMAIL, and DISNEWMAIL login flags. • You may want to allow only interactive use of the account from a local terminal. This is done by including the qualifiers /NODIALUP, /NOREMOTE, /NOBATCH, and /NONETWORK when establishing the account. • Your application may have special requirements. It may require you to impose additional AUTHORIZE qualifiers on the account, such as /NODIALUP, to restrict modes of operation. Consider imposing restrictions for the periods of the day and days of the week when the process can run. • You can define a special set of DCL tables by using the /CLITABLES qualifier, or you can emulate DCL through the use of a DCL command procedure. It is more efficient to define DCL tables than to resort to a DCL command procedure to emulate DCL. See the description of the Command Definition utility (CDU) in the Open VMS System Management Utilities Reference Manual for help when defining the DCL tables. • You can grant privileges, although you rarely need to grant any privilege other than TMPMBX to a captive account. • You can limit the disk quota for the captive account to the amount needed. 5.13.1.2 Guidelines for Captive Command Procedures When writing captive command procedures for your site, be sure to observe the following guidelines: • Use the DCL command READ/PROMPT in command procedures. For example, to request the user to enter the date, enter the following command in the command procedure: READ/PROMPT="Enter date: " SYS$COMMAND DATE • Avoid use of the INQUIRE command in a captive command procedure. It produces an error that, if unhandled by a previous ON declaration, results in deletion of the process.
5-53 Managing the System and Its Data 5.13 Using Limited-Access Accounts to Create a Restricted Environment
• When user input is required, never execute it directly. First compare it to what is expected and screen for illegal characters such as apostrophe ('), at sign(@), dollar sign($), quotation mark("), ampersand(&), and hyphen(-). • Avoid any use of the construction 'x, where x contains a string entered by the user. Never permit a restricted command procedure to attempt an evaluation of a symbol that the user enters. Use of lexical functions could break the command procedure. • Avoid executing a line in a captive command procedure that contains the characters "@TT:". • Put Audit ACEs on the captive command procedure and its home directory to detect any modification of the file. See Section 6.2.1.2 for more information on Audit ACEs. • If the captive account user is allowed to create or perform other operations on files, make certain that write access to the login command procedure and its directory is denied. (The user does need execute access.) If the function of the command procedure requires text preparation, you may need to give users access to a text editor. Use caution, however. Editors such as TECO or DECTPU can be dangerous because users can manipulate files and exit from the editor to the DCL interface. When designing this environment, remember that most text editors are capable of reading and writing files (within the access rights of the account). Provide an editor that gives users the tools they require but does not allow them to escape from the captive environment. Example 5-4 and Example 5-5 provide sample command procedures for privileged and unprivileged accounts.
Example 5-4 Sample Captive Procedure for Privileged Accounts
$if f$mode() .nes. "INTERACTIVE" then $logout $ term= f$logical("SYS$COMMAND") $ if £$locate(" T", term) .eq. 0 then $goto allow $ if £$locate( .. -OP" ,term) .ne. 0 then $logout $allow: - $ set control=(y,t) 5.13.2 Creating a Restricted Account Certain limited-access accounts require a less restrictive environment than captive accounts. Accounts under which network objects run, for example, require temporary access to DCL. Such accounts must be set up as restricted accounts, not captive accounts. (See Section 9.6.3 for details about network object accounts.) Restricted accounts are indistinguishable from regular accounts once the login sequence finishes. The purpose behind restricted accounts is to ensure a trusted login wherein SYLOGIN, LOGIN, and their descendants execute completely.
5-54 Managing the System and Its Data 5.13 Using Limited-Access Accounts to Create a Restricted Environment
Example 5-5 Sample Captive Command Procedure $ deassign sys$input $previous sysinput == f$logical("SYS$INPUT") $ on error-then goto next command $ on control y then goto next command $ set control=(y,t) - $ $next command: $ on error then goto next command $ on control y then goto next command $ - - $ if previous sysinput .nes. f$logical("SYS$INPUT") then deassign sys$input $ read/end=next_command/prornpt="$ " sys$command command $ command== f$edit(cornrnand,"UPCASE,TRIM,COMPRESS") $ if f$length(command) .eq. 0 then goto next_cornrnand $ ' $ delete = "delete" $ delete/symbol/local/all $if f$locate("@",command) .ne. f$length(cornrnand) then goto illegal command $if f$locate("=",command) .ne. f$length(cornmand) then goto illegaCcornmand $if f$locate("F$",command) .ne. f$length(command) then goto illegaI_command $verb= f$elernent(O," ",command) $ $ if verb .eqs. "LOGOUT" then goto do logout $ if verb .eqs. "HELP" then goto do help $ - $write sys$output "%CAPTIVE-W-IVVERB, unrecognized command \",verb,"\" $ goto next command $ - $illegal command: $ write sys$output "%CAPTIVE-W-ILLEGAL, bad characters in command line" $ goto next command $ - $do logout: $ logout $ goto next command $ - $do help: $ define sys$input sys$command $ help $ goto next_command
Define a restricted account with the Authorize utility (AUTHORIZE) by including the following qualifier when creating the account: /FLAGS=(RESTRICTED) This flag ensures that the account is noted as restricted. A restricted account provides the same features as those listed for a captive account in Section 5.13.1 except that restricted accounts allow the user access to the DCL command level following the execution of the system and process login command procedures. Sometimes it is appropriate to allow the user to enter the Ctrl/Y key sequence after the command procedure starts. For example: • You may want to provide users with a Ctrl/Y feature at points during the execution of the restricted login command procedure. Include ON CONTROL_ Y commands in the procedure where you want to test for the Ctrl/Y features, as shown in Example 5-5.
5-55 Managing the System and Its Data 5.13 Using Limited-Access Accounts to Create a Restricted Environment
• You may have a restricted command procedure that ultimately turns control over to the user. For example, consider a SYLOGIN.COM command procedure that performs additional security validation; its execution should be guaranteed to ensure its effectiveness. However, once SYLOGIN.COM has done its job, control can be passed to the user. To do this, mark the account as restricted, and enter the DCL command SET CONTROL=Y when you are ready to release control to the user. 5.13.3 Guest Accounts Guest accounts are forms of captive or restricted accounts that allow multiple remote users access to resources on your system through a common account. For example, users across the network may need access to your system to report problems or to read corporate memos. Digital does not recommend the practice of setting up guest accounts. Guest accounts, however unprivileged, offer malicious users a chance to compromise your system security. Most needs for a guest account can be handled by special proxy login accounts, which should also be limited-access accounts. If you still need a guest account, take the following steps to make the account secure: • Use an obscure password for the guest account. Change the password frequently. Never use easily guessed account name and password combinations such as GUEST/GUEST or USER/USER. • Maintain a list of people allowed to use the account. (Changing the password regularly helps you keep this list current.) • Set up the guest account in a separate UIC group. Make sure that the account is not a member of the system group. • Place the default login command procedure in the directory SYS$MANAGER by using the AUTHORIZE command MODIFY, as follows: MODIFY guest-account/LGICMD=SYS$MANAGER:filename.COM • Make the guest account restricted or captive by setting the AUTHORIZE qualifiers /FLAGS=RESTRICTED or /FLAGS=CAPTIVE, respectively. • If the guest account is set up as a restricted account, limit the number of subprocesses that the account can create to 0 using the AUTHORIZE qualifier /PRCLM=O. (Ensure that the system parameter PQL_MPRCLM is also set to 0.) • Assign the guest account only TMPMBX privilege. • To handle error conditions, include the following commands in the default login command procedure: SET ON SET NOCONTROLY ON ERROR THEN LOGOUT/BRIEF • If LOGOUT is defined as a global symbol and points to a command procedure (enter the DCL command SHOW SYMBOL LOGOUT to confirm this), include the following DCL command in the default login command procedure for the account: DELETE/SYMBOL LOGOUT/GLOBAL
5-56 Managing the System and Its Data 5.13 Using Limited-Acc~ss Accounts to Create a Restricted Environment
This command eliminates the possibility that the user could break the restricted account at logout time by pressing Ctrl/Y. • To prevent outsiders from misusing your system resources through the submission of batch jobs under the guest account, include the AUTHORIZE qualifier /NOBATCH when you create the account. • Limit the disk quota for the guest account UIC to the amount needed. • Do not allow the DCL command INQUIRE to appear in any of the command procedures. 5.13.4 Effect of the DISIMAGE Flag The AUTHORIZE flag DISIMAGE prevents users from using the MCR or the RUN command to execute system or user-written images or from executing images defined as foreign commands. ·Because the DISIMAGE flag is enforced by the DCL command language interpreter (CLI), you must ensure that the account for which the DISIMAGE flag is set has access to the DCL CLI only. Use the DISIMAGE flag in conjunction with the AUTHORIZE flag DEFCLI or within a restricted account. (Setting the RESTRICTED flag for an account implicitly sets the DEFCLI flag.) 5.13.5 Proxy Login Accounts Generally, proxy login accounts should be set up as restricted accounts. Proxy login accounts permit remote users to access a local account without specifying a password. Section 9.7.1.2 describes proxy login accounts. Note that many recommendations are the same as those for restricted accounts. 5.14 Training the New User Teaching new users about system security is an important security tool. It is important to involve users in security methods and goals; the more they know about the system and how break-ins occur, the better equipped they are to guard against them. Include the following topics in your user training: • What is the location of the user's account? Specifically, which system, where is it located, what is the proper node name if on a network, and, if the system is part of a cluster, what other nodes are available? • Which terminals can be used for logging in, and where are they located? • Is the account restricted with regard to local, dialup, remote, interactive, network, or batch operations? If so, describe both permitted use and restrictions. • Can the account be accessed by dialing in? If so, provide the access telephone number and describe the procedure. Specify how many retries are allowed and the maximum number of seconds allowed between each before the connection is lost. • Are system passwords implemented for any terminals that the user may be using? If so, describe which terminals, how often the system password is changed, and how the user can learn the new system password. • What is the account duration? When will it expire? From whom should the user request an extension?
5-57 Managing the System and Its Data 5.14 Training the New User
• What is the user name? What identifiers are held by the user, if any? What are the group and member numbers associated with the user? • What password information is required? Specifically, what is the initial password? Is the password locked? If the password is not locked, how often must the password be changed? What' is the minimum length for the password? Is there a secondary password for this account, and who will know it? Is the user free to select passwords, or must they be automatically generated? • What is the default device and directory? • What is the default protection? • Are there quotas on disk usage? If so, what are the values? • Are there restrictions on use? For example, are there certain days or hours of the day that are suggested or enforced? Explain primary and secondary days if applicable. • Are there files or directories that are shared? If so, provide the details. • Are there ACLs that affect the user? What identifiers does the user need to know? • Which privileges does the user hold? • What is the command language interpreter? • Which type of account is this: open, locked, captive/restricted, or normal? • Which nodes permit proxy logins for this user, if any? • What are the names of the queues the user may need to use? • What actions should the user take to ensure physical site security, such as locking up materials?
5.15 Logging a User's Session While users are learning the system, you may choose to monitor terminal sessions or they may want to log their own sessions so they have a record of their actions. To log an entire terminal session, you set host to your own system and specify that a log file of the session be kept. The resulting log file contains a record of the entire terminal session. For example, the following command keeps a record of the entire session in the log file APRIL15.LOG: $ SET HOST 0 /LOG=APRIL15.LOG Note that if you use the /LOG qualifier without including a file specification, the log information is stored in the file SETHOST.LOG. (Use of the SET HOST command requires that DECnet software is configured and started. Details on these operations are provided in the DECnet for Open VMS Networking Manual.) By using a special restricted account and appropriate command procedures, you can enforce the logging of terminal sessions for selected users. These users would need to log in to the special restricted account first and then log in to their own account. The restricted account ensures that the session is logged.
5-58 Managing the System and Its Data 5.15 Logging a User's Session
The following example provides guidelines on how to set up the restricted account (named USER_LOG in this example) and includes samples of appropriate command procedures: 1. Set up the restricted account USER_LOG as follows: UAF> ADD USER LOG /FLAGS=(RESTRICTED,DISMAIL,DISNEWMAIL) UAF> /LGICMD~SYS$SYSROOT:[USER LOG]SESSIONLOG- -UAF> DEV=SYS$SYSROOT: /DIR=[USER LOG]- =UAF> /NONETWORK /NOBATCH /UIC=[200,256] 2. The SESSIONLOG.COM command procedure enables logging of the terminal session, as follows: $ ! SESSIONLOG.COM - log in to specified account with terminal session $ ! logging enabled. $ $WRITE SYS$0UTPUT "Please log in to the account of your choice." $WRITE SYS$0UTPUT "Your terminal session will be recorded." $ WRITE SYS$0UTPUT $ $ Acquire the intended user name and save it in a temporary file. Use $ it to name the log file, and pass it as the first line of input to $ LOGIN. $ ! 11 $ READ/PROMPT= Username: II SYS$COMMAND USERNAME 11 11 $ PID = F$GETJPI (0, PID ) $ OPEN/WRITE OUTPUT USERNAME'PID' .TMP $ WRITE OUTPUT USERNAME $ CLOSE OUTPUT $ DEFINE/USER SYS$INPUT USERNAME'PID' .TMP $ SET HOST 0 /LOG='USERNAME' .LOG $ DELETE USERNAME'PID' .TMP;O $ LOGOUT 3. Set up each account for which session auditing is to be enforced. The following command sets up the account for user Smith: UAF> MODIFY SMITH /FLAGS=RESTRICTED /NOLOCAL /NODIALUP - _UAF> /LGICMD=SYS$SYSROOT:[USER_LOG]CHECKLOG Because the restricted login command procedure ensures that the login is coming from the USER_LOG account using a SET HOST command, the session' is logged. 4. You may also want to disable batch and network access for each user account to allow only local logins from the USER_LOG account. For example: UAF> MODIFY SMITH/FLAGS=RESTRICTED/NOLOCAL/NODIALUP/NOBATCH - /NONETWORK/LGICMD=SYS$SYSROOT:[USER_LOG]CHECKLOG 5. The following CHECKLOG.COM command procedure verifies that the user is logging in to the USER_LOG account. For this procedure to work correctly, you must have enabled DECnet proxy accounts as described in Section 9.7.
5-59 Managing the System and Its Data 5.15 Logging a User's Session
$ ! CHECKLOG.COM - ensure that the account is being logged in to $ ! with the user log account. $ ! $ IF F$MODE () .NES. "INTERACTIVE" THEN EXIT $ ! $ ! Verify that the connection originated from the local node and $ ! from the USER LOG account. $ ! - $ IF F$LOGICAL ("SYS$NODE") .EQS. F$LOGICAL ("SYS$REM NODE") $ .AND. F$LOGICAL ("SYS$REM ID") .EQS. "USER LOG"- - -$ THEN GOTO OK - - $WRITE SYS$0UTPUT "You may only log in to this account with ", $ "the USER LOG - account. " - $ LOGOUT $ $ When the login has been verified, enable Ctrl/Y to $ release the account, invoke the user's LOGIN.COM, and turn $ control over to the user. $ $ OK: $ SET CONTROL Y $ IF F$SEARCH- ("LOGIN. COM" ) .EQS. 1111 THEN EXIT $ @LOGIN
5.16 Configuring Terminal Lines for Modems When configuring terminal lines for modems, never set the /COMMSYNC qualifier to the DCL command SET TERMINAL (or the TT$M_COMMSYNC characteristic for the TTDRIVER interface) on a line with a modem hookup that is intended for interactive use. The qualifier disables the modem terminal characteristic that disconnects a user process from the terminal line in case of a modem phone line failure. With the /COMMSYNCH qualifier enabled, the next call on the terminal line could be attached to the previous user's process. The /COMMSYNC qualifier is intended to allow connection of asynchronous printers and other devices to terminal ports by using modem signals as flow control. Security administrators should be aware that the characteristic should not be used on interactive terminal ports.
5.17, Disk Maintenance Considerations Proper disk maintenance includes the following: • Physical security for disks • Backups of disks • Physical security for backup media • Retrieving files from backups 5.17.1 Backups of Disks Having an effective backup schedule is critical to protect your data. By performing regularly scheduled backup operations, you prevent the loss of accidentally deleted or damaged files.
5-60 Managing the System and Its Data 5.17 Disk Maintenance Considerations
Refer to the Open VMS System Management Utilities Reference Manual for information about performing backups and setting up backup schedules. Be aware that the Backup utility (BACKUP) does not implement security policy; you must direct it explicitly. It runs with the security profile of the operator, which can often be privileged. 5.17.2 Protecting a Backup Save Set Limiting access to backup save sets is an important part of system security. The file system treats a backup save set as a single file, whether it is stored on disk or on magnetic tape. Therefore, anyone with access to a save set can read any file in the save set. BACKUP does not check protection on individual files until after they are restored to standard OpenVMS file format. To maintain system security, it is crucial that you protect save sets adequately. Assign restrictive protection to save sets on disk and to magnetic tape volumes by using the output save-set qualifiers /OWNER_UIC and /PROTECTION. Sufficient protection can prevent nonprivileged users from mounting a save-set volume or from reading files from a save set. You should also take physical security precautions with save sets stored off line by keeping backup media in locked cabinets. When you write a save set to a Files-11 disk or a sequential disk and do not specify the /PROTECTION qualifier, BACKUP applies the process default protection to the save set. If you specify /PROTECTION, any protection categories that you do not specify default to your default process protection. Protection information is written to the volume header record of a magnetic tape and applies to all save sets stored on the tape. Therefore, the output save-set qualifiers /OWNER_UIC and /PROTECTION are effective on magnetic tape save sets only if you specify the output save-set qualifier /REWIND. This qualifier allows the tape to rewind to its beginning, to write the protection data to the volume header record, and to initialize the tape. If you specify /PROTECTION, any protection categories that you do not specify default to your default process protection. If you do not specify /REWIND with the /PROTECTION and /OWNER_UIC qualifiers, the magnetic tape retains its existing protection. However, specifying /REWIND alone results in a magnetic tape without any protection. The following example illustrates how a directory is backed up to tape: $ BACKUP FROM: [PAYROLL] -TO: MFA2:KNOX.BCK/LABEL=BANK01 - 0 -$ /REWIND/OWNER UIC=[030,003] - f) -$ /TAPE EXPIRATION=15-JAN-1993 - 0 =$ /PROTECTION=(S:RWE,O:RWED,G:RE,W) ., 0 The contents of the directory [PAYROLL] is copied to file KNOX.ECK on the magnetic tape drive MFA2. The output save-set qualifier /LABEL provides the label BANKOl for the tape. f) The output save-set qualifier /OWNER_UIC assigns an owner UIC of [030,003] to the save set. 0 The output save-set qualifier /TAPE_EXPIRATION assigns an expiration date of January 15, 1993 to the tape.
5-61 Managing the System and Its Data 5.17 Disk Maintenance Considerations
0 The output save-set qualifier /PROTECTION assigns the owner of the volume read, write, execute, and delete access. System users are assigned read, write, and execute access; group users are assigned read and execute access; world users are assigned no access. 5.17.3 Retrieving Files from Backup Save Sets Anyone who has access to a save set can read any file in the save set. Never give a copy of your backup media to a user; a malicious user could restore the files from the tape or disk and compromise the security of the system. When a nonprivileged user wants to restore a particular file, do not lend the volume containing the save set. You could give away access to all the files on the volume. The safest way to restore a particular file is to restore the file selectively, as shown in the following example: $ BACKUP MTAO:JULY.BCK/SELECT=[JONES.TEXTPROC]LASTMONTH.DAT - _$ [* ••• ]/BY_OWNER=ORIGINAL The selected file is restored with its. original directory, ownership, and protection. In this way, the file system determines if the user is permitted access to the file. 5.18 Methods for Discouraging Disk Scavenging Disk scavenging is the process of reading magnetic imprints of data after deletion of the file header following a purge or delete operation. (When users delete files from the system, only the file header is deleted.) Until the data is overwritten, it is a potential target for disk scavenging. Sites with medium or high security needs should be concerned about this procedure. After establishing overall security features, restrict access to disks containing valuable information by using UIC-based volume protection. Because disk scavenging is frequently performed by authorized users, consider implementing erasure patterns and highwater marking, as described in the following sections. 5.18.1 Erasing Techniques There are several ways to implement erasing of disks. • The inclusion of the /ERASE qualifier with the DELETE or the PURGE command causes the system to write an erasure pattern of zeros over the entire file location when you delete or purge that file. You can encourage users to use this qualifier voluntarily or make inclusion automatic by including the following command definitions in the system login command procedure (usually SYS$MANAGER:SYLOGIN.COM): DEL*ETE :== "DELETE/ERASE" PUR*GE :== "PURGE/ERASE" However, any user can bypass these definitions by adding the /NOERASE qualifier to the DELETE or the PURGE command. • To guarantee erase-on-delete, turn on the feature for the entire volume by using the DCL command SET VOLUME/ERASE_ON_DELETE. When files are deleted, this command overwrites all files on the volume with the erasure pattern of zeros.
5-62 Managing the System and Its Data 5.18 Methods for Discouraging Disk Scavenging
• To completely erase the volume and enable erase-on-delete for the volume at volume initialization, use the DCL command INITIALIZE/ERASE. By default, when erase-on-delete is enabled, the operating system writes a default data security erase (DSE) pattern of zeros, applied during a single write operation over the area. If you feel that the default pattern of zeros or the single rather than multiple number of erasures does not suit your requirements, you can use the $ERAPAT (Get Security Erase Pattern) system service to write a customized erasure pattern to specified files. See the description of $ERAPAT in the Open VMS System Services Reference Manual for more information. Generally, for sites with high-level security requirements, a random pattern is preferable to a fixed pattern. The technology is already available that can detect and use faint residual magnetic impressions. Thus, if you conclude there is sufficient danger that a disk might be removed and read by some of this specialized analysis equipment, you may need to rewrite the erasure pattern several times. You can learn how to customize the data security erase pattern to fit your needs by studying the information provided in the file SYS$EXAMPLES:DOD_ERAPAT.MAR. Employ erasing patterns only on disks where the security needs are the greatest. Erasures are time-consuming and affect system performance. 5.18.2 Prevention Through Highwater Marking Highwater marking refers to a technique that tracks the furthest extent to which each file has been written and prohibits user attempts at reading data beyond that point. The operating system implements true highwater marking for all sequential, exclusively accessed files, such as the set of files output from various text editors, compilers, and linkers; that is, most files a process writes. The highwater mark is updated in the file header whenever the logical end-of-file mark is updated (usually when the file is closed). For shared files (both indexed and sequential), the operating system uses the principle of erase-on-allocate to achieve a result similar to true highwater marking. When a file is about to be created or extended, the system determines how much disk space (the extent of the file) is required and applies the security erasure pattern of zeros to the areas (extents) it allocates for writing. The file is then written into the area just erased for it. Thus, if any user gains access to the file (including its full extent) and attempts to read the area beyond where the file has been written, only the data security erase pattern is readable. By default, the operating system turns on highwater marking for all volumes. Highwater marking is a deterrent to disk scavenging attempts. However, it does require additional I/O, which affects system performance. You can turn off highwater marking on a volume-by-volume basis by specifying the DCL command SET VOLUME/NOHIGHWATER_MARKING.
5-63 Managing the System and Its Data 5.18 Methods for Discouraging Disk Scavenging
5.18.3 Summary of Prevention Techniques As security administrator, you can apply the following controls to discourage disk scavengers: • Provide tight physical security, particularly on those disks with the most valuable information. • Provide tight volume protection through DIC-based protection. • Encourage the use of the /ERASE qualifier when key files are purged or deleted through user participation or volume enforcement. • Permit default highwater marking on your most valuable disks.
5.19 Ongoing Tasks to Maintain a Secure System Maintaining a secure system requires continuous surveillance. The following ongoing tasks are important to you in your role as security administrator: • Use the MONITOR IO report to develop a familiarity with the normal amounts of 1/0 on your system at various times. Watch for abnormal changes. • Keep informed of the images installed on your system. Use the Install utility (INSTALL) to look for unexpected additions. • Use the AUTHORIZE command SHOW on a regular basis to check for unauthorized user names. • Use the AUTHORIZE command SHOW/PROXY regularly to quickly recognize all proxy access that you have authorized. Watch for unexpected additions. Remove any remote users who no longer require access. Institute regular communications with system managers at remote nodes. • Apply the Accounting utility (ACCOUNTING) on a regular basis to give you a basis of normal amounts of processing time. Watch for unexplained changes. • Regularly check the accounting report produced by ACCOUNTING for known user names, unknown user names, and appropriate hours of system use. • Develop sufficient familiarity with your system's workload so that you notice normal (as well as abnormal) processing activity occurring at unusual hours. • Monitor device allocations routinely with the DCL command SHOW DEVICE so that you immediately notice any that are unexpected. • Become familiar with the recurring types of batch jobs that run on the batch queues and what times they are most likely to run. • Monitor the protection and ownership of critical files with the DIRECTORY /SECURITY command. Watch for unexplained changes in each. • Maintain familiarity with the rights list. Keep current listings so that you can recognize identifiers that have been added or new holders of the current identifiers. • Remove identifiers that are not in use. Keep the rights list current. • Regularly review the templates that you use to set up UAF records. Make any necessary changes. • Use the security auditing features described in Chapter 6.
5-64 Managing the System and Its Data 5.19 Ongoing Tasks to Maintain a Secure System
• Apply the Audit Analysis utility (ANALYZE/AUDIT) regularly to detect abnormal auditing activity. • Try to break into your user accounts with some obvious password choices. • When you allow new users to change their initial passwords, check back to see if you can log in with the password you originally assigned. Where necessary, follow up with the user to determine why the change did not occur as requested. • Try searching unprotected user files for passwords embedded in network access control strings. The password will precede the 3-character terminator ( ":: ). Also search for the noun password, and see if any passwords are revealed nearby. • Check that your users are logging out properly. Make physical checks at the end of normal business hours. • Check that your users have appropriate default protections in place. • Keep informed about your inventory of magnetic tapes, disks, and program listings. Routinely check that inventory for possible indications that physical security has degraded. • Keep your office and all important listings locked up.
5-65
6 Security Auditing ·
This chapter describes how to use and manage the OpenVMS auditing system. It explains how you can monitor security-relevant activity on your system by recording events as they occur on the system and subsequently analyzing this audit log. 6.1 Overview of the Auditing Process Auditing is the recording of security-relevant activity as it occurs on the system and the subsequent analysis of this audit log. With auditing, you can monitor users' activity on the system and, if necessary, reconstruct events leading up to attempts to compromise the security of your system. Thus, it is not as much a method of protecting the system and its data as a method of analyzing and recording system use. Anything that has to do with a user's access to the system or to a protected object within the system is considered a security-relevant activity. Such activities are called events. Typical events include the following: • Logins, logouts, or login failures • Changes to the authorization database • Access to a protected object, such as a file, device, or global section • Changes in privileges or the security attributes of protected objects The operating system can record both successful and unsuccessful events. Sometimes the unsuccessful can be more revealing. For example, it is less important to record that a programmer displayed a file to which he had access than that the same programmer tried to but was prevented from displaying a protected file. The event message itself can be written to two places: an audit log file or an operator terminal that is enabled to receive security class messages. As Example 6-1 shows, a 'message contains the following data: 0 Date and time of the message 8 Type of event 8 Date and time the event occurred 0 The process identification (PID) of the user who caused the event Additional information in aud1ting messages is specific to the type of event. See Appendix D for examples of different messages.
6-1 Security Auditing 6.2 Reporting Security-Relevant Events
Example 6-1 Sample Alarm Message
%%%%%%%%%%% OPCOM 25-JUL-1993 16:07:09.20 %%%%%%%%%%% Ct Message from user AUDIT$SERVER on GILMORE Security alarm (SECURITY) on GILMORE, system id: 20300 Auditable event: Process suspended ($SUSPND) f) Event time: 25-JUL-1993 16:07:08.77 6) PID: 30C00119 8 Process name: Hobbit Username: HUBERT Process owner: [LEGAL,HUBERT] Terminal name: RTAl: Image name: $99$DUAO:[SYSO.SYSCOMMON.][SYSEXE]SET.EXE Status: %SYSTEM-S-NORMAL, normal successful completion Target PID: 30C00126 Target process name: SMISERVER Target username: SYSTEM Target process owner: [SYSTEM]
6.2 Reporting Security-Relevant Events Beyond a certain set of default reporting (see Table 6-1), the kind of security event information you receive depends on the kind of information you select from a long list of possible events. This section explains how to enable the reporting of security-event information. Specifically, it discusses the following topics: • Ways to generate event messages • Types of events the system can report • Sources of event information 6.2.1 Ways to Generate Audit Information Whenever you install or upgrade your system, the OpenVMS operating system automatically audits a limited number of events. These event categories, which are shown in Table 6-1, represent major changes in the security of your system. Depending on your site's requirements, you may want to enable other forms of reporting. You can have the operating system report on security-related activity in three different ways: • By enabling a category of events for auditing. For example, all login failures or all changes to system parameters can be reported. • By attaching an access control entry (ACE) to a protected object. For example, any time a user modifies a particular file, a message can be generated. • By modifying a user's authorization record so the system audits all operations performed from the account. 6.2.1.1 Auditing Categories of Activity Security-relevant events are divided into a number of categories called event classes. The operating system audits several event classes by default (see Table 6-1). If the security requirements at your site justify additional auditing, you enable security auditing for additional event classes by using the DCL command SET AUDIT.
6-2 Security Auditing 6.2 Reporting Security-Relevant Events
To enable auditing for different event classes, use the following command format: SET AUDIT /ENABLE=event-class[, ... ] {/ALARM I /AUDIT} The command requires two qualifiers to enable events: • The /ENABLE qualifier defines which event classes you want audited. See Table 6-3 for a list of event classes. • The /AUDIT qualifier or the /ALARM qualifier defines the destination for the event message. The /AUDIT qualifier directs the message to the audit log file, whereas the /ALARM qualifier directs the message to an operator terminal that has been enabled to receive security event messages. Critical events should be reported as both audits and alarms; less critical events can be written to a log file for later examination. The default event classes listed in Table 6-1 are audited as both alarms and audits. The operating system begins auditing the new events on all nodes of the cluster as soon as you enable them. It continues auditing until you explicitly disable the classes with the /DISABLE qualifier. For more information about the SET AUDIT command, see the Open VMS DCL Dictionary.
Table 6-1 Event Classes Audited by Default Class Description ACL Access to any object holding a security-auditing ACE. Audit All uses of the SET AUDIT command. This category cannot be disabled. - Authorization All changes to the authorization database: • System user authorization file (SYSUAF.DAT) • Network proxy authorization file (NETPROXY.DAT) • Rights database (RIGHTSLIST.DAT)
Break-in All break-in attempts: batch, detached, dialup, local, network, remote. Logfailure All login failures: batch, dialup, local, remote, network, subprocess, detached.
To see which event classes your site currently audits, enter the DCL command SHOW AUDIT. Example 6-3 displays the audit settings for a site with moderate security requirements. Example of Enabling Event Classes Although you can enable auditing for every possible class of security activity (/ENABLE=ALL), such an approach can result in an excessive number of auditing messages and generates too much information to analyze in a meaningful way. Therefore, Digital suggests that you evaluate your needs, as described in Section 6.3.1, and selectively audit system activity.
6-3 Security Auditing 6.2 Reporting Security-Relevant Events
You can enable auditing of event classes with different levels of granularity. You can use the following methods: ' • Enable a class To enable auditing for all login failures, for example, you enable the logfailure class by entering the following command: $ SET AUDIT/AUDIT/ENABLE=LOGFAILURE=ALL As a result of this command, the audit server reports all login failures in the security audit log file. • Enable a subset of a class With certain events, you may want to be more selective in the kinds of reporting you enable. For example, it makes more sense to enable network and remote login events rather than to enable all logins. To enable auditing of only the network and remote logins, enter the following command: $ SET AUDIT/AUDIT/ENABLE=LOGIN=(NETWORK,REMOTE) • Enable successful, unsuccessful, or privileged events Event messages that report on normal system use can easily be eliminated if you enable only unsuccessful event reports or reports for activity performed through a certain privilege. When auditing access events to protected objects, in particular, you need to define your information requirements more finely than you would with event classes like logins or use of the Install utility. Files and certain other protected objects are accessed so often that full enabling of the related access event class can result in an overwhelming number of event messages- so many that they can possibly mask the unusual events that do require investigation. For this reason, it is recommended that you enable access auditing only for unusual conditions, such as unsuccessful accesses or privileged access. To enable auditing of unsuccessful file access events, enter the following command: $ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE Notice that the previous command enables auditing for all failed file accesses, not just failed read or write access attempts. This is recommended because access operations can be quite involved: what appears to be a simple write operation can involve several types of access. (For example, before writing to the file, the operation requires access to the volume and read access to the directory as well as access to the file within it.) Example 6-2 displays an event message from a file access failure. User Robinson tried to delete the file FOO.BAR, but an ACE on the file prevented it. Apparently, Robinson holds the identifier MINDCRIME, and an Identifier ACE on FOO .BAR denies access to those holding such an identifier. Furthermore, because the system owns the file, Robinson cannot gain delete access to the file through the protection code either.
6-4 Security Auditing 6.2 Reporting Security-Relevant Events
Example 6-2 Audit Generated by an Object Access Event Message from user AUDIT$SERVER on BILBO Security alarm (SECURITY) and security audit (SECURITY) on BILBO, system id: 19662 Auditable event: Object deletion Event information: file deletion request (IO$ DELETE) Event time: 24-APR-1992 13:17:24.59 - PID: 47400085 Process name: Hobbit Username: ROBINSON Process owner: [ACCOUNTING,ROBINSON] Terminal name: OPAO: Image name: DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE Object class name: FILE Object owner: [SYSTEM] Object protection: SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE File name: DSA2200:[ROBINSON]FOO.BAR;l File ID: (17481,6299,1) Access requested: DELETE Matching ACE: (IDENTIFIER=MINDCRIME,ACCESS=NONE) Sequence key: 00008A41 Status: %SYSTEM-F-NOPRIV, no privilege for attempted operation
6.2.1.2 Attaching a Security-Auditing ACE As Section 6.2.1.1 describes, auditing access to protected objects requires careful thought because this type of event occurs so frequently. Too many event messagef? can overwhelm you and possibly mask the unusual events that do require investigation. A more selective method of auditing protected objects is to include an auditing ACE in an object's access control list (ACL) and enable the ACL event class. With this approach, only access to objects with security-auditing ACEs results in an event message, not all objects of a class. You can use two different types of auditing ACEs, depending on where you want the event reported. Alarm ACEs direct event messages to the operator terminal, whereas Audit ACEs direct event messages to the audit log file. Table 6-2 summarizes the auditing ACEs, and the Open VMS System Management Utilities Reference Manual provides a full description of them.
6-5 Security Auditing 6.2 Reporting Security-Relevant Events
Table 6-2 Access Control Entries (ACEs) for Security Auditing ACE Type Description Alarm ACE Writes an event message to the operator terminal whenever the object is accessed in the specified manner. It has the following syntax: (ALARM=SECURITY[,OPTIONS=options],ACCESS=access type[+access-type ... ])
Audit ACE Writes an event message to the security audit log file whenever the object is accessed in the specified manner. It has the following syntax: (AUDIT=SECURITY [,OPTIONS=options],ACCESS=access type[+access-type ... ])
You attach an ACE to sensitive objects by using the DCL command SET SECURITY/ACL or the access control list editor (ACL editor). Always include the SUCCESS or FAILURE keyword (or both) in the access statement of an auditing ACE. It is a good idea to define auditing ACEs for critical system files that are not automatically audited, such as the automatic login file SYSALF.DAT, the operator log file OPERATOR.LOG, or the system accounting file ACCOUNTING.DAT. Do not monitor all access conditions, however, because such an approach can generate a large volume of messages, many of which are not useful. For example, tracking successful write operations to OPERATOR.LOG probably will not produce interesting information, but unsuccessful attempts probably will. You can add auditing ACEs to any protected object, although files are the most common objects to audit. You may want to add an auditing ACE to a print queue that is handing sensitive documents or add one to a terminal to catch attempted password grabbers (see Section 3.8). Example of Adding an Auditing ACE To establish an Alarm ACE for the accounting file, enter the following command: $ SET SECURITY/ACL=(ALARM=SECURITY,ACCESS=DELETE+CONTROL+SUCCESS+FAILURE)- _$ SYS$MANAGER:ACCOUNTING.DAT The ACL event class is enabled by default, but if it has been disabled at a site, a site security administrator must enter the following command to reenable the use of auditing ACEs: $ SET AUDIT/ALARM/AUDIT/ENABLE=ACL
6.2.1.3 Modifying a User Authorization Record Sometimes security administrators may see one of their users acting in a suspicious way. Perhaps they are logging in from a number of terminals or logging in at unusual times of the day or the week. You can monitor the person's actions by modifying the auditing attribute in their user authorization record. Run the AUTHORIZE utility and set the Audit flag. The following command sequence modifies the account of user Robin: $ RUN SYS$SYSTEM:AUTHORIZE UAF> MODIFY ROBIN/FLAGS=AUDIT %UAF-I-MDFYMSG, user record(s) updated
6-6 Security Auditing 6.2 Reporting Security-Relevant Events
With the Audit flag set, the operating system audits the user's process. The audit log file contains a report of any action the user performs that the operating system is capable of auditing (see Section 6.2.2). You can use the Audit Analysis utility to review the user's actions. For example, to get a report on the activities of user Robin, enter the following command: $ ANALYZE/AUDIT/SELECT=(FLAGS=MANDATORY,USERNAME=ROBIN) - _$ SECURITY.AUDIT$JOURNAL See Section 6.5 for a full description of the Audit Analysis utility. 6.2.2 Kinds of System Activity the Operating System Can Report With the DCL command SET AUDIT, you can enable auditing for one or more of the event classes shown in Table 6-3. Many of the events classes have keywords permitting you to define a subset of the event class.
Table 6-3 Kinds of Security Events the System Can Report Event Class Description Access Specifies access events for all objects in a class. You can audit selected types of access, both privileged and nonprivileged, to all protected objects of a particular class. ACL Events requested by a security Audit or Alarm ACE in the ACL of an object. Authorization Modification of any portion of SYSUAF.DAT, NETPROXY.DAT, or RIGHTSLIST.DAT. Breakin Break-in attempts. Connection Logical link connections or terminations through SYSMAN, DECnet, DECwindows, or an interprocess communication (IPC) call. Create Creation of a protected object. Deaccess Deaccess from a protected object. Delete Deletion of a protected object. Identifier Use of identifiers as privileges. Install Modifications made to the known file list through the Install utility. Logfailure Unsuccessful login attempts. Login Successful login attempts. Logout Lo gouts. Mount Volume mounts and dismounts. NCP Modification to the network configuration database, using the network control program (NCP). Privilege Successful or unsuccessful use of privilege. Process Use of one or more of the process control system services. SYSGEN Modification of a system parameter with the System Generation (SYSGEN) utility or AUTOGEN. Time Modification of system time.
6-7 Security Auditing 6.2 Reporting Security-Relevant Events
6.2.2.1 Suppression of Certain Privilege Audits Although a site may enable the privilege event class, the operating system does not report every event in this class. It suppresses the following types of audits: • Successful use of privileges with which an image is installed For example, the image SHOW.EXE is installed with WORLD privilege. When unprivileged users enter the SHOW SYSTEM command, SHOW.EXE uses WORLD privilege to perform wildcard $GETJPI system service calls. This use of WORLD privilege is not audited. However, if the same unprivileged users attempt to use the SHOW PROCESS command to display process attributes for a process that they do not have access to, the operation fails. This lack of WORLD privilege is audited even though SHOW.EXE is installed with WORLD privilege. • Successful use of a lesser privilege than installed with the image When an image is installed with a greater privilege than used, the lesser privilege is not audited if the request is successful. For example, if an image installed with CMKRNL privilege successfully executes a $CMEXEC system service call, the use of the CMEXEC privilege is not audited. The following relationships exist:
Greater Privilege Privilege It Implies PRMMBX TMPMBX CMKRNL CMEXEC SYSNAM GRPNAM WORLD GROUP SYSPRV GRPPRV BYPASS SYSPRV, GRPPRV, READALL, DOWNGRADE, UPGRADE
• Any use of SETPRV privilege by an image installed with SETPRV Although the operating system does not audit use of SETPRV, it does audit the use of any privilege enabled with SETPRV. Digital recommends that you install an image with the privileges that it actually needs and avoid installing images with SETPRV. • With protected subsystems, successful access by using a subsystem identifier 6.2.2.2 Suppression of Certain Process Control Audits Although a site may enable the process event class, the operating system does not report every event in this class. It suppresses the following types of audits: • Server processes created with the DCL command RUN/TRUSTED or the Create Process system service ($CREPRC) with the ~RC$M_TCB flag set Server applications that do need to audit information regarding their clients can set the auditing flags NSA$M_SERVER or CHP$M_SERVER, which override the process no-audit setting for the duration of the auditing call. • Process control events inside your process's job tree that have the same UIC as the requestor You do not see any process control audits when granting or revoking identifiers to or from your own process. However, events related to the use of $CREPRC and $DELPRC are always audited.
6-8 Security Auditing 6.2 Reporting Security-Relevant Events
6.2.3 Sources of Event Information Applications and system programs can contribute security-event information by calling the following system services: • $AUDIT_EVENT • $CHECK_PRIVILEGE • $CHKPRO and $CHECK_ACCESS Audit Event ($AUDIT_EVENT) System Service The operating system calls the $AUDIT_EVENT system service every time a security-relevant event occurs on the system. By looking at the SET AUDIT settings, the system service determines whether you enabled auditing for the event. When the event is enabled for alarms or audits, $AUDIT_EVENT generates an audit record that identifies the process (subject) involved and lists event information supplied by its caller. Check Privilege ($CHECK_PRIVILEGE) System Service The operating system calls the $CHECK_PRIVILEGE system service any time a user attempts to perform a privileged function. (The current set of OpenVMS privileges is listed in Appendix A.) The system service performs the privilege check and looks at the SET AUDIT settings to determine whether you enabled privilege auditing. When privilege auditing is enabled, $CHECK_PRIVILEGE generates an audit record. The audit record identifies the process (subject) and privilege involved, provides the result of the privilege check, and lists supplemental event information supplied by its caller. Privilege audit records usually contain the DCL command line or system service name associated with the privilege check. Check Protection ($CHKPRO) and Check Access ($CHECK_ACCESS) System Services The operating system calls the $CHKPRO system service any time a process (subject) attempts to access a protected object. The system service performs the access arbitration according to the rules described in Section 4.3. By looking at the SET AUDIT settings for the associated object class, the service also determines whether you enabled auditing for the associated object access event. When an alarm or an audit is required, $CHKPRO generates an audit record that identifies the process (subject) and object involved and includes the final outcome and any supplemental event information supplied by its caller. Privileged server processes use the $CHECK_ACCESS system service to determine whether their clients should be allowed access to the protected objects being served. The $CHECK_ACCESS system service provides a calling interface appropriate for servers and is layered on top of the $CHKPRO service. As a result, it performs object access auditing in the same manner as $CHKPRO. 6.3 Developing an Auditing Plan As system manager or site security administrator, you have to determine the level of security required at your site before you can understand which security events to audit.
6-9 Security Auditing 6.3 Developing an Auditing Plan
6.3.1 Assessing Your Auditing Requirements Assessing your auditing requirements is a two-step process: 1. Determine your site's general security requirements: are they high, moderate, or low? Table 1-1 provides some guidance on determining your security needs. 2. Once you know your site's needs, refer to Table 6-4 for a suggested list of event classes to enable. After developing a general notion of your site requirements, you need to consider how much security reporting is realistic. Balance the suggestions in Table 6-4 with the following site factors: • The sensitivity of the data at your site • The amount of time you have to analyze log files • The disk space you have available • Your knowledge of a security threat: where is it coming from or likely to come from
Table 6-4 Events to Monitor Depending on a Site's Security Requirements Low Medium High Goal Monitor local events with Track changes to system Monitor network connections high impact definition and database changes; track use of process control system services Classes to ACL, authorization, break Same as low category plus Same as medium category Enable as in (all types), logfailure (all use of SECURITY privilege plus INSTALL, time, Alarms types) SYSGEN, unsuccessful privilege use Classes to ACL, authorization, breakin All of low category plus All of medium category plus Enable as (all types), logfailure (all INSTALL; time; SYSGEN; identifier, connection, NCP, Audits types) privilege; logins (all types); process, unsuccessful access logouts (all types); access to protected objects of files through BYPASS, SYSPRV, and READALL privileges; unsuccessful access to files, devices, and volumes
In Table 6-4, the event classes suggested for a low-security site are the default settings for the operating system. If these classes are not the current defaults on your system, you can enable them with the following command: $ SET AUDIT/ALARM/AUDIT/ENABLE=(ACL,AUTHORIZATION,BREAKIN:ALL,LOGFAILURE:ALL) In a site with moderate security requirements, you want to audit events that can redefine your system. You watch for changes to system files, system time, or system parameters. You also monitor image installations and the use of privilege. Example 6-3 shows the auditing setting for a site with moderate security requirements.
6-10 Security Auditing 6.3 Developing an Auditing Plan
Example 6-3 Auditing Events for a Site with Moderate Security Requirements System security alarms currently enabled for: Authorization Breakin: dialup,local,remote,network,detached System security audits currently enabled for: ACL Authorization INSTALL Time SYS GEN Breakin: dialup,local,remote,network,detached Login: batch,dialup,local,remote,network,subprocess,detached Logfailure: batch,dialup,local,remote,network,subprocess,detached Logout: batch,dialup,local,remote,network,subprocess,detached Privilege use: ACNT ALL SPOOL ALTPRI AUDIT BUG BYPASS CMEXEC CMKRNL DETACH DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT LOG IO MOUNT NETMBX OPER PFNMAP PHY IO PRMCEB PRMGBL PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL SYSLCK SYS NAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD Privilege failure: ACNT ALL SPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL DETACH DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT LOG IO MOUNT NETMBX OPER PFNMAP PHY IO PRMCEB PRMGBL PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL SYSLCK SYS NAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD FILE access: SYSPRV: read,write,execute,delete,control BYPASS: read,write,execute,delete,control READALL: read,write,execute,delete,control
To enable the settings for a moderate level of auditing, assuming the default events are already in effect, enter the following set of commands: $ SET AUDIT/ALARM/AUDIT/ENABLE=PRIVILEGE=(SUCCESS:SECURITY,FAILURE:SECURITY) $SET AUDIT/AUDIT/ENABLE=(INSTALL,SYSGEN,TIME,PRIVILEGE=(SUCCESS,FAILURE)) $ SET AUDIT/AUDIT/ENABLE=ACCESS=(BYPASS,SYSPRV,READALL)/CLASS=FILE $ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=(FILE,DEVICE,VOLUME) A site with high security requirements expands its auditing breadth to include network activity. It needs to monitor the creation of logical network connection, changes to the network database, the use of identifiers as privileges, and privileged file access. Monitor all file access through SYSPRV, BYPASS, or READALL privilege, and watch both successful and unsuccessful file access through GRPPRV privilege. To enable the settings for a high level of auditing, assuming a medium level is in effect, enter the following set of commands: $SET AUDIT/ALARM/ENABLE=(INSTALL,SYSGEN,TIME,PRIVILEGE=(FAILURE:ALL)) $ SET AUDIT/AUDIT/ENABLE=(CONNECTION,IDENTIFIER,NCP,PROCESS:ALL) $ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=* To enable all auditing: $ SET AUDIT/AUDIT/ENABLE=ALL/CLASS=* To disable all auditing: $ SET AUDIT/AUDIT/DISABLE=ALL/CLASS=* See Section 7 .3.2 for more suggestions of event classes to enable.
6-11 Security Auditing 6.3 Developing an Auditing Plan
6.3.2 Selecting a Destination for the Event Message The operating system can report a security event as either an alarm or an audit (see Section 6.2.1.1). Which form you select depends on the nature of the event. Real-time events or events that should be treated immediately, such as break-in attempts or changes to the system user authorization file (SYSUAF.DAT), are classes to enable as both alarms and audits. Less critical events can be enabled just as audits. Unless you have a hardcopy operator terminal, the alarm record is quickly superseded by other system messages. Audit event records, which are written to the system security audit log, are saved so you can study them in volume. There is an advantage to studying event messages. Many times an isolated auditing message offers little insight, but numerous audit records reveal a pattern of activity that might indicate security violations. With auditing of object access, for example, a security administrator can see a pattern of time, types of objects being accessed, and other system information that, in total, paint a complete picture of system activity. Section 6.5 describes how to produce reports from audit log files. 6.3.3 Considering the Performance Impact The default auditing performed by the operating system primarily tracks changes to the authorization databases. System events like changes to the system user authorization file (SYSUAF.DAT) or the installation of images do not occur too frequently and therefore are not a drain on system resources. Auditing additional event classes, particularly access events and privilege events, can consume significant system resources if a site enables the event classes without understanding how their system is used and without evaluating the value of the audit information. In this respect, implementation of the audit reporting system is similar to system tuning: it takes a little while to reach the appropriate level of reporting that is free of spurious details. For this reason, Digital recommends you turn auditing on in phases, not all at once, and gradually add or subtract event classes until you reach a satisfactory balance. Here are some rules: • Evaluate your auditing requirements, as described in Section 6.3.1. • Be selective in auditing object access events. Object access events occur all the time and therefore have the greatest impact on system performance. Audit file-access failures in most cases rather than successful file access, or put auditing ACEs on key files rather than enable auditing for the entire file class. • Examine the layered products you are running so you understand which privileges they may use. Also become familiar with site-specific procedures, such as the use of the READALL privilege during a .backup operation. Because privilege events occur frequently, they too have a great impact on system performance. • Enable a few event classes at a time and then add or subtract, if necessary, until you have sufficient event information. The more classes you enable, the more overhead you have and the fewer resources you have for useful work on the system.
6-12 Security Auditing 6.4 Methods of Capturing Event Messages
6.4 Methods of Capturing Event Messages The operating system can send event messages to an audit log file or to an operator terminal. If a site wants additional copies, it can send duplicate messages to a remote log file or an application listener mailbox. 6.4.1 Using an Audit Log File The operating system writes all security event messages to the latest version of the security audit log file. This log file is created by default during system startup in the SYS$COMMON:[SYSMGR] directory and named SECURITY.AUDIT$JOURNAL. Table 6-5 describes some of its more notable characteristics. Ordinarily, all cluster events are written to a single audit log file. The use of one security audit log file in a cluster results in a single record of all security-relevant events on the system. For this reason, one clusterwide log file is preferable to node-specific audit logs, which lose the interrelationship of events across the cluster, thus producing an incomplete analysis of security events. You can, if you wish, create node-specific audit logs (see Section 6.4.1.1), but this is not the recommended procedure.
Table 6-5 Characteristics of the Audit Log File Characteristic Advantage Binary A binary file requires the least amount of disk space. Clusterwide A clusterwide file, when processed by the Audit Analysis utility, results in one report of security-relevant events in the cluster. Sequential A sequential record format is easily analyzed by user-written programs. record format See the Open VMS System Management Utilities Reference Manual for a description of the message format of the security audit log file.
The usefulness of the security audit log file depends upon the procedures you adopt: • Maintain the log file (see Section 6.4.1.1) so events are recognized early and the file does not get too big. • Routinely review the log file and scrutinize suspicious activity (see Section 6.5). 6.4.1.1 Maintaining the File The security audit log file continues to grow until action is taken, so you must devise a plan for maintaining it. Typically, sites rename each day's log file and create a new one. To open a new, clusterwide version of the security audit log file, use the following command: $ SET AUDIT/SERVER=NEW_LOG To create a new, node-specific log, precede the SET AUDIT/SERVER=NEW_LOG command with the command SET AUDIT/DESTINATION=filespec where the file specification includes a logical name that resolves to a node-specific file (for example, SYS$SPECIFIC:[SYSMGRJSECURITY). Once you have opened the new log, rename the old version with a name that incorporates a beginning or ending date for the data.
6-13 Security Auditing 6.4 Methods of Capturing Event Messages
To save space on the system disk, you may want to copy the file to another disk and delete the log from the system disk. Even sites with a dedicated auditing disk, which is common to environments with high security requirements, may want to relocate the old version to make space for future messages. Once you archive the file, run the Audit Analysis utility on the old log (see Section 6.5.2). By archiving this file, you maintain a clusterwide history of auditing messages. If you ever discover a security threat on the system, you can analyze the archived log files for a trail of suspicious user activity during a specified period of time. 6.4.1.2 Moving the File from the System Disk To relocate the file from the SYS$COMMON:[SYSMGR] directory, edit the command procedure SYSECURITY.COM. This procedure executes each time the system is rebooted, before the audit server is started. To relocate the file, perform the following steps: 1. Change the startup sequence by adding a line to SYSECURITY.COM that directs the operating system to mount the designated auditing disk before the audit server process is started rather than after. For example: $ IF .NOT. F$GETDVI("$1$DUA2","MNT") - _$ THEN MOUNT/SYSTEM $1$DUA2 AUDIT AUDIT$ /NOREBUILD The command in this example mounts a volume labeled AUDIT on $1$DUA2 and makes it available systemwide. MOUNT also assigns the logical name AUDIT$. 2. Move the audit server database to the auditing disk, if you choose. The database remains small and fairly stable so this step is not essential. To move the database, add a second line to SYSECURITY.COM to define the system logical name VMS$AUDIT_SERVER. (The line follows the one that mounts the auditing disk.) In the command, define a system logical name and assign it to the VMS$AUDIT_SERVER data file on the disk with the logical name AUDIT$. For example: $DEFINE/SYSTEM/EXEC VMS$AUDIT_SERVER AUDIT$:[AUDIT]VMS$AUDIT_SERVER.DAT This command redirects the audit server database to the volume on $1$DUA2, which was mounted in step 1. 3. From the DCL level, redirect the security audit log file to the volume mounted in SYSECURITY.COM (see step 1). Use the SET AUDIT command to update the audit server database with the new location of the security audit log file, and instruct the audit server process on each node in the cluster to begin using the file. For example: $ SET AUDIT/JOURNAL=SECURITY - _$ /DESTINATION=AUDIT$:[AUDIT]SECURITY Do not repeat this command on each system restart. If you use a logical name in the specification of the security audit log file, it must be defined as a /SYSTEM logical name in SYSECURITY.COM.
6-14 Security Auditing 6.4 Methods of Capturing Event Messages
6.4.2 Enabling a Terminal to Receive Alarms The operating system sends alarm messages to terminals enabled for security class messages. In most cases, these security alarms appear on the system console by default. Because messages scroll quickly off the screen, it is good practice to enable a separate terminal for security class messages and disable message delivery to the system console. Choose either a terminal in a secure location that provides hardcopy output or have dedicated staff to monitor the security operator terminal. Any number of terminals can be enabled as security operators. To set up a terminal to receive security class alarms, enter the following DCL command from the designated terminal: $ REPLY/ENABLE=SECURITY For long-term use of a specific terminal, you can modify your site-specific startup command procedure to automatically enable the terminal. For example, the following command lines in a startup command procedure disable the delivery of security alarms to the system console and enable alarms on terminal TTA3: $ DEFINE/USER SYS$COMMAND OPAO: $ REPLY/DISABLE=SECURITY $ DEFINE/USER SYS$COMMAND TTA3: $ REPLY/ENABLE=SECURITY The authorization and SYSGEN event classes occasionally produce such lengthy alarm messages that the messages get truncated. For this reason, it is best to enable these classes for both alarms and audits. When an alarm message is truncated, the text indicates it is incomplete. As long as you have enabled the classes for audit messages, you can use ANALYZE/AUDIT to display the complete message. 6.4.3 Secondary Destinations for Event Messages The operator terminal and the audit log file are the primary destinations for security-event messages. A site can choose to send copies of audit messages to a remote log file (called an archive file) or a listener mailbox. 6.4.3.1 Using a Remote Log File The operating system allows workstations and other users with limited management resources to duplicate their audit log file on another node. This secondary log, the security archive file, is then available to a security administrator on a remote note who has the skills to analyze the file. In some situations, the archive file can also provide an insurance should the local audit log file be tampered with in some way. Only one node can direct auditing messages to an archive file. Once enabled, the audit server writes a copy of each auditing message to the security archive file as well as to the security audit log file. Use the following procedure to write security audit messages to a remote security archive file: 1. Log in to the node where the archive file is located, and create an account for the audit server. To the account, assign a user name like AUDIT_ARCHIVE; make the account unprivileged with only network access. Be sure the account has access to the device and directory containing the security archive file.
6-15 Security Auditing 6.4 Methods of Capturing Event Messages
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD AUDIT ARCHIVE /ACCESS=NETWORK /DEVICE=WORK2- _ UAF> /DIRECTORY=[AUDIT_ARCHIVE] 2. Add a proxy account on the remote node for AUDIT$SERVER. This allows the audit server process to write data to its account on the remote node. For example, the following commands grant the audit server process on node SMLNOD proxy access to the AUDIT_ARCHIVE account on node BIGNOD: UAF> ADD/PROXY SMLNOD::AUDIT$SERVER AUDIT ARCHIVE/DEFAULT UAF> EXIT - See Section 9.7 for further information about setting up proxy accounts. 3. Log out from the remote node. On the local node, enable archiving of the log file to the node by entering the following command: $SET AUDIT/ARCHIVE=ALL/DESTINATION=BIGNOD::WORK2:- _$ [AUDIT_ARCHIVE]SMLNOD_MAY_93.AUDIT$JOURNAL You must supply a complete directory specification. If you include any logical names, ensure the local audit server process can translate them. To create a new archive file, rename the current file; the next time the system starts up, it creates a new one for you. If the network goes down, messages intended for the security archive file are lost. Security operator terminals receive notice of the lost connection and the number of lost messages. Once the network is up, the audit server reestablishes connection to the original archive file and continues writing event messages. Analyzing the security archive file is identical, in most respects, to analysis of the security audit log file. You can analyze a remote security archive file at any time, even while the file is open. See Section 6.5 for more information. 6.4.3.2 Using a Listener Mailbox As an additional feature of the security auditing facility, you can create a listener device to receive a binary copy of all security-auditing messages. (A listener device is a permanent or temporary mailbox that you create with the Create Mailbox [$CREMBX] system service.) Security administrators can set up an application to receive and process auditing information and react to events as they occur on the system. Each system can have one listener device, and it can receive only events that are occurring on the local node. To enable the listener device to receive security-auditing messages, execute the , SET AUDIT/LISTENER command in the following format: SET AUDIT/LISTENER=device-name For the device-name parameter, supply either the logical name specified when you created the mailbox or the equivalence name of the mailbox, in the form of MBAn, where n represents the unit number of the mailbox. If you create the device as a temporary mailbox, you must use the Get Device and Volume Information ($GETDVI) system service to return the mailbox device name. To disable a listener device, enter the following command:
$ SET AUDIT/NOLISTENER
6-16 Security Auditing 6.4 Methods of Capturing Event Messages
Refer to the files AUDSRV_LISTENER.B32 (a VAX BLISS program) and AUDSRV_LISTENER.MAR (a VAX MACRO program) in the SYS$EXAMPLES directory for examples of a program that processes audit-event messages sent to a listener mailbox on a DECtalk device. 6.5 Analyzing a Log File Collecting security audit messages in the security audit log file is useless without periodically reviewing it for suspicious activity. You use the Audit Analysis utility (ANALYZE/AUDIT) to examine the data in the security audit log file. ANALYZE/AUDIT generates a report from the log file so that you become familiar with normal activity on your system and can easily spot atypical activity. It summarizes events for you and plots where activity is occurring on the cluster. The utility also helps you analyze atypical activity because it is capable of selecting a subset of information from an audit report and of providing fuller information for your analysis. While the analysis of a single audit log file might not be significant, audit records can, over time, reveal a pattern of activity that indicates security violations. 6.5.1 Recommended Procedure This section describes how to analyze audit log files on your system. Although the way you use ANALYZE/AUDIT depends upon the security needs at your site, there are a number of common steps that you should follow, regardless of the extent to which you use the utility. Before you can recognize potential security problems, you need to become familiar with the normal operation of your system. Then you can develop a procedure for generating and reviewing audit reports on a periodic basis. Whenever your regular analysis of audit log files leads you to suspect a security problem, you should perform a detailed investigation of selected security events. Step 1 : Know What Is Normal As a security administrator, you should be able to answer the following questions before analyzing an audit log file: • What are the typical hours of operation for most users of the system? • Are there specific users who normally operate with advanced privileges? • Which images generate system security events as part of other applications? • Are there any regular batch or network jobs that run at specific times of the day? By knowing the answers to these questions, you can eliminate false alarms, which otherwise may cause you to wrongly suspect a security problem. Step 2: Periodically Analyze the Audit Report The most common type of report to generate is a brief, daily listing of events. You can create a command procedure that runs in a batch job every evening before midnight to generate a report of the day's security event messages. (You can use the same procedure to create a new version of the audit log [see Section 6.4.1.1].)
6-17 Security Auditing 6.5 Analyzing a Log File
The following example shows the ANALYZE/AUDIT command line to generate this report: $ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31DEC1993.AUDIT - 0 $ SYS$MANAGER:SECURITY.AUDIT$JOURNAL $ MAIL/SUBJECT="Security Events" 31DEC1993.AUDIT SYSTEM 8 0 The first command in this example produces an audit report named 31DEC1993.AUDIT, which contains one-line descriptions of all the security event messages generated during the current day. @ The second command mails the file to the security administrator for examination. Depending on the number of security events that you are auditing on your system, it can be impractical to review every audit record written to the audit log file. In this case, you can select a specific set of records from the log file, such as all audit records related to changes in the authorization database and break-in attempts, or all events occurring outside normal business hours. It is important that you review audit reports as soon as possible. The sooner you inspect the reports, the sooner you become aware of any possible breach of security on the system and can determine the extent of the problem. You can make the inspection of the previous day's audit report a regular part of your morning routine, or you can create a program that reviews the report and notifies you through the Mail utility (MAIL) when suspicious events appear. Step 3: Scrutinize Suspicious Activity If, during your review, you find any security events that appear suspicious or out of place, like login attempts outside normal business hours, then use the Audit Analysis utility to perform a more detailed inspection of the security audit log file. A full report can help you determine which security events logged to the audit log file warrant a more thorough investigation. The following command generates a full report of selected security audit records: $ ANALYZE/AUDIT/FULL/SINCE=TODAY/OUTPUT=31DEC1993.AUDIT - $ /EVENT TYPE=(BREAKIN,RIGHTSDB,SYSUAF) $ MAIL/SUBJECT="Security Events" 31DEC1993.AUDIT SYSTEM The audit report for December 31, 1993 contains information on all break in attempts and all modifications to the system user authorization file (SYSUAF.DAT) and the rights database (RIGHTSLIST.DAT). 6.5.2 Invoking the Audit Analysis Utility The Audit Analysis utility is the tool you use to produce a meaningful report from a binary log file. This section and the sections that follow describe how to use the utility, but refer to the Open VMS System Management Utilities Reference Manual for complete documentation of the utility's commands and qualifiers. To invoke the Audit Analysis utility, use the following DCL command: ANALYZE/AUDIT file-riame For the file-name parameter, substitute the name of the file from which audit reports are to be generated. The default name of the security audit log file is SECURITY.AUDIT$JOURNAL. You must specify the directory: SYS$MANAGER.
6-18 Security Auditing 6.5 Analyzing a Log File
6.5.3 Providing Report Specifications With the Audit Analysis utility, you are able to extract all or some of the security event messages from a single audit log and produce reports with various levels of detail. The audit report reflects events from the set of event classes a site has enabled (see Section 6.2). You can tailor the report so only a subset of events are extracted. The selection criteria can be based on time, on event class, or on field of data within the event message. (See the documentation of the /SELECT qualifier in the Open VMS System Management Utilities Reference Manual.) Table 6-6 summarizes the qualifiers that determine the content of the report.
Table 6-6 Qualifiers for the Audit Analysis Utility Type Qualifier Description Content /BEFORE Extracts event messages logged prior to the specified time. /SINCE Extracts event messages logged after the specified of time. /EVENT_TYPE Extracts event messages of a specific event class (see Table 6-3). /SELECT Extracts event messages based on data in the messages. (For example, /SELECT=USERNAME=JSNOOP lists only security event messages generated by user JSNOOP.) /IGNORE Excludes event messages from the report based on data in the messages. Format /BRIEF Produces a report with one line of information about each record in the audit log file, such as the type of event, when it occurred, and the terminal from which it originated (see Example 6-4). This is the default. /FULL Provides all possible data for each record in the audit log file being processed (see Example 6-5). Appendix D provides sample alarm messages for each event class. /SUMMARY Lists the total number of audit messages for each event class in the log file being analyzed (see Example 6-6). It can also plot the aggregate events per hour on each node. /BINARY Produces a binary file so you can extract records for further analysis using your own data reduction tools. See the Open VMS System Management Utilities Reference Manual for a description of the audit message record format. Destination /OUTPUT Specifies the report destination. By default, it goes to SYS$0UTPUT.
ANALYZE/AUDIT produces audit reports in different formats (see Table 6-6). The utility produces a one-line summary of each record in the log file by default. Brief, one-line reports are most useful for routine analysis of a log file. The more detailed full reports provide the detail necessary for analyzing records of a suspicious nature. If you are interested in archiving portions of a log file, the binary listing lets you store a subset of an audit log file.
6-19 Security Auditing 6.5 Analyzing a Log File
A summary report helps you identify potential security problems quickly. For each class of security event, a summary report can list the total number of audit messages extracted from the security audit log file being analyzed. A summary report can also display a plot of auditing activity, based on the system generating the event message, the time when it occurred, and the total number of events seen. Example 6-4 shows a brief report of all the security audit events logged to the system security audit log file. In the ANALYZE/AUDIT command that generates the report, substitute the name of your audit log file.
Example 6-4 Brief Audit Report $ANALYZE/AUDIT/BRIEF SYS$MANAGER:SECURITY.AUDIT$JOURNAL
Date I Time Type Subtype Node Username ID Term 1-NOV-1993 16:00:03.37 ACCESS FILE ACCESS HERE SYSTEM 5B600AE4 1-NOV-1993 16:00:59.66 LOGIN SUBPROCESS GONE ROBINSON 3BA011D4 1-NOV-1993 16:02:37.31 LOGIN SUBPROCESS GONE MILANT 00000005 1-NOV-1993 16:06:36.40 LOGFAIL LOCAL SUPER MBILLS OOOOOOE5 TTAl:
Example 6-5 shows one record from a full format audit report. In the ANALYZE /AUDIT command that generates the report, substitute the name of your audit log file.
Example 6-5 One Record from a Full Audit Report $ ANALYZE/AUDIT/FULL SYS$MANAGER:SECURITY.AUDIT$JOURNAL
Security audit (SECURITY) on FNORD, system id: 19728 Auditable event: Object access Event time: 6-AUG-1993 11:54:16.21 PIO: 30200117 Process name: Hobbit Username: PATTERSON Process owner: [ACCOUNTING,PATTERSON] Terminal name: RTAl: Object class name: LOGICAL NAME TABLE Object name: LNM$SYSTEM DIRECTORY Access requested: WRITE - Status: %SYSTEM-S-NORMAL, normal successful completion Privileges used: SYSPRV
Example 6-6 shows a summary report. In the ANALYZE/AUDIT command that generates the report, substitute the name of your audit log file.
6-20 Security Auditing 6.5 Analyzing a Log File
Example 6-6 Summary of Events in an Audit Log File $ ANALYZE/AUDIT/SUMMARY
Total records read: 9701 Records selected: 9701 Record buffer size: 1031 Successful logins: 542 Object creates: 1278 Successful logouts: 531 Object accesses: 3761 Login failures: 35 Object deaccesses: 2901 Breakin attempts: 2 Object deletes: 301 System UAF changes: 10 Volume (dis)rnounts: 50 Rights db changes: 8 System time changes: 0 Netproxy changes: 5 Server messages: 0 Audit changes: 7 Connections: 0 Installed db changes: 50 Process control audits: 0 Sysgen changes: 9 Privilege audits: 91 NCP command lines: 120
6.5.4 Using the Audit Analysis Utility Interactively When you send output to a terminal, you can analyze an audit log file interactively. At any time during the display of a listing, you can interrupt the report being displayed by pressing Ctrl/C. This automatically initiates a full listing and gives you the Command> prompt. In command mode, you can advance or return to earlier records in the report and study them in greater detail. At the Command> prompt, you can enter any of the ANALYZE/AUDIT commands listed in the Open VMS System Management Utilities Reference Manual to modify the analysis criteria, to change position within the audit report, or to toggle between full and brief displays. To return to an audit report listing, enter the CONTINUE command. 6.5.5 Examining the Report When a routine analysis of an audit log file leads you to suspect that the security of your system has been compromised (through an actual or attempted break- in, repeated login failures, or any other suspicious security events), you can investigate the source of the security event through a more detailed inspection of the security audit log file. For example, assume that you see the security events shown in Example 6-7 during a routine inspection of the previous day's audit report.
6-21 Security Auditing 6.5 Analyzing a Log File
Example 6-7 Identifying Suspicious Activity in the Audit Report
Date I Time Type Subtype Node Username ID Term
26-0CT-1993 16:06:09.17 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA RTA14: 26-0CT-1993 16:06:22.01 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA -RTA14: 26-0CT-1993 16:06:34.17 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA -RTA14: 26-0CT-1993 16:06:45.50 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA -RTA14: 26-0CT-1993 16:07:12.39 LOGIN REMOTE BOSTON KOVACS 5BC002EA -RTA14: 26-0CT-1993 16:23:42.45 SYSUAF SYSUAF ADD BOSTON KOVACS 5BC002EA -RTA14:
The security events displayed in the report shown in Example 6-: 7 indicate that user Kovacs logged in to the system following four unsuccessful login attempts. Shortly after logging in, user Kovacs created a new account in the system user authorization file (SYSUAF.DAT). At this point, you must determine whether this behavior is normal or abnormal. Is user Kovacs authorized to add new user accounts to the system? If you believe that the security of your system has been compromised, use the following command to generate a more detailed report from the security audit log file to determine if damage has been done to your system: $ ANALYZE/AUDIT/FULL/SINCE=26-0CT-1993:16:06 The command in this example generates a full report of all security audit events written to the audit log file since user Kovacs first attempted to log in to the system. In a full format report, all the data for each record in the audit log file is displayed. Using the full report, you can determine the name of the remote user who logged in under the local KOVACS account and the node from which the login was made, as shown in Example 6-8.
6-22 Security Auditing 6.5 Analyzing a Log File
Example 6-8 Scrutinizing a Suspicious Record
Security alarm (SECURITY) and security audit (SECURITY) on BOSTON, system id: 19941 Auditable event: Remote interactive login failure Event time: 26-0CT-1993 16:06:09.17 PID: 5BC002EA Username: KOVACS Terminal name: RTA14: Remote nodenarne: NACHWA Remote node id: 7300 Remote username: FOLLEN Status: %LOGIN-F-INVPWD, invalid password
Security alarm (SECURITY) and security audit (SECURITY) on BOSTON, system id: 19941 Auditable event: Remote interactive login Event time: 26-0CT-1993 16:07:12.39 PID: 5BC002EA Usernarne: KOVACS Terminal name: RTA14: Remote nodenarne: NACHWA Remote node id: 7300 Remote username: FOLLEN
The information displayed in Example 6-8 indicates that the login failures and subsequent successful login were made by user Follen from the remote node NACHWA. Your next step is to determine whether the security events were generated by user Follen or by someone who has broken into the remote node NACHWA through the FOLLEN account. 6.6 Managing the Auditing Subsystem This section discusses how to manage the auditing system. Management tasks include the following: • Enabling and disabling startup of the audit server process • Changing the point in startup when the operating system initiates auditing • Choosing the number of outstanding messages that trigger process suspension • Choosing the audit server response to memory exhaustion • Maintaining the accuracy of message time-stamping • Adjusting the transfer of messages from system auditing buffers to disk • Choosing the amount of disk space periodically allocated to the system audit log 6.6.1 Tasks Performed by the Audit Server The operating system creates the audit server as a detached process during system startup to perform the following tasks: • Create a clusterwide security audit log file (SECURITY.AUDIT$JOURNAL) in SYS$COMMON:[SYS$MGR] • Control the logging of security events to the log file and the delivery of alarms to any operator terminals enabled to receive security class messages
6-23 Security Auditing 6.6 Managing the Auditing Subsystem
• Enable auditing of a site-defined set of security events • Monitor disk and memory resources • Maintain a database of security-auditing characteristics The audit server sends informational and error messages to OPCOM. OPCOM broadcasts these messages to operator terminals and writes the messages to the operator log file. Figure 6-1 displays the audit server's initial operating values. These settings are stored in the audit server database, VMS$AUDIT_SERVER.DAT in SYS$COMMON:[SYSMGR]. Any time you modify security-auditing characteristics by using the DCL command SET AUDIT, the audit server database is updated. Each time the system is rebooted, it takes the auditing values from this database.
Figure 6-1 Default Characteristics of the Audit Server
$ SHOW AUDIT/ALL List of audit journals: Journal name: SECURITY Journal owner: (system audit journal) Destination: SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL Monitoring: enabled Warning thresholds, Block count: 100 Duration: 2 00:00:00.0 Action thresholds, Block count: 25 Duration: 0 00:30:00.0 Security auditing server characteristics: Database version: 4.4 Backlog (total): 100, 200, 300 Backlog (process): 5, 2 Server processing intervals: Archive flush: 0 00:01:00.00 Journal flush: 0 00:05:00.00 Resource scan: 0 00:05:00.00 Final resource action: purge oldest audit events Security archiving information: Archiving events: none Archive destination: System security alarms currently enabled for: ACL Authorization Breakin: dialup,local,remote,network,detached Logfailure: batch,dialup,local,remote,network,subprocess,detached System security audits currently enabled for: ACL Authorization Breakin: dialup,local,remote,network,detached Log failure: batch,dialup,local,remote,network,subprocess,detached
6-24 Security Auditing 6.6 Managing the Auditing Subsystem
6.6.2 Disabling and Reenabling Startup of the Audit Server All operating systems start the audit server process and the operator communication manager (OPCOM) by default. If the physical memory or disk storage space on your system is especially limited and logging of security-related events is not important, you can remove the audit server and OPCOM processes from the system startup procedure. Before you do so, be aware that cluster object support requires the audit server (see Chapter 8). The following example shows how you would remove these processes with the System Management utility (SYSMAN): $ SET PROCESS/PRIVILEGES=(OPER,BYPASS) $ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP VMS SYSMAN> STARTUP DISABLE FILE VMS$CONFIG-050 OPCOM.COM/NODE=* SYSMAN> STARTUP DISABLE FILE VMS$CONFIG-050-AUDIT SERVER.COM /NODE=* SYSMAN> EXIT - - $ SET PROCESS/PRIVILEGES=(NOOPER,NOBYPASS) To delete the audit server process and to shut down security auditing on the system, enter the following commands on each node in the cluster: $ SET AUDIT/ALARM/AUDIT/DISABLE=ALL/CLASS=* $ SET AUDIT/SERVER=EXIT You can restart security auditing and OPCOM on the system by executing the following DCL command lines: $ @SYS$SYSTEM:STARTUP OPCOM $ @SYS$SYSTEM:STARTUP VMS$AUDIT_SERVER To start the OPCOM and the audit server processes for all subsequent system boots, reverse your previous edits of the system startup procedure. Use the following SYSMAN commands: $ SET PROCESS/PRIVILEGES=(OPER,BYPASS) $ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP VMS SYSMAN> STARTUP ENABLE FILE VMS$CONFIG-050 OPCOM.COM/NODE=* SYSMAN> STARTUP ENABLE FILE VMS$CONFIG-050-AUDIT SERVER.COM - SYSMAN> /NODE=* - - SYSMAN> EXIT $ SET PROCESS/PRIVILEGES=(NOOPER,NOBYPASS) See the Open VMS System Management Utilities Reference Manual for more information about the SYSMAN utility. 6.6.3 Changing the Point in Startup When the Operating System Initiates Auditing Ordinarily, the operating system starts sending audit-event messages just before SYSTARTUP_VMS.COM executes. However, a site that is not interested in receiving audit-event messages during startup can alter this behavior by redefining the logical name SYS$AUDIT_SERVER_INHIBIT.
6-25 Security Auditing 6.6 Managing the Auditing Subsystem
To change the point where the operating system begins to deliver security-event messages, add the following line to the SYS$STARTUP:SYLOGICALS.COM command procedure: $ ! $ DEFINE /SYSTEM /EXECUTIVE SYS$AUDIT SERVER INHIBIT yes $ ! - - A system manager can choose another phase of system startup to initiate auditing, perhaps at the end of SYSTARTUP_VMS. However, be sure to initiate auditing before allowing any general logins to the system (that is, before any SET LOGINS/INTERACTIVE command). To initiate delivery of auditing messages, add the following line to the appropriate command file: $ $ SET AUDIT/SERVER=INITIATE $ ! 6.6.4 Choosing the Number of Outstanding Messages That Trigger Process Suspension Unless the audit server controls the influx of messages, it is possible under some conditions to run out of memory. A very slow I/O device, a disk space problem, or even a sudden onslaught of messages can exceed the server's ability to write messages to disk. To prevent memory exhaustion, the audit server constantly monitors the total number of outstanding messages and tallies the number of messages contributed by each active process. If the server receives more events than it can log to disk, it begins applying flow control to those processes generating audit events. 6.6.4.1 Controlling Message Flow Message volume is controlled on a per-process basis. Table 6-7 shows the three stages of flow control: 1. When there are 100 messages in memory, the operating system suspends any process that has five or more outstanding messages. Once a process has all its messages written to the log file, it can resume processing. 2. When there are 200 messages in memory, the operating system suspends any process that has submitted two or more messages until all messages are written to disk. 3. When there are 300 messages in memory, any process with messages in memory is suspended until all messages are written to disk.
Table 6-7 Controlling the Flow of Audit Event Messages Control Stages Total Message Backlog (Default) Process Backlog Limit (Default) 1 100 5 2 200 2 3 300 None
You can establish site-specific values for controlling messages by using the /BACKLOG qualifier to the SET AUDIT command. For example, the following command raises the action thresholds so that the operating system starts controlling the influx of messages when it has 125 unprocessed messages in its queue and a contributing process has eight messages outstanding.
6-26 Security Auditing 6.6 Managing the Auditing Subsystem
$SET AUDIT/BACKLOG=(TOTAL=(125,250,350),PROCESS=(8,4)) 6.6.4.2 Preventing Process Suspension Naturally, the operating system never suspends certain critical processes. Realtime processes and any of the following processes are exempt: CACHE_SERVER OPCOM CLUSTER_SERVER REMACP CONFIGURE SHADOW_SERVER DFS$COM_ACP SMISERVER DNS$ADVER SWAPPER IPCACP TP_SERVER JOB_CONTROL VWS$DISPLAYMGR NETACP VWS$EMULATORS NET$ACP The system administrator can prevent the suspension of a process by adding its process identifier (PID) to the process exclusion list. Use the following form of the SET AUDIT command: SET AUDIT/EXCLUDE=process-id Be aware that processes (PIDs) are not automatically removed from the process exclusion list when processes log out of the system. To remove a process from the exclusion list, use the SET AUDIT/NOEXCLUDE command. Processes excluded by the operating system cannot be removed. 6.6.5 Reacting to Insufficient Memory When processes on the exclusion list (see Section 6.6.4.2) produce so many audit messages that the audit server runs out of memory, the default behavior of the audit server is to remove old event messages until memory is available. It saves the most current messages. The audit server has other alternatives when it encounters memory limitations:
Option Description Crash Crash the system if the audit server runs out of memory. lgnore_New Ignore new event messages until memory is available. New event messages are lost but event messages in memory are saved. Purge_Old Remove old event messages until memory is available for the most (default) current messages.
To alter the default behavior of the audit server and instruct it to ignore all new audit messages rather than purge the old ones, enter the following command: $ SET AUDIT/SERVER=FINAL_ACTION=IGNORE_NEW The audit server runs with a fixed virtual memory limit (PGFLQUOTA) of 20,480 pages. This may be further limited by the size of page files installed on the system. You can adjust the size of page files by running AUTOGEN. Whenever it detects a page file problem, AUTOGEN automatically resets the size to allev!ate the problem.
6-27 Security Auditing 6.6 Managing the Auditing Subsystem
6.6.6 Maintaining the Accuracy of Message Time-Stamping If you are auditing a set of security events in which the order of occurrence is important, all clocks within a cluster need to remain synchronized. This ensures that message time-stamping on all nodes in the cluster closely reflects the order in which events occurred. Because each node in a cluster configuration maintains time independently, it is possible for cluster times to drift apart over time. To prevent drifting, use the SYSMAN command CONFIGURATION SET TIME at regular intervals. The Open VMS System Management Utilities Reference Manual provides a sample command procedure that you can run every hour to maintain clock synchronization to within a second. 6.6. 7 Adjusting the Transfer of Messages to Disk The audit server stores security-event messages in memory and periodically transfers groups of messages from its buffers to the audit log file on disk. Usually, the audit server transfers auditing messages every 5 minutes and archived messages (see Section 6.4.3.1) every minute. Except for some high security environments and instances where extreme numbers of audit messages are being generated on the system, this default should be sufficient. High-security sites can transfer event messages to disk at higher-than-normal rates by modifying the interval of log transfer operations. The following command, for example, changes the audit server's characteristics so it writes event messages to the audit log file every 2 minutes: $ SET AUDIT/INTERVAL=JOURNAL_FLUSH=00:02 Frequent message transfers can impact system performance, however, because the system performs more 1/0 operations rather than store messages in the system buffers associated with the audit server process. To immediately force all audit messages to the log file, enter the following command: $ SET AUDIT/SERVER=FLUSH 6.6.8 Allocating Disk Space for the Audit Log File The audit server constantly monitors the disk space allocated to the security audit log file to ensure there is adequate space for event messages. Whenever the file runs low on available blocks, the audit server extends the audit log file. If disk resource limitations prevent the server from allocating more blocks to the log file, it takes one of the following actions: • Warn you by sending warning messages to the operator terminal. This occurs by default when less than 100 disk blocks are available. The following command changes the default so the warning occurs when 150 blocks are available: $ SET AUDIT /THRESHOLD=WARNING=l50 • Take action by suspending processes that are generating audit records. (Certain processes are immune to this: see Section 6.6.4.2.) When resource monitoring is enabled for the log file, process suspension occurs when less than 25 disk blocks are available.
6-28 Security Auditing 6.6 Managing the Auditing Subsystem
To modify the action threshold to 50 blocks, enter the following command: $ SET AUDIT /THRESHOLD=ACTION=50 The threshold values may be expressed in blocks or as a delta time. Delta time values are multiplied by the average space consumption rate to yield a number of blocks. The maximum of the block and time threshold values is used as the active threshold value. 6.6.9 Error Handling in the Auditing Facility Resources consumed by the OpenVMS security-auditing facility vary with the number and type of system events being recorded. Three different error conditions can develop related to the auditing facility: • The audit server can run out of memory. Section 6.6.5 describes different methods of handling the situation. • The disk storing the audit log file can run out of space. • The network connection for a remote log file (archive file) can break. This section discusses the default behavior of the auditing system in monitoring disk space and logging to an archive file. 6.6.9.1 Disabling Disk Monitoring The audit server monitors the audit log file and regularly pre-extends its disk block allocation to ensure there is adequate space for incoming event messages. Whenever disk space is unavailable, the server first warns you through operator messages and then resorts to suspending certain contributing processes (see Section 6.6.8). You can disable resource monitoring altogether by entering the following command: $ SET AUDIT/JOURNAL=SECURITY/RESOURCE=DISABLE However, if you disable disk resource monitoring, you eliminate the opportunity to receive warning messages until it is too late. The audit server begins to suspend processes that are generating too many audits, as Section 6.6.4 describes, and if it runs out of memory, the server takes the action described in Section 6.6.5: it ignores messages, purges old messages, or, possibly, crashes the system. Once disk space becomes available, the audit server extends the log file and resumes any processes it suspended. 6.6.9.2 Losing the Link to a Remote Log File If you are writing auditing messages to a remote log file, as described in Section 6.4.3.1, the link between the local and remote node can fail. Should this happen, the audit server broadcasts a warning message to all operator terminals and attempts to reestablish the link every minute until the connection is made.
6-29
7 System Security Breaches
Along with developing a security policy and selecting appropriate security measures to implement that policy, a site needs to establish and test procedures for handling system, site, or network compromises. The procedure should address two areas: • Appropriate responses once a breach is suspected or confirmed. Site guidelines should help determine whether to increase site security (eliminating all possibility of further compromise), put proactive measures in place to apprehend the offender, or collect evidence to initiate a criminal or civil suit. Each decision has its· own set of rules and guidelines. • Appropriate contacts and resources outside of the site that may be needed should such an event occur. For example, a company might want to become familiar with local, state, and federal authorities (as applicable), local phone carriers (security division), and the Digital support groups.1 This chapter describes how to recognize when an attack on the system is in progress or has taken place and what countermeasures can be taken. 7.1 Forms of System Attacks Security administrators must monitor the system on a regular basis for possible security breaches. Following are the most common forms of system attacks: • Hunting for access lines • Hunting for passwords • Attempting a break-in • Changing or creating user authorization file (UAF) records • Granting/stealing extra privileges • Introducing apparently innocent software (Trojan horse software) that is intended to steal user passwords or do other damage to the system • Introducing worms in command procedures and programs to gain access to privileged accounts • Scavenging disks • Using a node as a gateway to other nodes
1 Digital support groups include the Software Security Response Team (SSRT) in the United States and the European Security Program Office (ESPO).
7-1 System Security Breaches 7.2 Indications of Trouble
7.2 Indications of Trouble When your system is vulnerable and possibly under attack, your first indications may come from the following sources: • Reports from users • Monitoring the system, for example: Unexplained changes or behavior in applications or normal processes Unexplained messages from OPCOM or the audit server Unexplained changes to user accounts in the system authorization database (privilege changes, protections, priorities, quotas) 7 .2.1 Reports from Users User observations frequently point to system security problems. A user may contact you with the following situations: • Files are missing. • There are unexplained forms of last login messages, such as successful logins the user did not perform or unexplained login failures. • A user cannot log in, suggesting the user password might have been changed since the last successful login, or some other form of tampering has occurred. • Break-in evasion appears to be in effect, and the user cannot log in. • Reports from the SHOW USERS command indicate that the user is logged in on another terminal when the user did not do so. • A disconnected job message appears during a login for a process the user never initiated. • Files exist in the user's directories that the user did not create. • Unexplained changes have been found in the protection or ownership of user files. • Listings appear that are generated under the user name without the user requesting the listing. • A sudden reduction occurs in the availability of resources, such as dialup lines. Follow up promptly when one of these items is reported to you. You must confirm or deny that the condition exists. If you find the complaint is valid, seek a cause and solution. 7.2.2 Monitoring the System Section 5.19 lists those tasks that can help you detect potential security breaches on your system. The following list details possible warning signs you may uncover while performing the recommended tasks: • A user appears on the SHOW USERS report that you know could not be currently logged in. • You observe an unexplained change in the system load. • You discover media or program listings are missing or notice other indications that physical security has degraded.
7-2 System Security Breaches 7.2 Indications of Trouble
• Your locked file cabinet has been tampered with, and the list of authorized users has disappeared. • You find unfamiliar software in the system executable image library [SYSEXE] or in [SYSLIB]. • You observe unfamiliar images running when you examine the MONITOR SYSTEM report. , • You observe unauthorized user names when you enter the DCL command SHOW USER. When you examine the listing that the Authorize utility (AUTHORIZE) produces with the SHOW command, you find that those users have been given system access. • You discover proxy users that you never authorized. • The accounting report reveals unusual amounts of processing time expended recently, suggesting outside access. • You observe unexplained batch jobs on the batch queues. • You observe unexpected device allocations when you enter the SHOW DEVICE command. • You observe a high level of processing activity at unusual hours. • The protection codes or the access control lists (ACLs) change on critical files. Identifiers are added, or holders of identifiers are added to the rights list.
0 There is high personnel turnover or low morale. All these conditions warrant further investigation. Some indicate that you already have a problem, and some may have simple explanations, while others may indicate serious potential problems. 7.3 Routine System Surveillance The operating system provides a number of mechanisms that allow systematic surveillance of the activity in your system. Proper use of such mechanisms should help alert you to problems and allow you to intervene. This section describes the most important system surveillance mechanisms: • Accounting utility (ACCOUNTING) • Audit Analysis utility (ANALYZE/AUDIT) 7.3.1 System Accounting You can learn what the normal pattern of resource use is by studying reports of the Accounting utility (ACCOUNTING). To obtain a report, you run the utility image SYS$SYSTEM:ACC.EXE. The resulting data file is SYS$MANAGER:ACCOUNTNG.DAT. Review ACCOUNTING reports because they can provide early indications of problems. Check for the following: • Unfamiliar user names • Unfamiliar patterns of use, such as unusual activity for a particular time of day or day of week • Use of an unusual amount of resources • Unfamiliar sources of login, such as network nodes or remote terminals
7-3 System Security Breaches 7.3 Routine System Surveillance
7.3.2 Security Auditing As the security administrator, you can have the operating system report on security-related activity by enabling categories of events for auditing using the DCL command SET AUDIT. Using the Audit Analysis utility (ANALYZE/AUDIT), you can periodically review event messages collected in the security audit log file. (See Chapter 6 for a full description of the process.) The operating system can send event messages to an audit log file or to an operator terminal. You define whether events are reported as audits or alarms in the following way: • Ordinarily, enable audits rather than alarms for security-related events because the audit records are written to the system security audit log where you can study them in volume and archive log files for future reference. While an isolated auditing message may offer little insight, numerous audit records produce a pattern of security violations. For example, with auditing of object access, you can see a pattern of time, types of objects being accessed, and other system information that, in total, paint a picture of how the system is being used at different times of day. To enable audits for unsuccessful access to files, devices, and volumes, enter the following command: $ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=(FILE,DEVICE,VOLUME) This command records unsuccessful access events in the security audit log file but sends no alarms to the operator terminal. • Enable security alarms for real-time events or events that should be reviewed immediately, for example, break-in attempts or changes to the system user authorization file (SYSUAF.DAT). For example, to enable alarms for modification to the known file list and changes to system time, enter the following command: $ SET AUDIT/ALARM/ENABLE=(INSTALL,TIME) This command sends event messages to the operator terminal. To keep a hardcopy record of these alarms, use a hardcopy operator terminal, or enable the events as both alarms and audits. Because security auditing affects system performance, enable auditing only for the most important events. The following security-auditing actions are presented in order of decreasing priority and increasing system cost: 1. Enable security auditing for login failures and break-ins. This is the best way to detect probing by outsiders (and insiders looking for accounts). All sites needing security should enable alarms for these events. 2. Enable security auditing for logins. Auditing successful logins from the more suspicious sources like remote and dialup users provides the best way to track which accounts are being used. An audit record is written before users logging in to a privileged account can disguise their identity. 3. Enable security auditing for unsuccessful file access (ACCESS=FAILURE). This technique audits all file-protection violations and is an excellent method of catching probers.
7-4 System Security Breaches 7.3 Routine System Surveillance
4. Apply ACL-based file access auditing to detect write access to critical system files. The most important files to audit are shown in Table 7-1. (Table 6-2 presents an example of how to establish security entries in ACLs.) You may want to audit only successful access to these files to detect penetrations, or you may want to audit access failures to detect probing as well. Note that some of the files in Table 7-1 are written during normal system operation. For example, SYSUAF.DAT is written during each login, and SYSMGR.DIR is written when the system boots.
Table 7-1 System Files Benefiting from ACL-Based Auditing Device and Directory File Name SYS$SYSTEM AUTHORIZE.EXE FllBXQP.EXE LOGINOUT.EXE DCL.EXE JOBCTL.EXE SYSUAF.DAT NETPROXY.DAT RIGHTSLIST.DAT STARTUP.COM VMS$0BJECTS.DAT SYS$LIBRARY SECURESHR.EXE SECURESHRP.EXE SYS$MANAGER VMS$AUDIT_SERVER.DAT SY*.COM VMSIMAGES.DAT SYS$SYSROOT [OOOOOO]SYSEXE.DIR [OOOOOOJSYSLIB.DIR [OOOOOOJSYS$LDR.DIR [OOOOOO]SYSMGR.DIR
5. Enable security auditing for modifications to system parameters or the known file list (/ENABLE=(SYSGEN,INSTALL)). 6. Audit use of privilege to access files (either write access or all forms of access). Implement the security audit with the keywords ACCESS=(SYSPRV,BYPASS,READALL,GRPPRV). Note that this class of auditing can produce a large volume of output because privileges are often used in normal system operation for such tasks as mail delivery and operator backups. Section 6.3 provides further discussion of recommended sets of security events to audit.
7-5 System Security Breaches 7.4 Handling a Security Breach
7.4 Handling a Security Breach There are four phases that security administrators experience while handling a security breach, whether the breach actually occurred or was attempted: 1. Detection of a problem 2. Identification of the perpetrator 3. Prevention of further security violations 4. Repair of damage The following sections describe these phases for both attempted and successful break-ins. In all phases, train personnel to retain information and data as evidence, should there be a need to apprehend and prosecute the perpetrator. 7.4.1 Unsuccessful Break-In Attempts Unsuccessful break-in attempts include situations where someone has attempted to guess passwords or browse through files. 7.4.1.1 Detection of the Break-In Attempt You usually detect break-in attempts through the following sources: • Reports from users about unexplained login failures • Unusual system activity or unavailability of dialup lines • Security alarms for login failures, break-in attempts, and file-protection violations • Examination of the break-in database 7.4.1.2 Identifying the Perpetrator Enabling file auditing simplifies identification of file browsers. If, however, browsing is being initiated from another node in the network, you must inspect the network server log file (NETSERVER.LOG) that corresponds to the times of the protection violations. Coordinate your investigation with the security administrator at the remote node. Identifying a perpetrator who is guessing passwords is considerably more difficult, especially when the source is anonymous, as from a dialup line. Usually, you must trade identification for prevention. Often the only way to positively identify an outsider attempting to enter the system requires that you permit further attempts while establishing the perpetrator's identity. 7.4.1.3 Prevention of Break-In Attempts The prevention phase for this kind of attack involves preventing the would-be intruder from actually gaining access to the system and making future attempts more difficult. Password Guessing To reduce the opportunities for successful password guessing: • Make certain your users choose appropriate passwords. Consider use of the password generator (see Section 5.6.6).
7-6 System Security Breaches 7.4 Handling a Security Breach
• Enable system passwords at the points of entry. While a minor inconvenience to your users, system passwords are the best protection against further probing. If you already had a system password enabled, change it (see Section 5.6.2). • Enable auditing of successful logins to catch the event if the intruder succeeds in getting in (see Section 7 .3.2). File Browsing To reduce the opportunities for successful file browsing: • If you can identify the perpetrator, take action as established at your site. • Warn your users about the importance of adequate protection of their files, and consider inspecting the protection of user files. • If file browsing from other nodes in the network becomes a persistent problem, eliminate the default FAL account and authorize individual users through proxy login accounts (see Section 9. 7). 7.4.2 Successful Break-In Attempts A successful security breach can include a successful password guessing scheme, theft or modification of information or system resources, and placement of damaging software on the system. A successful break-in may require a considerable amount of time to repair, depending upon the skill and intent of the perpetrator.
7.4.2.1 Identifying the Successful Perpetrator Identification is often the most difficult part of handling a break-in. First, you must establish whether the perpetrator is an authorized user or not. This determines the nature of the preventive measures that you will take. However, the distinction between insiders and outsiders may be difficult to achieve. Tradeoff Between Identification and Prevention You may have to make a tradeoff between a positive identification of the intruder and preventing future attacks. Often, the data available initially does not allow complete identification. If it is important to identify the perpetrator, you will often find it necessary to permit continued break-ins while you analyze the break-in activity. Increase your auditing. Consider planting traps in system procedures that are under your control (such as SYLOGIN.COM) to obtain additional information. Increase your system backup efforts to permit easier recovery if files become damaged. Identification of Outsiders Identifying external break-in perpetrators is particularly difficult, especially if they use any switched forms of communication (such as dialup lines or public data networks). DECnet for OpenVMS software provides many features to help you trace the activity through the network back to the source node. If a local terminal is involved, physical surveillance may be appropriate. When a switched connection is involved, one of the major computer security problems is the telephone system itself. Tracing a telephone or public data network connection is time-consuming. Chasing an intruder through the telephone system is likely to take months and will require the assistance of law enforcement authorities. The advent of independent long-distance telephone services compounds the problem by increasing the number of organizations with whom you must deal.
7-7 System Security Breaches 7.4 Handling a Security Breach
As a result, identifying an outside intruder is usually worthwhile only when you have sustained substantial financial damage. In many cases, it may be more useful if you concentrate on preventing recurrences of the problem. 7.4.2.2 Securing the System The actions you must take to secure your system after a break-in depend on the nature and source of that break-in. This section describes these actions in order of priority. • Restore SYSUAF.DAT, NETPROXY.DAT, and RIGHTSLIST.DAT (if damaged) from backups. Alternatively, generate listings of the files and inspect them closely, looking for improper entries, additional privileges, and changed UICs. If you are unsure of when SYSUAF.DAT might first have been modified, inspect it carefully regardless of whether you are using a backup copy or proceeding with the existing one. Be sure all authorization files are secure. • The perpetrator may have discovered passwords by browsing through files or from other nodes in the network and may be using seldomly accessed accounts for personal use. Change passwords for accounts, and have your users appear in person to learn their new passwords. At a minimum, change passwords on all privileged accounts. Do not use the same new password for all accounts. • A sophisticated penetrator may have planted ways to provide future access to the system even though you have taken the obvious steps of securing your system. Therefore, you may have to restore selected components of the OpenVMS software from backups or from your OpenVMS distribution kit. If the intruder was an outsider, the only critical component is LOGINOUT.EXE, which validates all entries to the system. However, if the intruder was an authorized user, restore all system files from backup copies. Authorized users can make use of a wide variety of illicit software patches (called trap doors) that they insert in the executive (SYS.EXE), the file system (FllBXQP.EXE), DCL, and other system files. The penetrator may have planted damaging software in any piece of software or command procedure likely to be used by a privileged user. Thus, complete assurance of a secure system requires a wholesale restoration of files from backups. An alternate strategy is to restore trustworthy copies of the obvious targets of attack and to rely on increased auditing for a period of time to catch suspicious events. • Consider implementing additional security features, such as system passwords, password generation, increased auditing, and more stringent file protection to prevent a recurrence. 7.4.2.3 Repair After a Successful Break-In After a break-in, restore corrupted files. Decide whether it is appropriate to do a wholesale restoration of your system's data or to repair problems as they are discovered. Look for modifications to file protection that would have created worm holes and for Trojan horses that were introduced into the system and may still reside there.
7-8 8 Securing a Cluster
This chapter describes concerns for security administrators on clustered systems. Clustered systems refer to those systems using hardware and software that permits sharing of disks, resources, and a common operating system among various computers. Clusters of VAX. processors are said to be joined in a VAX.cluster environment, whereas clusters including both AXP processors and VAX. processors are said to be joined in a VMScluster environment. To properly secure your cluster, you should be familiar with the information in VMScluster Systems for Open VMS. VMScluster Systems for Open VMS describes the tasks of the cluster manager. The cluster manager's job is the same as that of any system manager, but the cluster manager has to implement changes across many nodes. The security administrator for a cluster generally requires the same training and skills as a cluster manager, and at some cluster sites, the same person serves in the role of security administrator as well as cluster manager. At other sites, there may be one or more security administrators in addition to a cluster management team. When a site separates the security administrator function from the cluster management function, coordination, cooperation, and communication between these functions becomes vital. As in previous chapters, this chapter uses the title of security administrator to refer to individuals who have the responsibility for system security, regardless of what other responsibilities they hold. 8.1 Overview of Clusters Clustered systems provide a uniform computing environment that is highly scalable, highly available, and secure. It is critical that there be a single set of authorized users and that these users may have processes executing on any cluster member. To achieve a uniform computing environment, a cluster relies on the following components operating across all cluster members: • Lock manager system services ($ENQ/$DEQ) (to provide a framework for building distributed applications) • File and record management subsystems (coordinated through the lock manager) • Batch and print services • Process control system services • Security auditing system
8-1 Securing a Cluster 8.1 Overview of Clusters
Within a cluster, authorization data for users and the security profiles of objects must be consistent across all nodes so that each cluster member makes the same access control decision when presented with a particular user's access request for a particular object. Section 8.2 and Section 8.3 describe how to achieve a single security domain. 8.2 Building a Common Environment Within a cluster, access control is mediated by individual nodes using a common set of authorization information. In the single security domain model, a process, acting on behalf of an authorized individual, requests access to a cluster-visible object, and a coordinating node determines the outcome by comparing its copy of the common authorization database with the security profile for the object being accessed. This model enforces security only when the authorization information and the object security profiles are consistent across all nodes in the cluster. To achieve data consistency within the cluster, a site needs to: • Maintain a common set of data, as described in Section 8.2.1, Section 8;2.2, and Section 8.2.3 • Execute changes to system parameters consistently When changing any LGI system parameters, use the System Management utility (SYSMAN) (see Section 8. 7). 8.2.1 Required Common System Files The easiest way to ensure a single security domain is to maintain a single copy of each of the files listed in Table 8-1 on one or more cluster-mounted disks. As soon as any required file is created on one node, it must be created or commonly referenced on all remaining cluster members. When a cluster is configured with multiple system disks, system logical names can be used to ensure that only a single copy of each file exists. The files in Table 8-1 contain data that must be synchronized. When a site chooses to maintain multiple versions of these files, you must synchronize the data, as Section 8.2.3 explains.
Table 8-1 System Files That Must Be Common in a Cluster File Description NETOBJECT.DAT Contains the DECnet object database. Among the information contained in this file is the list of known DECnet server accounts and passwords. NETPROXY.DAT Contains the network proxy database. This file is maintained by the Authorize utility (AUTHORIZE). QMAN$MASTER.DAT Contains the master queue manager database. This file contains the security information for all shared batch and print queues. A single copy of this file must be maintained on a shared disk if two or more nodes intend to participate in a shared queuing system. RIGHTSLIST.DAT Contains the rights identifier database. This file is maintained by AUTHORIZE and by various rights identifier system services. (continued on next page)
8-2 Securing a Cluster 8.2 Building a Common Environment
Table 8-1 (Cont.) System Files That Must Be Common in a Cluster File Description
SYSALF.DAT Contains the system autologin facility database. This file is maintained by the System Management utility (SYSMAN). SYSUAF.DAT Contains the system user authorization file. This file is maintained by AUTHORIZE and modifiable through the $SETUAI system service. SYSUAFALT.DAT Contains the system alternate user authorization file. This file serves as a backup to SYSUAF.DAT and is enabled through the SYSUAFALT system parameter. VMS$0BJECTS.DAT Contains the cluster-visible object database. Among the information contained in this file are the security profiles for all cluster-visible objects.
8.2.2 Recommended Common System Files Although Digital does not require that the files listed in Table 8-2 be common to all cluster members, it does rec.ommend that the data in the files be fully synchronized. Table 8-3 explains how to coordinate these files and suggests possible consequences of poor synchronization. Some of the recommended files are created only on request and may not exist in all configurations. Note that a file may be absent on one node only if it is absent on all other nodes. As soon as any required file is created on one node, it must be created or commonly referenced on all remaining cluster members.
Table 8-2 System Files Recommended to Be Common File Description VMS$AUDIT_ Contains information related to security auditing, such as SERVER.DAT enabled security-auditing events and the destination of the system security audit log file. VMS$PASSWORD_ Contains the system password history database. This file is HISTORY.DATA maintained by the SET PASSWORD utility. VMS MAIL_ Contains the system mail database. This file is maintained PROFILE.DATA by the Mail utility (MAIL). It holds mail profiles for all system users as well as a list of all mail forwarding addresses in use on the system. VMS$PASSWORD_ Contains the system password dictionary. The system DICTIONARY.DATA password dictionary is a list of English words and phrases that cannot be used for as account passwords. VMS$PASSWORD_ Contains any site-specific password filters. This file is POLICY created and installed by the security administrator or system manager. (See Section 5.6.5.3.)
8.2.3 Synchronizing Multiple Versions of Files Using shared files is not the only way of achieving a single security domain. Some sites may have requirements for multiple copies of one or more of these system files on different nodes in a cluster. As long as the security information available to each node in the cluster is exactly the same, these sites operate in a single security domain.
8-3 Securing a Cluster 8.2 Building a Common Environment
Table 8-3 lists the files that require coordination, explains when to update these files, and suggests possible .consequences of poor synchronization.
Table 8-3 Using Multiple Versions of Required Cluster Files File Coordination Required Result of Poor Synchronization VMS$AUDIT_SERVER.DAT Update after any SET AUDIT Possible partitioning of auditing command. domains NETOBJECT.DAT Update all versions after any NCP Unexplained network login failures SET OBJECT or DEFINE OBJECT and unauthorized network access command. NETPROXY.DAT Update all versions after any Unexplained network login failures AUTHORIZE proxy command. and unauthorized network access RIGHTSLIST.DAT Update all versions after any Possible unauthorized system change to any identifier or holder access and unauthorized access to records. protected objects SYSALF.DAT Update all versions after any Unexplained login failures and SYSMAN ALF command. unauthorized system access SYSUAF.DAT Update all versions so the fields Possible unexplained login failures listed in Table 8-4 are synchronized and unauthorized system access. for each user record. SYSUAFALT.DAT Update all versions after any Possible unexplained login failures change to any authorization records and unauthorized system access in this file. VMS$0BJECTS.DAT Update all versions after any Possible unauthorized access to change to the security profile of protected objects a cluster-visible object or after new cluster-visible objects are created. (See Section 8.5.) VMSMAIL_PROFILE.DATA Update all versions after any Possible authorized disclosure of changes to mail forwarding information parameters. VMS$PASSWORD_ Update all versions after any Possible violation of the system HISTORY.DATA password change. password policy VMS$PASSWORD_ Update all versions after any site Possible violation of the system DICTIONARY.DATA specific additions. password policy VMS$PASSWORD_POLICY Install common version on all nodes. Possible violation of the system password policy
8.3 Synchronizing Authorization Data On a cluster, all elements of the user authorization data should exist in a common database. These authorization elements include the system user authorization files (SYSUAF.DAT and its backup SYSUAFALT.DAT), the rights database (RIGHTSLIST.DAT), the network authorization file (NETPROXY.DAT) and its object database file (NETOBJECTS.DAT), which are present on all OpenVMS systems, and optionally, the autologin file, SYSALF.DAT. A secure cluster requires that the authorization data be synchronized across all nodes. If a site chooses to maintain multiple versions of these files, then you must synchronize the data. Each user should have the same UIC, group number, and set of identifiers defined on every node. Coordination of privileges and access rights is also critical. A shared disk is protected only as much as its least protected node. If you maintain separate authorization files on each node in the cluster, ensure that user privileges are common across all copies of the system
8-4 Securing a Cluster 8.3 Synchronizing Authorization Data
user authorization file (SYSUAF.DAT). Table 8-4 lists the fields of SYSUAF.DAT that must be identical on each node.
Table 8-4 Fields in SYSUAF.DAT Requiring Synchronization Internal Name $SETUAI Item Code UAF$R_DEF_CLASS UAI$_DEF_CLASS UAF$Q_DEF_PRIV UAI$_DEF_PRIV UAF$B_DIALUP_ACCESS_P UAI$_DIALUP_ACCESS_P UAF$B_DIALUP_ACCESS_S UAI$_DIALUP_ACCESS_S UAF$B_ENCRYPT UAI$_ENCRYPT UAF$B_ENCRYPT2 UAI$_ENCRYPT2 UAF$Q_EXPIRATION UAI$_EXPIRATION UAF$L_FLAGS UAI$_FLAGS UAF$B_LOCAL_ACCESS_P UAI$_LOCAL_ACCESS_P UAF$B_LOCAL_ACCESS_S UAI$_LOCAL_ACCESS_S UAF$B_NETWORK_ACCESS_P UAI$_NETWORK_ACCESS_P UAF$B_NETWORK_ACCESS_S UAI$_NETWORK_ACCESS_S UAF$B_PRIME_DAYS UAI$_PRIMEDAYS UAF$Q_PRIV UAI$_PRIV UAF$Q_PWD UAI$_PWD UAF$Q_PWD2 UAI$_PWD2 UAF$Q_PWD_DATE UAI$_PWD_DATE UAF$Q_PWD2_DATE UAI$_PWD2_DATE UAF$B_PWD_LENGTH UAI$_PWD_LENGTH UAF$Q_PWD_LIFETIME UAI$_PWD_LIFETIME UAF$B_REMOTE_ACCESS_P UAI$_REMOTE_ACCESS_P UAF$B_REMOTE_ACCESS_S UAI$_REMOTE_ACCESS_S UAF$R_MAX_CLASS UAI$_MAX_CLASS UAF$R_MIN_CLASS UAI$_MIN_CLASS UAF$W_SALT UAI$_SALT UAF$L_UIC Not applicable
Use SYSMAN if you choose to create an autologin file and maintain the file in the common authorization database with your authorization files and rights database. On clustered systems, the autologin file must include the cluster node name as a prefix to the terminal name. For example, the terminal TTAO on node WILLOW would be represented as WILLOW$TTAO. Section 8. 7 describes the SYSMAN utility.
8.4 Managing the Audit Log File The audit server database VMS$AUDIT_SERVER.DAT contains information about events to be audited, the location of the audit log file, and information used to monitor its consumption of resources.
8-5 Securing a Cluster 8.4 Managing the Audit Log File
The audit log file resides in SYS$COMMON:[SYSMGR]. If you should decide to redirect the audit log off the system disk, it is important to redirect it uniformly across all nodes on the cluster. You use the command SET AUDIT /JOURNAL=SECURITY/DESTINATION=filename. Make sure that the file name you assign resolves to the same file throughout the cluster, not a file unique to each node. VMScluster Systems for Open VMS describes the procedure in detail. 8.5 Protecting Objects A single security domain is one in which each cluster member must make the same access control decision when presented with a particular user's access request for a particular object. The operating system provides this level of protection for files, queues, other cluster-visible objects: devices, disk and tape volumes, and resource domains. Table 8-5 summarizes the behavior of each object class and explains where each stores security profiles. See Section 4.8 for a description of object classes.
Table 8-5 Summary of Object Behavior in a Cluster Class Visibility in Cluster Location of Profile Capabilities Visible only to local node. Stored on local node. Devices Some can be visible Profiles stored in clusterwide. VMS$0BJECTS. Files Visible clusterwide. Stored in file header. Global sections Visible only to local node. Stored on local node. Logical name tables Visible only to local node. Stored on local node. Queues Visible clusterwide. Stored in job-controller queue database (see Table 8-1). Resource domains Visible clusterwide. Stored in VMS$0BJECTS. Security class Visible clusterwide. Stored in VMS$0BJECTS. Volumes Can be visible clusterwide. Stored on the volume.
8.6 Storing Profiles and Auditing Information The audit server creates and maintains the security elements of clusterwide objects in a database called VMS$0BJECTS.DAT, located in SYS$COMMON:[SYSEXE]. You should ensure that the object database is present on each node in the cluster by specifying a file name that resolves to the same file through the cluster, not to a file that is unique to each node. To reestablish the logical name after each system boot, define the logical in SYSECURITY.COM. The command procedure SYSECURITY.COM has to be defined before the audit server starts up. The object database contains the following information: • Audit and alarm settings for all objects, established through the DCL command SET AUDIT • Template profiles for all security profiles, as described in Section 4.8 • Security profiles for all resource domain objects, all security class objects, and all cluster-visible devices (see Section 8.5)
8-6 Securing a Cluster 8.6 Storing Profiles and Auditing Information
This database is updated whenever characteristics are modified, and the information is distributed so that all nodes participating in the cluster share a common view of the objects. Ordinarily, it is not possible to change security profiles or create protected objects when the object server is absent and cannot update the cluster database VMS$0BJECTS.DAT. However, you can modify the system parameter SECURITY_FOLICY to allow security profile changes to protected objects on a local node (bit 4) or the creation of protected objects on a local node (bit 5). 8.7 Using the System Management Utility The System Management utility (SYSMAN) is a facility supporting the cluster work of the security administrator. Through its centralized management of nodes and clusters, SYSMAN lets you perform system management tasks from your local node that the utility executes on all nodes in the target environment. To use SYSMAN requires OFER privilege on the local node and authorization for the OFER privilege on any remote node. The utility does not require a password when you are operating within a cluster in your own account. The operating system audits any logical link connections or any operation in which the utility requires a password. System managers using SYSMAN should be careful that logical names are set to the same name on each node. 8.8 Managing Cluster Membership Clustered systems use a group number and a cluster password to allow multiple independent clustered systems to coexist on the same extended local area network (LAN) and to prevent accidental access to a cluster by unauthorized computers. The group number uniquely identifies each cluster system on a LAN. The cluster password serves as an additional check to ensure the integrity of individual clusters on the same LAN that accidentally use identical group numbers. The password also prevents an intruder who discovers the group number from joining the cluster. The cluster group number and password (in encrypted form) is maintained in the cluster authorization file, SYS$COMMON:[SYSEXE]CLUSTER_ AUTHORIZE.DAT. This file is created during installation of the operating system if you indicate that you want to set up a local area or mixed-interconnect cluster. The installation procedure then prompts you for the cluster group number and password. Under normal conditions, you need not alter records in the CLUSTER_ AUTHORIZE.DAT file interactively. However, if you suspect a security breach, you may want to change the cluster password. In that case, you use the SYSMAN utility to make the change. The file is accessible only to users with the SYSFRV privilege. Note that if you change either the group number or the password, you must reboot the entire cluster. If your configuration has multiple system disks, each disk must have a copy of CLUSTER_AUTHORIZE.DAT. You must run the SYSMAN utility to update all copies.
8-7 Securing a Cluster 8.8 Managing Cluster Membership
The following command sequence illustrates the use of the SYSMAN utility to change the cluster password: SYSMAN> SET CLUSTER AUTHORIZATION/GROUP NUMBER=65353 SYSMAN> SET ENVIRONMENT/CLUSTER/NODE21 - SYSMAN> SET PROFILE /PRIVILEGE=SYSPRV SYSMAN> CONFIGURATION SET CLUSTER AUTHORIZATION/PASSWORD=HOOVER %SYSMAN-I-CAFOLDGROUP, existing group will not be changed %SYSMAN-I-GRPNOCHG, Group number not changed %SYSMAN-I-CAFREBOOT, cluster authorization file updated The entire cluster should be rebooted.
8.9 Using DECnet Between Cluster Nodes The cluster environment provides such a rich resource-sharing model, which includes files and volumes, disk and tape devices, and batch and print queues, that it is usually unnecessary to directly access another cluster node through DECnet software. Nonetheless, there are situations where resources may not be uniformly shared across the cluster. This is particularly true in mixed interconnect or local area cluster configurations, where security administrators may choose to limit cluster access to a satellite's disk or tape volumes. In such cases, users need to use the DCL command SET HOST or some form of network access to access a satellite's resources from other cluster members. See Section 9.7 for more information on network access through proxy logins.
8-8 9 Security for a DECnet Node
Security in a networking environment is even more sensitive than security in a single-system environment. Security is also harder to achieve because of operational complexities and the decentralization of control that commonly exist in networks. The larger the network, the more difficult the problem of establishing control and communication between security administrators of the numerous nodes. This chapter provides direction on how security administrators can improve network security at the system level. Network security also requires access control at the circuit level and the node level. This chapter assumes the reader is familiar with the information in the DECnet for Open VMS Networking Manual, which describes security at all three levels. Secure nodes and overall network security are even more important to system security than individual node operations and must be monitored and updated regularly. There are limitations in the degree of security any networking site can expect to achieve due to limitations currently present in networking technology. Being sensitive to potential problems can help you avoid operations that could increase the security exposure in your network. This chapter helps you recognize these problem areas and adjust your operations accordingly. 9.1 Access Control in a Network The security administrator can control access to the local node at three levels: the circuit, the node, and the system. This section briefly describes each, but refer to the DECnet for Open VMS Networking Manual for a complete description of circuit and node security. This chapter discusses system-level access control in detail. 9.1.1 · Circuit-Level Access Control For point-to-point connections, especially over dialup lines, you can use passwords to verify that the initiating node is authorized to form a connection with your node. Passwords are usually optional for point-to-point connections but are required for dynamic asynchronous connections. Each end of a point-to-point circuit can establish a password to transmit to the other node and specify a password expected from the other node. Before the link is established, each node verifies that it received the expected password from the other node. Added security is provided for a dynamic asynchronous connection (which is normally maintained only for the duration of a telephone call): the node requesting the dynamic connection is required to supply a password, but the node receiving the login request is prevented from revealing a password to the requesting node.
9-1 Security for a DECnet Node 9.1 Access Control in a Network
9.1.2 Node-Level Access Control To control the establishment of logical links with remote nodes, you can specify in your network database access control parameters that indicate which of the following logical link connections are permitted: INCOMING, OUTGOING, BOTH, or NONE. Use the Network Control Program (NCP) commands that follow to specify access parameters for a specific node; use the executor parameter DEFAULT ACCESS for any node for which a specific access parameter is not specified: $ RUN SYS$SYSTEM:NCP NCP>DEFINE NODE node-id ACCESS option NCP>DEFINE EXECUTOR DEFAULT ACCESS option NCP>EXIT 9.1.3 System-Level Access Control When a remote user requests access to an object on the local node, the following means of authorization are checked: • Is an explicit access control string available? • Does the user have a proxy account on the local node? • Is there a default access account for the object at the local node? • Is there a default nonprivileged DECnet account at the local node? If no explicit access control information or proxy account is available, DECnet software uses access control information specified for the object in the local network database. DECnet first attempts to use a default access account for the object. If neither explicit access control information, nor a proxy account, nor a default access account for the object exists, DECnet attempts to use the default nonprivileged DECnet account, if one exists, to access the system. 9.2 Reference Monitor in a Network Chapter 2 introduces the concept of a reference monitor. This concept also applies to security in a network of interconnected computer systems. This section first extends the reference monitor concept to the network environment, then summarizes the special considerations that apply in a network, and finally makes the connection between the abstract components of the reference monitor and the real elements of a DECnet network. In a network, there is a subject on one computer, an object on another, and a network reference monitor. The monitor grants the subject access to the object, refers to an authorization database, and develops the required audit trail. Figure 9-1 shows this simplified view of secure access in a network environment.
9-2 Security for a DECnet Node 9.2 Reference Monitor in a Network
Figure 9-1 Simple View of Reference Monitor in a Network
Authorization Database
Subject: System User Authorization File, Rights Database, Network Proxy Authorization File
Object: UIC-Based Protection Code, Owner UIC, ACL
Audit: Audit Database (Location and listing of enabled events)
Network Subject: Object: t-• Reference Monitor r--• A Computer Node A Computer Node
,,
Audit Trail
ZK-2018-GE
While, for the most part, the network security mechanisms that Digital employs conform to the abstract model depicted in Figure 9-1, there are some differences. Consider a subject on one node in the network that attempts to access an object on a second node. Because each computer must have its own implementation of the reference monitor model, there is a phantom object on the system with the real subject (the source machine) and a corresponding phantom subject on the system with the real object (the target machine). The resulting configuration resembles Figure 9-2.
9-3 Security for a DECnet Node 9.2 Reference Monitor in a Network
Figure 9-2 Advanced View of the Reference Monitor in a Network r------1 r------1 Source Machine (Contains Phantom Object) I Target Machine (Contains Phanton:i Subject) I
Authorization Authorization Database Database
Network Network Subject Reference ----t- Reference Object Monitor Monitor
Audit Audit Trail Trail
L------L------ZK-2038-G E
There are three critical requirements for achieving security in a network environment: • There must be a correspondence between the real subject on the source machine and the phantom subject on the target machine. This correspondence must be managed by the two reference monitors and must be consistent with the security policy intended on the target machine (which is ultimately responsible for protecting the object). • The authorization database on the target machine must express an access authorization for a phantom subject that corresponds to the real subject on the source machine. • There must be a protected means of communication between the two reference monitors (source and target) so that correspondence between real and phantom subjects can be reliably established and authenticated. 9.2.1 Establishing Subject Correspondence OpenVMS and DECnet software provide several mechanisms for establishing a correspondence between a subject or process on a source node and another on a target node: • Essentially, the default account mechanisms allow any subject on any node to be placed in correspondence with a default subject on a target node known as a default DECnet account. This subject can, in turn, gain access to objects on behalf of a requesting subject and return the required information. Because any subject can be placed in correspondence with a default subject on a target node, there is little selectivity or control in the establishment of the correspondence. A default account is appropriate for limited situations, such as read-only public directories.
9-4 Security for a DECnet Node 9.2 Reference Monitor in a Network
• Another alternative is the use of explicit (user name/password) access control when establishing a subject at the target node. This mechanism restricts access to those objects accessible to the named user but also causes users' passwords to move about the network without effective protection. Because passwords are cumbersome to enter, users may embed access control strings in files and command procedures. The security of the remote systems can depend on the discretionary access controls and default file protections that users employ on the local system. Explicit access control also results in plaintext passwords being sent over the cluster or network communications channels, thereby increasing the need for physical site security. • Finally, the OpenVMS system offers proxy accounts as a means of establishing the correspondence between the real subject on the source node and the phantom subject on the target node. The proxy database is a table created by the security administrator that lists mappings between remote users and local accounts. Proxies spare users from entering or remembering passwords or sending plaintext passwords over the network. However, maintaining the proxy database requires the security administrator's time. In addition, the security of the local system is coupled to the security of all remote systems and users named in the proxy database, and proxy authentication is subject to node impersonation on unencrypted networks. Section 9.7 describes proxy accounts. The proxy option requires the target reference monitor to maintain a table of source subjects (by user name and node name) and the corresponding local (target) user names. Then each request from a subject on a source node is mapped into the creation of a subject representing the corresponding target user. This mechanism offers the explicit control associated with user name/password control but more adequately protects the passwords. 9.2.2 Specifying Authorizations The approach used to specify authorization for access to objects depends somewhat on the mechanism for establishing correspondence between subjects. The default account mechanisms essentially create anonymous subjects on the target node. As a result, objects that are to be made accessible to a default account must permit the world user category full access, which leaves the object unprotected. If either explicit access control or proxy access is used to establish correspondence between subjects, the authorization can be granted to the target subject selected by the user name or proxy. In this case, the full range of OpenVMS authorization mechanisms can be used. 9.2.3 Protecting Communications It should be clear that the security of network operations depends mostly on the ability of source and target reference monitor mechanisms to communicate in a private, authenticated way. Do not allow an intruder to observe passwords or to masquerade as a source node that has been granted proxy access.
9-5 Security for a DECnet Node 9.2 Reference Monitor in a Network
9.2.4 Auditing in the Network The operating system audits Network Control Program (NCP) command lines as well as the creation and termination of logical links with other nodes in the network. Each NCP command line is audited along with its completion status. Any network connection results in four audits; the system monitors: Event 1 Outgoing connection initiations from the source node Event 2 Incoming connection initiations from the destination node Event 3 Link terminations by the source node Event 4 Link terminations by the destination node Events 1 and 3 are recorded on the initiating nodes only; events 2 and 4 are recorded on the target node. Events 3 and 4 can occur in any order. With an incoming network connection, the auditing message has a remote user name field that identifies who initiated the connection. With outgoing logical link connections, the remote logical link identifier is always 0. Whenever a user exercises a privilege in an operation, the operating system can audit the use of this privilege. In a network environment, much of this privilege use is related to the use of the OPER privilege in modifying the volatile network database. 9.2.5 Summary of OpenVMS Network Security and the Reference Monitor The OpenVMS system provides, especially through the proxy mechanism, a vehicle for extending user authentication and authorization over a network in a secure, natural, and consistent manner. However, from a system point of view, the network security mechanisms are no better than the protection of the underlying communications. This can be critical in relatively open networks that process sensitive information. 9.3 DECnet Accounts DECnet accounts permit certain types of access to your system from remote nodes without requiring them to specify account and password information. Instead, this information is specified in the DECnet executor and object databases. Like all accounts, these are controlled through the system user authorization file (SYSUAF.DAT) by using techniques similar to those used for restricted user accounts (see Section 5.13). Consider the following general guidelines when you set up accounts for network use. Detailed examples are given in Section 9.6.3. • DECnet software currently has no requirement for a privileged default account. Keep the privileges for DECnet accounts to a minimum. Typically, this means you would give only TMPMBX and NETMBX to nonprivileged accounts. • UICs of the network nonprivileged accounts should be unique. Furthermore, the group code must exceed the system UIC group number to avoid granting the user the system user category for object access. (Ensure this by using group codes greater than the SYSGEN parameter MAXSYSGROUP.) • Maintain the secrecy of passwords for DECnet accounts; they need not be known to users of your node or other nodes. Once the password is defined in the user authorization file and the DECnet databases, there is no need to specify the password.
9-6 Security for a DECnet Node 9.3 DECnet Accounts
• Set up the DECnet accounts with the AUTHORIZE qualifiers /FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE), /NOINTERACTIVE, and /NOBATCH. Section 9.6 describes how to create individual network accounts for each DECnet object required on the sys.tern. 9.4 DECnet Database The DECnet node and circuit databases control how other computers are allowed to connect to your computer. Because a computer connection permits automated assaults on both your own security and that of any other computer in the network, it requires strict control. To promote the security of the databases, observe the following guidelines: • Define receive and transmit passwords for all nodes in the database. The receive password defined for a node needs to be known by the manager of that node only if that node can be adjacent. Wherever possible, the transmit and receive passwords should be different and not obvious. (Some operating systems do not permit this.) • Always enable verification on any circuit that goes outside a locked computer room or to a machine with a different security environment. This forces the local node to check the Routing layer passwords before it completes a node initialization request. The password check is necessary to prevent the node adjacent to you from intercepting mail or circumventing a connection check for the originating node by pretending to be another node in the network. Node verification is particularly important when proxy logins are permitted. • Do not define default access rights in the database for external nodes. A possible exception to this would be for a server or computer that is a dedicated front end for another computer. • In general, do not enable backup synchronous dialup for autoanswer. Systems that have incoming dialup for production purposes should control which nodes can connect.
9.5 Network Laws and Regulations Use of the network is restricted in many countries, either by law or by contract with the major communications division of many governments known as the PTT (Post, Telegraph, & Telephone) administration. Always conform to these regulations. For example, several countries have laws to protect personal data from misuse, including restrictions on moving personal data across country boundaries. This includes moving or remotely accessing personnel databases and may also be interpreted to include such tasks as forwarding job applications. For example, Germany has a law that forbids transmitting data for processing outside the country. Similarly, some European laws forbid anyone but the PTT from providing data transmission as a service to customers. For example, in Germany it is illegal to route data between the X.25 network and the leased-line network.
9-7 Security for a DECnet Node 9.6 Specifying DECnet Object Accounts
9.6 Specifying DECnet Object Accounts Network objects are system programs and user-written applications that permit communications among nodes in a DECnet network. As an important part of your overall system security plan, you should identify the set of network objects allowed access to your system and set up the appropriate access controls for each object. (For more information on network objects, see the DECnet for Open VMS Networking Manual.) You can select one of the following mechanisms to control network access to your system: • Default DECnet account-A default DECnet account allows all network objects general access to the system. You can establish and maintain a default DECnet account for remote nodes if you consider your system a part of a low-security environment, such as a local area network of systems located within a building or site with no outside connections or dialup lines. • DECnet object accounts-A more secure alternative to the default DECnet account is the creation of network accounts for specific network objects. Creating individual accounts for network objects provides better accountability of remote access to the object. For example, you can create a captive login command procedure for the network object account that grants or denies access to the object based on the remote node name or user name. • Proxy account-If there is no default DECnet account on the system and no account created for the network object, you can still allow selected remote users proxy access to the object. (See Section 9.7 for more information about setting up a proxy account.) Sites with medium to high security requirements create and use proxy accounts as a means of denying all but a trusted set of remote users access to the local system. (Note, however, that it is still possible for a malicious person to impersonate a remote node in the network and to gain all proxy access granted to users from that system.) • Explicit access control string-For some sites with medium to high security requirements, both proxy access and access through network object-specific accounts are denied. Remote users can access protected network objects, however, by supplying access control information (the user name and password, typically) with the network request. For example, remote users with accounts on the local system can include the "username password" access control string in the file specification when attempting remote copy operations, as shown in the following command: $COPY DTROIT"WILSON MI2326G"::WORKl:[DISTRIBUTION] - _$ NOTICE.DAT * Depending upon the level of security required at your site, you can choose any of these access control techniques to protect access to your system from remote sources. The following sections summarize the network objects supplied with the OpenVMS operating system and describe how to configure the objects using two different methods: • Automatically by using the DECnet configuration procedure NETCONFIG.COM
9-8 Security for a DECnet Node 9.6 Specifying DECnet Object Accounts
• Manually by creating accounts for network objects with the Authorize utility (AUTHORIZE) and modifying the network object database to recognize the object-specific accounts 9.6.1 Summary of Network Objects You should understand the function of the network objects supplied with the OpenVMS operating system before you determine the access control to apply to them. This section provides a description of the most common network objects. FAL The file access listener (FAL) is the remote file access facility. FAL is an image that receives and processes remote file access requests for files at the local node. Use of general FAL access is strongly discouraged. Open access allows general network access to any files marked world-accessible. It also allows remote users to create files in any directory with world write access. Sites with high security requirements, or sites where it is difficult to recognize all the intended users, should not create a FAL account. To control which users gain access, these sites may establish one or more proxy accounts for specific purposes (see Section 9. 7). MAIL MAIL is an image that provides personal mail services for OpenVMS systems. In most cases, allow the MAIL object general access to the system. MIRROR MIRROR is an image that is used for particular forms of loopback testing. For example, MIRROR is run during the DECnet phase of the UETP test package. MOM MOM is the Maintenance Operations Module. The MOM image downline loads unattended systems, transferring a copy of an operating system file image from a OpenVMS node to a target node. The MOM object is established during a system installation. NML NML is the network management listener. Remote users with access to NML can use NCP TELL commands to gather and report network information from your DECnet databases. PHONE PHONE is an image that allows online conversations with users on remote OpenVMS systems. Note that if you allow default DECnet access to PHONE, anyone in the network can get a list of users currently logged in to the local system and attempt a login using the list of user names. TASK Through the default DECnet account, the TASK object allows arbitrary command procedures (including those which might be used in attempted break-ins) to be executed on your system. Note that if you do not allow default DECnet access on your system or if you disable default DECnet access to the TASK object, you can allow remote user written command procedures (tasks) to run on your system through the use of access control strings or proxy access.
9-9 Security for a DECnet Node 9.6 Specifying DECne.t Object Accounts
VPM VPM is the Virtual Performance Monitor Server. Access to VPM is required to use the cluster monitoring features of the Monitor utility (MONITOR). 9.6.2 Configuring Network Objects Automatically The operating system provides the command procedure NETCONFIG.COM in the SYS$MANAGER directory to automatically configure your system as a node in a DECnet network. NETCONFIG.COM, when executed, also lets you define either a default DECnet account on the system or separate network accounts for specific network objects. Typically, you run NETCONFIG.COM after installing a new version of the operating system. If you have recently upgraded your system from a previous version of the operating system and you want to remove default DECnet access on your system, you can execute the procedure NETCONFIG_UPDATE.COM, located in the SYS$UPDATE directory. NETCONFIG_UPDATE.COM provides most of the same features as NETCONFIG.COM, except that it does not purge the network databases before starting. Refer to the DECnet for Open VMS Networking Manual and the Open VMS VAX "Version 6.0 Upgrade and Installation Manual for information about using the NETCONFIG.COM and NETCONFIG_UPDATE.COM network configuration procedures. 9.6.3 Configuring Network Objects Manually If you choose not to execute the NETCONFIG.COM or NETCONFIG_ UPDATE.COM command procedure to configure or update the network objects on your system, you can perform the following steps to allow network access to specific objects: 1. Create a top-level directory for the object (see Section 9.6.3.1). Specify a unique UIC for the directory owner. 2. Using AUTHORIZE, create an account for the object (see Section 9.6.3.2) in the system user authorization file (SYSUAF.DAT). Use a generated password for the account. Note the name of the account and the password specified for the account; they are used in the next step of the procedure. 3. Specify the account name and password for the object in the network object database (as described in Section 9.6.3.3). 4. Repeat steps 1 through 3 for each network object. 5. When completed, remove default DECnet access from the executor database, and remove the default DECnet account from the SYSUAF (see Section 9.6.3.4). 6. Finally, reboot the system to copy changes made to the permanent executor and object databases to the running system.
9.6.3.1 Creating a Top-Level Directory for an Object When you create top-level directories for network object accounts, ensure that the UIC group is unique for each network object. The following example shows how to create a top-level directory for the MAIL object on the system disk: $SET DEFAULT SYS$SPECIFIC:[OOOOOO] $ CREATE/DIRECTORY [MAIL$SERVER]/OWNER_UIC=[376,374]
9-10 Security for a DECnet Node 9.6 Specifying DECnet Object Accounts
Table 9-1 lists the directory names, user names, and UICs used by the NETCONFIG.COM and NETCONFIG_UPDATE.COM command procedures to create accounts for specific network accounts. For consistency, you should specify the same information when manually creating network object accounts. Note that the MOM object is created by the operating system during installation.
Table 9-1 Network Object Defaults Object Directory and Name User (Account) Name UIC FAL FAL$SERVER [376,373] MAIL MAIL$SERVER [376,374] MIRROR MIRRO$SERVER1 [376,367] $MOM SYS$COMMON:[MOM$SYSTEM]2 [376,375] NML NML$SERVER [376,371] PHONE PHONE$SERVER [376,372] VPM VPM$SERVER [376,370]
1 Because AUTHORIZE enforces a user name limit of 12 characters, you must truncate the user name (and directory name) of the MIRROR object account to MIRR0$SERVER. 2MOM has no associated user name.
9.6.3.2 Creating an Account for a Network Object The following example shows the commands you use to set up an account in AUTHORIZE for the MAIL object. Note that the user name and password that you specify must match the password defined for the object in the network database (described in Section 9.6.3.3). $ RUN SYS$SYSTEM:AUTHORIZE UAF> ADD MAIL$SERVER/OWNER=MAIL$SERVER DEFAULT - UAF> /PASSWORD=MDU1294B/UIC=[376,374]/ACCOUNT=DECNET - -UAF> /DEVICE=SYS$SPECIFIC: /DIRECTORY=[MAIL$SERVER] - -UAF> /PRIVILEGE=(TMPMBX,NETMBX) /DEFPRIVILEGE=(TMPMBX,NETMBX) - -UAF> /FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE) /LGICMD=NL: - -UAF> /NOBATCH /NOINTERACTIVE The AUTHORIZE command SHOW MAIL$SERVER displays the network account set up for the MAIL object, as shown in Example 9-1.
9-11 Security for a DECnet Node 9.6 Specifying DECnet Object Accounts
Example 9-1 UAF Record for MAIL$SERVER Account Usernarne: MAIL$SERVER Owner: MAIL$SERVER Account: MAIL$SERVER DEFAULT UIC: [376,374] ([DECNET,MAIL$SERVER]) CLI: DCL Tables: Default: SYS$SPECIFIC:[MAIL$SERVER] LGICMD: Login Flags: Restricted Primary days: Mon Tue Wed Thu Fri Sat Sun Secondary days: Primary 000000000011111111112222 Secondary 000000000011111111112222 Day Hours 012345678901234567890123 Day Hours 012345678901234567890123 Network: ##### Full access ###### ##### Full access ###### Batch: No access No access Local: No access ------No access Dialup: No access ------No access Remote: No access ------No access Expiration: (none) Pwdminimum: 6 Login Fails: 0 Pwdlifetime: (none) Pwdchange: (none) Last Login: (none) (interactive), (none) (non-interactive) Maxjobs: 0 Fillm: 16 Bytlm: 12480 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 12 JTquota: 1024 Prclm: 0 DIOlm: 6 WSdef: 180 Prio: 4 ASTlm: 16 WSquo: 200 Queprio: O TQElm: 10 wsextent: 0 CPU: (none) Enqlm: 20 Pgflquo: 25600 Authorized Privileges: TMPMBX NETMBX Default Privileges: TMPMBX NETMBX
9.6.3.3 Defining the Network Object Account Name and Password After you create the network account in AUTHORIZE, use the NCP DEFINE command to associate the user name and password of the account with the specified object in the network database, as follows: $ RUN SYS$SYSTEM:NCP NCP>DEFINE OBJECT MAIL USER MAIL$SERVER PASSWORD MDU1294B NCP>EXIT 9.6.3.4 Removing Default DECnet Access to the System
------Warning Before deleting your default DECNET account, as described in this section, use the NCP command SHOW KNOWN OBJECTS and the Authorize utility (AUTHORIZE) to verify that all network objects and layered products that use network objects have network accounts set up in the system user authorization file (SYSUAF.DAT).
Once you have set up accounts for all the network objects needed, remove default DECnet access to the system. To do this, remove access to the DECNET account in the executor database, and delete the DECNET account from the UAF.
9-12 Security for a DECnet Node 9.6 Specifying DECnet Object Accounts
Removing Default DECnet Access Execute the following NCP commands to remove the default DECnet access from the network executor database: NCP>DEFINE EXECUTOR NONPRIVILEGED USER DEFAULT DECNET NCP>PURGE EXECUTOR NONPRIVILEGED PASSWORD - The DEFAULT_DECNET user specified in the first command is a nonexistent user account that is specified for auditing purposes only. (A network login failure message is written to the security audit log file each time access to your system is attempted through the (nonexistent) DEFAULT_DECNET account.) Deleting the DECNET Account Using AUTHORIZE, remove the DECNET account from SYSUAF, as follows: $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> REMOVE DECNET UAF> EXIT Delete any files in the [DECNET] directory structure.
9.6.3.5 Rebooting the System After configuring the desired network objects, reboot the system. The changes made to the permanent executor and object databases are copied to the system following the reboot. 9.7 Proxy Logins You can authorize proxy access when you encounter situations where users on different nodes or in different groups want to share files on your system and you are reluctant to give out passwords or to set the directory and file protection to W:RWE. With proxy logins, there is no need for passwords to be embedded in commands to copy a file across the network. There is also no need to allow world read access to a file for file transfers. The user enters the following form of the DCL command COPY: COPY remotenode::file-spec file-spec You can authorize a remote user access to a default proxy account and up to 15 other proxy accounts. To copy a file over the network using proxy access from an account other than the default, the user includes the name of the proxy account in the access control string of the DCL command, as follows: COPY remotenode 11 proxyacct 11 ::file-spec file-spec Security administrators should avoid setting up proxies that map into privileged accounts. To deter Trojan horse attacks on a privileged user's environment, use a different UIC and default directory for the unprivileged proxy account of a privileged user. 9.7.1 Setting Up Proxy Logins Two utilities are used to set up proxy logins: AUTHORIZE and NCP. You might want to create a command procedure to assist you in implementing proxy access.
9-13 Security for a DECnet Node 9. 7 Proxy Logins
For example, the command procedure could provide the following functions: • Check if proxy access is enabled for your system • Create a proxy account for sharing files • Grant a user access to a proxy account • Remove a user from access to a proxy account • Change the default proxy account for a user • List users authorized to access a proxy account 9.7.1.1 Using the Authorize Utility To set up proxy logins without using a command procedure, use the Authorize utility (AUTHORIZE) to create or modify the network proxy authorization file, NETPROXY.DAT, that contains the names of all remote users allowed proxy access to the system and the names of all proxy accounts defined for the remote users. Note that the remote user can be specified either by user name or, for non OpenVMS systems that implement DECnet Phase Iv, by UIC. The following commands establish, modify, display, or remove records in the proxy authorization file: • CREATE/PROXY • ADD/PROXY node::remoteuser localuser[, ... ] • LIST/PROXY • MODIFY/PROXY node::remoteuser • SHOW/PROXY node::remoteuser • SHOW/PROXY* • REMOVE/PROXY node::remoteuser 9.7.1.2 Proxy Account Example When you want to set up a proxy account on your node for use by one or more users at other nodes, you must perform the following steps: 1. Decide on the purpose of the account. Decide the name of the local account and which network users will be admitted. 2. If the local account does not exist, create it with AUTHORIZE; if the account does exist, examine it to ensure it is adequately restricted. Proxy accounts should be restricted so that they prohibit interactive users and batch jobs, which means they should permit only network logins. 3. Review the privileges on the account. Generally avoid granting privileges to proxy login accounts. This practice provides a shield between systems in a network in the event one node is penetrated. The fact that proxy logins provide admittance only to nonprivileged accounts at other nodes may help contain the extent of damage if a penetration occurs on one system in the network. 4. If the network proxy authorization file NETPROXY.DAT does not exist, create it with the AUTHORIZE command CREATE/PROXY.
9-14 Security for a DECnet Node 9. 7 Proxy Logins
5. Allow as many remote users as necessary access to the proxy account with the AUTHORIZE command ADD/PROXY. (Exercise caution when authorizing users. Ideally, you should receive a formal authorization request from the security administrator at the remote site.) 6. Check the default protection on the directory, and customize it as necessary. 7. Examine any command procedure used at login time and specified by /LGICMD. Make certain that it follows the recommendations in Section 5.13 for login command procedures in captive accounts. It should reside in a well-protected directory owned by a user other than the owner of the proxy account. It should prohibit write access for those who use the account. 8. Notify the security administrator at the remote node which users from that node have been authorized for access to your node. In Example 9-2, the security administrator at the node WALNUT wants to create a general access account called GENACCESS. At the same time the administrator wants to take steps to allow proxy logins by three users from the node BIRCH: K.Mahogany, PSumac, and WPine, as well as two users from the node WILLOW: RDogwood and WCherry. No network proxy authorization file currently exists.
Example 9-2 Sample Proxy Account $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD GENACCESS /PASSWORD=WHYNADGUM/UIC=[236,043] - UAF> /DEVICE=STAFFDEV/DIRECTORY=[GENACCESS] - -UAF> /OWNER="Security Mgmt"/ACCOUNT=SEC - -UAF> /FLAGS=(DISWELCOME,DISNEWMAIL,GENPWD,DISMAIL) - -UAF> /NOBATCH/NOINTERACTIVE/MAXDETACH=B - -UAF> /LGICMD=LOGIN/MAXACCTJOBS=lO user record successfully added identifier for value:[000236,000043] added to RIGHTSLIST.DAT UAF> CREATE/PROXY UAF> ADD/PROXY BIRCH::KMAHOGANY GENACCESS/DEFAULT record successfully added to NETPROXY.DAT UAF> ADD/PROXY BIRCH::PSUMAC GENACCESS/DEFAULT record successfully added to NETPROXY.DAT UAF> ADD/PROXY BIRCH::WPINE GENACCESS/DEFAULT record successfully added to NETPROXY.DAT UAF> ADD/PROXY WILLOW::RDOGWOOD GENACCESS/DEFAULT record successfully added to NETPROXY.DAT . UAF> ADD/PROXY WILLOW::WCHERRY GENACCESS/DEFAULT record successfully added to NETPROXY.DAT UAF> SHOW/PROXY*::* Default proxies are flagged with a (D)
(continued on next page)
9-15 Security for a DECnet Node 9.7 Proxy Logins
Example 9-2 (Cont.) Sample Proxy Account BIRCH::KMAHOGANY GENACCESS (D) BIRCH : : PSUMAC GENACCESS (D) BIRCH : :WPINE GENACCESS (D) WILLOW ::RDOGWOOD GENACCESS (D) WILLOW : : WCHERRY GENACCESS (D) UAF> EXIT {messages} $DIRECTORY/SECURITY SYS$STAFF:[OOOOOO]GENACCESS.DIR
$DIRECTORY/SECURITY SYS$STAFF:[GENACCESS]LOGIN.COM
AUTHORIZE performs certain automatic maintenance functions on the NETPROXY.DAT proxy authorization file. Whenever the user name changes through a RENAME or COPY command, the associated change is made in NETPROXY. Similarly, when you remove an account from SYSUAF.DAT, all entries for which there is a matching local user name are removed from NETPROXY.DAT. 9.7.1.3 Using the Network Control Program (NCP) Utility Use NCP to control the overall use of proxy logins with respect to the executor node and network objects. You can restrict the use of proxy logins on your system by specifying the NCP executor parameters INCOMING PROXY and OUTGOING PROXY, as shown in Table 9-2.
Table 9-2 Executor Proxy Parameter Values Parameter Meaning INCOMING PROXY enabled Allows proxy login access from the remote node to the local node INCOMING PROXY disabled Prevents proxy login access from the remote node to the local node OUTGOING PROXY enabled Allows the local system to initiate proxy login access to the remote system OUTGOING PROXY disabled Prevents the local system from initiating proxy login access to the remote system
By default, both incoming and outgoing proxy login access are enabled at the local system.
9-16 Security for a DECnet Node 9. 7 Proxy Logins
You can also control proxy login access by network objects by setting the value of the object parameter PROXY in the object database. Specify proxy login access for a particular network object (such as MAIL or FAL) only when the desired proxy access is different from that defined in the executor database. Refer to the DECnet for Open VMS Networking Manual for information on using NCP to modify the executor and object databases. The control parameters are found in the executor and object databases. They each are part of the characteristics display that you can generate with the following command: $ RUN SYS$SYSTEM:NCP SHOW CHAR OBJ FAL The executor database contains the INCOMING PROXY and OUTGOING PROXY parameters. These parameters are used to supply values for other parameters when they are not explicitly set up for a given node or object. These parameters make it easy to set up the DECnet configuration database. Proxy access will not function for nodes that have privileged or nonprivileged access control specified (parameters [NON]PRIVILEGED USER, PASSWORD, and ACCOUNT). The concept of outbound proxy access conflicts with the concept of default outbound access control strings. This conflict occurs on the destination node. When a connect message containing non-null access control strings is received, the receiving node has no way of knowing whether those strings were specified explicitly by the user or were defaults provided by the source-node operating system; when access control strings are passed in the connect message, they are used, and proxy access is inhibited. The USER, PASSWORD, and ACCOUNT parameters should rarely be used. They are still needed if default access is to be provided to nodes that cannot provide default inbound access control. OpenVMS nodes are all capable of providing default inbound access control (in addition to proxy access) by setting the NONPRIVILEGED USER, PASSWORD, and ACCOUNT parameters in the executor database. If outbound proxy access is implicitly set for a node to OUTGOING PROXY ENABLED in the EXECUTOR database, the USER, PASSWORD, and ACCOUNT parameters may still be set up for that node. In this case, outbound proxy access to that node is inhibited because the DECnet connect message contains a non-null access control. The object database contains the PROXY parameter to control proxy access to and from individual objects in the network. The value for this parameter is taken from the EXECUTOR INCOMING PROXY and EXECUTOR OUTGOING PROXY parameters if it has not been given an explicit value or if a given object is not defined in the database. 9.7.1.4 Conditions for Proxy Access For proxy access to be allowed, five conditions must be satisfied. If any of these conditions are not met, the default DECnet account is used. • The EXECUTOR DEFAULT PROXY parameter for the initiating node must be either BOTH or OUTGOING. • The OBJECT PROXY parameter for the initiating node must be either BOTH or OUTGOING. • The EXECUTOR DEFAULT PROXY parameter for the destination node must be either BOTH or INCOMING.
9-17 Security for a DECnet Node 9. 7 Proxy Logins
• The OBJECT PROXY parameter for the destination node must be either BOTH or INCOMING. • There must be an entry in NETPROXY.DAT on the destination node for the initiating node-user pair. For example, if the account HYDRA on the destination node of CRAB permits proxy access for user CLAW on node LOBSTER, the listing of NETPROXY.DAT for node CRAB includes the following entry: LOBSTER::CLAW HYDRA (D) 9. 7 .2 Special Proxy Access Considerations Proxy access is a selective merging of the authorization databases of the affected systems. Therefore, the security is only as good as the security of the least secure node. Although proxy access eliminates passwords going over the network, it is possible for a personal computer to bypass the proxy login mechanism by impersonating one of the authorized nodes. For this reason, the parameter INCOMING for proxy should not be used on important nodes. Never set up a proxy account with privileges that could damage your system. (Proxy accounts should be nonprivileged.) In general, timesharing nodes should not permit proxy access from standalone nodes.
9.8 Sharing Files in the Network Environment The easiest way for a user to transfer a text file to another user is to invoke the Mail utility (MAIL) and to send the user a copy of the file. This method is reasonably secure, because passwords need not be revealed and the original protection of the file is not changed. The receiving user simply includes a new file name with the MAIL command EXTRACT/NOHEADER to place a copy in the user's own directory. The copy automatically acquires the user's default protection. The user then uses the MAIL command DELETE to remove the copy from the mail file. Sites should discourage users from sharing passwords and changing file and directory protection codes to grant the world category read or execute access. Grant BYPASS or READALL privileges cautiously. The only secure method for sharing and exchanging files in the network environment is to set up proxy accounts and to place access control lists (ACLs) on the directories and files. 9.8.1 Admitting Remote Users for a Single Task A network manager may need to admit a number of users from outside nodes into a directory on the local node for a specific task. In this situation, the security administrator creates a proxy account and adds the proxy access to admit the outsiders into that one account. There may also be a number of users on the local node who need to share the files in this account's directory. To provide that access while protecting the files from outsiders, place ACLs on the directory and files. Consider an example where a central depository is needed for sales update information that a number of users scattered throughout the corporation need to read. The security administrator at the node where the files will reside (BERTHA) creates the special account SALES_READER. The SALES_READER account is set up as a captive account with mail disabled. The default directory is [SALESINFO], which has the following default protection code: (S:RWED,O:RWED,G:R,W)
9-18 Security for a DECnet Node 9.8 Sharing Files in the Network Environment
Note that this protection code permits users in the same group as SALES_ READER on the home node BERTHA to read the files. Furthermore, only the users in the system category or the owner category, or those who have privileges that give them such access, can update the files in the directory. ACLs are used to further define the access, as shown below. Next, the security administrator uses the AUTHORIZE command ADD/PROXY to add the proxy access for the outside users. For example, to extend proxy access to user Jackson on node DEXTER and user Goodwin on node BANGOR, the commands would be as follows: UAF> ADD/PROXY DEXTER::JACKSON SALES READER/DEFAULT UAF> ADD/PROXY BANGOR::GOODWIN SALES-READER/DEFAULT If later it becomes clear that other users at the home node BERTHA need access and they do not belong to the same group as SALES_READER, ACLs could be added to the files in the directory [SALESINFO]. For example, suppose R. Grant needs control access to all the files and J. Magoon needs read access to all the files. The following two DCL commands would define the ACL for the directory and then propagate it to all existing files: $ SET SECURITY/ACL=- $ ((IDENTIFIER=R GRANT,OPTIONS=DEFAULT,ACCESS=CONTROL), -$ (IDENTIFIER=J MAGOON,OPTIONS=DEFAULT,ACCESS=READ))- -$ [OOOOOO]SALESINFO.DIR $SET SECURITY/DEFAULT *.*;* 9.8.2 Admitting Remote Users to One Account When all (or nearly all) users at a remote node require access to one of your accounts, specify proxy access to the account with the following form of the AUTHORIZE command ADD/PROXY: ADD/PROXY remote-node::* local-account/DEFAULT Check to be certain that there are no guest accounts or other undesired accounts at the remote node. If you discover there are a few exceptions at the remote node, you cannot simply remove the extra users with REMOVE/PROXY commands because the preceding ADD/PROXY command creates a single entry in NETPROXY.DAT. Use the following technique to exclude specific individual users at the remote node from access to the proxy account: ADD/PROXY remote-node::* local-account/DEFAULT ADD/PROXY remote-node::FRED SPECIAL ACCOUNT/DEFAULT ADD/PROXY remote-node::GEORGE SPECIAL ACCOUNT/DEFAULT In the preceding example, all users on the remote node use the specified proxy account except users Fred and George, who are directed to use the SPECIAL_ ACCOUNT proxy account. 9.8.3 Admitting Remote Users to Multiple Accounts The preceding techniques work well when there are several outside users requiring access for one purpose. When a small number of outside users need access for multiple purposes involving files needing special protection, set up access to multiple proxy accounts and apply extensive ACLs. For example, a large corporation with many branch offices might find it desirable to establish several proxy accounts for specific purposes for sharing. Assume the central office wants to grant two key users from its two nodes in the eastern region read and write access to the project files for code name LEVIGRAY and read-only access to the BETSEYHARLOW project files. At the same time,
9-19 Security for a DECnet Node 9.8 Sharing Files in the Network Environment
there are three users from the western region who need read access to those LEVIGRAY files and require read and write access to the BETSEYHARLOW files. Only two users from the central office will have full access rights to the LEVIGRAY files, and two other users from headquarters will have full access rights to the BETSEYHARLOW files. For working purposes, the situation could be represented in tabular form, as shown in Example 9-3.
Example 9-3 Protected File Sharing in a Network Access Requirements to CENTRL::PROJ:[DESGN PROJECTS] Owned by [DESIGNERS,MGR] - Users & Nodes Subdirectory LEVI Subdirectory BETSEY Project Files Project Files LEVIGRAY*.* BETSEYHARLOW*.* FRISCO: : ALBION R RW FRISCO: :ELTON R RW LA: :IRVING R RW CENTRL::DIANTHA RWED NONE CENTRL::BRITTANIA RWED NONE CENTRL: : ALBERT NONE RWED CENTRL: : DELIA NONE RWED BOS : : AYLMER RW R WASH: :LAVINA RW R The following solution uses five proxy accounts in addition to the four local accounts on node CENTRL, plus ACLs on the directory, subdirectories, and files: 1. The security administrator at headquarters uses AUTHORIZE to create new proxy accounts on node CENTRL for the remote users Albion, Elton, Irving, Aylmer, and Lavina. These accounts should be captive, disallow mail, and be restricted to network access only. The accounts are even restricted to a subset of DCL through CLI tables. The default directory should be [DESGN_ PROJECTS] for each user. The manager decides it makes sense to put them into the DESIGNERS group to match their proposed uses of the files. Presumably, accounts already exist for users Diantha, Brittania, Albert, and Delia. They need not necessarily belong to the same group. They will be informed which device and directory to use for their work. 2. The next step is to add the proxy records to the network proxy authorization file with the following AUTHORIZE commands: UAF> ADD/PROXY FRISCO::ALBION ALBION/DEFAULT UAF> ADD/PROXY FRISCO::ELTON ELTON/DEFAULT UAF> ADD/PROXY LA::IRVING IRVING/DEFAULT UAF> ADD/PROXY BOS::AYLMER AYLMER/DEFAULT UAF> ADD/PROXY WASH::LAVINA LAVINA/DEFAULT 3. The security administrator at node CENTRL places an ACL on the top-level directory for [DESGN_PROJECTS] with the following DCL command: $ SET SECURITY/ACL=(DEFAULT PROTECTION,S:RWED,O,G,W) - _$ [OOOOOO]DESGN_PROJECTS.DIR
9-20 Security for a DECnet Node 9.8 Sharing Files in the Network Environment
This ensures that no one outside of the system category of users can gain any VIC-based access to the files in the directory or any of the subdirectories unless they possess the BYPASS privilege. In fact, this restriction applies to those five users in the group DESIGNERS as well. The plan is for all files to possess ACLs that will admit the select group of users. It is desirable to propagate this protection code to all the files in this directory and its subdirectories. (The ACLs that will be placed on the files for further protection will take precedence when one of these users actually seeks access to a file.) 4. Two subdirectories are created in [DESGN_PROJECTS]: • [DESGN_PROJECTS.LEVI] • [DESGN_PROJECTS.BETSEY] 5. The security administrator uses the ACL editor to place the following additional ACEs in the ACL for the top-level directory:
DESGN PROJECTS.DIR (IDENTIFIER=DIANTHA,OPTIONS=PROTECTED,ACCESS=EXECUTE) (IDENTIFIER=BRITTANIA,OPTIONS=PROTECTED,ACCESS=EXECUTE) (IDENTIFIER=ALBERT,OPTIONS=PROTECTED,ACCESS=EXECUTE) (IDENTIFIER=DELIA,OPTIONS=PROTECTED,ACCESS=EXECUTE) (IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACESS=EXECUTE) (IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=EXECUTE) (IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=EXECUTE) (IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=EXECUTE) (IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=EXECUTE) These protected ACEs ensure that only the select nine users can access the top-level directory. Because no one receives write or delete access to the top directory through the ACL, the directory and subdirectories are generally protected from deletion and renaming of files. (Of course, the system category of user obtains write and delete access through the VIC-based protection.) 6. Next, the security administrator creates ACLs on the subdirectories. The ACEs that are required are shown for their respective subdirectories:
[DESGN_PROJECTS]LEVI.DIR (IDENTIFIER=DIANTHA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL) (IDENTIFIER=DIANTHA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) (IDENTIFIER=BRITTANIA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL) (IDENTIFIER=BRITTANIA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) (IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=AYLMER,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=LAVINA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=READ) (IDENTIFIER=ALBION,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ) (IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=READ) (IDENTIFIER=ELTON,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ) (IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=READ) (IDENTIFIER=IRVING,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)
9-21 Security for a DECnet Node 9.8 Sharing Files in the Network Environment
[DESGN_PROJECTS]BETSEY.DIR (IDENTIFIER=ALBERT,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL) (IDENTIFIER=ALBERT,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) (IDENTIFIER=DELIA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL) (IDENTIFIER=DELIA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) (IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=ALBION,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=ELTON,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=IRVING,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE) (IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACCESS=READ) (IDENTIFIER=AYLMER,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ) (IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=READ) (IDENTIFIER=LAVINA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ) Note that both preceding ACLs include two ACEs for each identifier. The first ACE controls the access to the subdirectory. It denies delete access for the protection of the subdirectory and is not propagated to all the files created in the subdirectory. The second ACE for each identifier will automatically propagate to all files added to their respective subdirectories because of the inclusion of the Default attribute. Furthermore, the Protected attribute ensures that all the ACEs are protected from deletion except by specific action. At this point, all the groundwork has been completed. Over time, files are added to the subdirectories. Thus, when the user Lavina in Washington enters the following DCL command, the file LEVIGRAYMEM3.MEM is printed at node WASH: $COPY CENTRL::LEVIGRAYMEM3.MEM LP: However, if user Lavina tries to edit this file, the attempt fails because user Lavina is denied write access through the ACL. If there were many users involved in this scheme, it would soon become worthwhile to grant additional identifiers to the users. For example, each user who would be allowed read access to the files in the LEVI subdirectory might be given the identifier LEVI_READER, and so forth. The ACLs could then be shortened.
9-22 10 Using Protected Subsystems
For the most part, the OpenVMS operating system bases its security controls on user identity. Protected objects, such as files and devices, are accessible to individual users or groups of users. If an object's ACL or protection code allows a user the necessary access, then the user can make use of that object by using any available software. (See Chapter 4 for a description of OpenVMS object protection.) In a protected subsystem, an application protected by normal access controls serves as a gatekeeper to objects belonging to the subsystem. Users have no access to the subsystem's objects unless they execute the application serving as gatekeeper. Once users run the application, their process rights list acquires identifiers giving them access to objects owned by the subsystem. As soon as they exit from the application, these identifiers and, therefore, the users' access rights to objects are taken away. This chapter describes protected subsystems and explains how to build them. 10.1 Advantages of Protected Subsystems Using protected subsystems offers several advantages: • With protected subsystems, you have a mechanism to provide conditional access to data that is not available with traditional OpenVMS access controls. Traditionally, you give users privileges to bypass protection codes or access control lists (ACLs). In giving these privileges, however, you grant users a wide class of access. (Refer to Appendix A for information on the power different privileges carry.) Protected subsystems avoid extensive privilege use by individual users. • · Protected subsystems give you an alternative to installing images with privilege. Writing a secure privileged image requires skill, and failures can compromise system security. • Protected subsystems give you an alternative to creating protected shareable images (also called user-written system services). • Protected subsystems make system management easier because unprivileged users can manage them without much assistance from you. See Section 10.5 for details on system management requirements.
10-1 Using Protected Subsystems 10.2 Applications for Protected Subsystems
10.2 Applications for Protected Subsystems Protected subsystems have many applications, from databases to common system management situations. One use for a protected subsystem might be a group membership list that you want to make available to all group members. The list contains the names, addresses, personnel numbers, and interests of group members. When the membership list is set up as a protected subsystem, all members of the group can read selected information and update specific types of information. A protected subsystem might also solve the problem of confidential information being sent to printers in public areas. You could write an application to filter data for sensitive information. Confidential files would be sent to printers in restricted areas, while public files would be sent to any available printer. Any user with execute access to the application could use printers, but only through the protected subsystem. 10.3 How Protected Subsystems Work A protected subsystem is an application that, when run, causes the process running the application to be granted one or more identifiers. For as long as a user runs the subsystem, the user's process rights list carries these additional identifiers. Figure 10-1 shows how a protected subsystem adds a second level of access control to traditional controls.
Figure 10-1 How Protected Subsystems Differ from Normal Access Control
Traditional Access Control
Protection Process Check Protected Rights --.. Object ~+ List User
Enhanced Access Control of Protected Subsystems
Protection Process Protection Process Check Protected Rights List Check Protected Rights ..... Subsystem --.. with r -- Object ~+ List Image Subsystem IDs User
ZK-5229A-GE Users with execute access to the application gain access to the subsystem. Once in the subsystem, users can work with the data files and other resources of the subsystem. A subsystem can have several identifiers because the resources consumed by the subsystem (the files, printers, and so forth) can be protected differently.
10-2 Using Protected Subsystems 10.3 How Protected Subsystems Work
Possession of subsystem identifiers is limited to the period users are executing the application. Once the users exit from the application, the identifiers are removed from their process rights lists. Subsystem identifiers are also removed from the rights list whenever users enter a Ctrl/Y sequence or attempt to create a subprocess with the DCL command SPAWN. (In this respect, use of the subsystem identifiers is identical to the operation of images installed with privileges.) 10.4 Design Considerations Someone developing an application for a protected subsystem must link the application images without the /DEBUG or !rRACEBACK qualifiers. Although this kind of subsystem often precludes the need for privilege, applications can be installed with privilege. For example, some applications may need the PRMGBL privilege to create permanent global sections, or they may need the AUDIT privilege to send security audit records to the system security audit log file. Digital does discourage the installation of a protected subsystem application with privileges in the All category. This category includes such privileges as BYPASS, CMKRNL, and SYSPRV-privileges that allow a user to subvert OpenVMS access controls. See Table 5-5 for a list of OpenVMS privileges. Subsystem designers need to generate a list of identifiers that are necessary for it to operate as intended. Then the designers approach you, as the security administrator, to make the preparations described in Section 10.5. 10.5 System Management Requirements Although an unprivileged user can build and manage a protected subsystem, you need to be involved at two points in the process: at the beginning to create the necessary identifiers for the subsystem and at the end to mount the volume with the protected subsystem. You need to perform the following tasks: 1. Create identifiers for the subsystem, each with the subsystem attribute. The subsystem attribute empowers the identifier's holder to manage the subsystem. 2. Grant these subsystem identifiers with subsystem attributes to the people who will serve as managers of the subsystem. This enables them to assign the subsystem identifier to the images comprising the subsystem. 3. Give the subsystem managers control access to application images. They need control access so they can add subsystem ACEs to the image ACLs. 4. Give the subsystem managers control access to existing resources (printers, for example) that are to be managed by the protected subsystem. Although subsystem managers may need control access to key system resources, the ACL on the objects limits their access rights to only those resources. This may not be as dangerous as installing an image with SYSPRV.
10-3 Using Protected Subsystems 10.5 System Management Requirements
The following example shows how you can set up identifiers and the necessary application access so that users can manage a membership list: $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/IDENTIFIER MEMBERS SUBSYSTEM- 0 _UAF> /ATTRIBUTES=(SUBSYSTEM,RESOURCE) UAF> GRANT/IDENTIFIER MEMBERS SUBSYSTEM - f} UAF> /ATTRIBUTES=(SUBSYSTEM,RESOURCE) LOUIS UAF> GRANT/IDENTIFIER MEMBERS SUBSYSTEM - UAF> /ATTRIBUTES=(SUBSYSTEM,RESOURCE) WU $ SET SECURITY/ACL=(IDENTIFIER=MEMBERS SUBSYSTEM,- 8 _$ ACCESS=CONTROL) MEMBER_LIST.EXE -
0 Use AUTHORIZE to create a subsystem identifier called MEMBERS_ SUBSYSTEM. Notice that this identifier carries the Subsystem attribute. @ Make Louis and Wu holders of the identifier so they can manage the subsystem. 8 Give Louis and Wu control access to the subsystem image MEMBER_ LIST.EXE. Note that you create the subsystem identifier MEMBERS_SUBSYSTEM with the Resource attribute. This allows disk space to be charged to the identifier MEMBERS_SUBSYSTEM and not the individuals accessing the subsystem. (When using the Resource attribute, be careful to set the appropriate ACLs on directories [see Section 5.5.1.2.3].) 10.6 Building the Subsystem Once managers of the subsystem have the appropriate identifiers and access rights as described in Section 10.5, they can add the necessary ACEs to a subsystem image. Two kinds of ACEs are necessary to construct a subsystem: the application image receives a Subsystem ACE, and the objects managed by the subsystem receive Identifier ACEs. Therefore, building a subsystem requires the following steps: 1. Create a Subsystem ACE containing the subsystem identifier in the ACLs of the application images. A Subsystem ACE has the following format: (SUBSYSTEM,{IDENTIFIER=identifier[,ATTRIBUTES=attributes]}) 2. Grant access to the objects managed by the subsystem. You need to add an Identifier ACE to the ACL of the various objects belonging to the subsystem. Each Identifier ACE contains one of the subsystem identifiers in the following format: (IDENTIFIER=identifier, ACCESS=access-type[+ ... ]) In the following example, the subsystem manager uses the DCL command SET SECURITY to associate the subsystem identifier with the images comprising the subsystem. First, the subsystem manager adds a Subsystem ACE with
10-4 Using Protected Subsystems 10.6 Building the Subsystem
the identifier MEMBERS_SUBSYSTEM to the ACL of the application image MEMBER_LIST.EXE: $ SET SECURITY/ACL=(SUBSYSTEM,IDENTIFIER=MEMBERS SUBSYSTEM,- _$ ATTRIBUTES=RESOURCE} MEMBER_LIST.EXE - Then the subsystem manager adds an Identifier ACE with the subsystem identifier MEMBERS_SUBSYSTEM to the data files managed by the subsystem: $ SET SECURITY/ACL=(IDENTIFIER=MEMBERS SUBSYSTEM,- _$ ACCESS=READ+WRITE} MEMBER_DATA*.DAT- The DCL command SHOW SECURITY displays the security attributes of the files. For example: $ SHOW SECURITY MEMBER LIST.EXE MEMBER_LIST.EXE object of class FILE Owner: [STAFF] Protection: (System: RWED, Owner: RWED, Group, World: RE) Access Control List: (SUBSYSTEM,IDENTIFIER=MEMBERS_SUBSYSTEM,ATTRIBUTES=RESOURCE) $ SHOW SECURITY MEMBER DATA*.DAT MEMBER_DATA_l.DAT object of class FILE Owner: MEMBERS SUBSYSTEM Protection: (System: RWED, Owner: RWED, Group, World) Access Control List: (IDENTIFIER=MEMBERS_SUBSYSTEM,ACCESS=READ+WRITE} MEMBER_DATA_2.DAT object of class FILE Owner: MEMBERS SUBSYSTEM Protection: (System: RWED, Owner: RWED, Group, World} Access Control List: (IDENTIFIER=MEMBERS_SUBSYSTEM, ACCESS=READ+WRITE)
10.7 Enabling Protected Subsystems on a Trusted Volume A person with the SECURITY privilege can enable subsystems on a volume by using the /SUBSYSTEM qualifier on the MOUNT command. By default, subsystems are enabled only on the system disk. For other disks, you need to enable subsystems every time a volume is mounted. In the following example, a security administrator uses the MOUNT command with the /SUBSYSTEM qualifier to enable the processing of subsystem ACEs on device DUAO. Assume that this disk contains the subsystem with the identifier MEMBERS_SUBSYSTEM. $ MOUNT /SUBSYSTEM /SYSTEM DUAO: DOC WORKS The processing of Subsystem ACEs can be turned on and off dynamically with the DCL command SET VOLUME /SUBSYSTEM. This command is especially useful for the system disk, which is not mounted using the MOUNT command. Any person mounting a subsystem is responsible for knowing what is on the volume being mounted. Without this knowledge, an operator or system manager can inadvertently subvert system security. For example, it is easy for a user with privileges on one cluster to put an application holding a subsystem identifier on a volume and then take the volume to a naive operator on another cluster and request that it be mounted. Because the application holds an appropriate subsystem identifier, it feigns membership in a subsystem for which it is unauthorized. Therefore, mount volumes of only those users whom you trust, or thoroughly search a volume for Subsystem ACEs before you mount it as a subsystem.
10-5 Using Protected Subsystems 10.8 Giving Users Access
10.8 Giving Users Access All users with execute access to the main application image of the subsystem can use the data files and other objects under control of the subsystem if the subsystem allows the access. However, managers of the subsystem can restrict access to objects of the subsystem in the following ways: • They can create special identifiers for resources belonging to the subsystem that they do not want all members to access and add ACEs to these resources. Printers and other devices are obvious examples. • They can use compound expressions in ACEs and thus grant access conditionally. For example, the following ACE grants access to MEMBERS_ ADMIN when running MEMBERS_SUBSYSTEM, but not to MEMBERS_ ADMIN alone nor to other users holding the MEMBERS_SUBSYSTEM identifier: (ID=MEMBERS_SUBSYSTEM+MEMBERS_ADMIN, ACCESS=READ+WRITE) Remember that as long as users are executing the application image for the subsystem, their process rights list contains the subsystem identifier as well as their normal identifiers. However, as soon as users interrupt or exit from the application, their process rights list loses the subsystem identifier, and they lose access rights to the objects in the subsystem. Subsystem identifiers are not propagated by default when subprocesses are spawned.
10.9 Example of a Protected Subsystem R. D. Taylor Inc., a company specializing in building supplies, decides to set up a protected subsystem for its purchasing and accounts payable departments. Although the departments are in different parts of the company, they share a common database for recording purchases from suppliers. When the company's inventory drops below the desired level, the purchasing department is directed to order required supplies Purchasing personnel find suppliers (if necessary), assign purchase order numbers, and issue a purchase orders. When the goods arrive, the receiving and quality control departments check the contents against what was ordered, ensure the goods meet quality standards, and put the goods into inventory. Once the shipment is processed, the information goes to the accounts payable department, which settles the invoices. Administrators in the accounts payable department check the invoices against purchase orders and run a payments program to calculate the monies due to suppliers each week. Payments are recorded in a database, and checks are printed on a printer loaded with company checks. Using the subsystem lets the company meet two objectives: • It gives purchasing personnel the right to reference or record purchase orders in the company database, and it gives personnel in the accounts payable department the right to verify suppliers' invoices. Purchasing personnel with these tasks hold the SUPPLIERS_ORDERS identifier. Accounts payable personnel hold the ACCOUNTS_PAYABLE identifier. These employees run ORDERS.EXE to update the supplier information. The program stores data in ORDERS.DAT.
10-6 Using Protected Subsystems 10.9 Example of a Protected Subsystem
• It gives trusted administrators in the accounts payable department the right to update databases, calculate payments due, and print checks. (One printer, loaded with company checks, is used for this purpose.) These administrators hold the ACCOUNTS_PAYABLE identifier. The administrators run PAYMENTS.EXE to perform these tasks. The program records payments made in the data file PAYMENTS.DAT. The company appoints one employee, McGrey, to design and manage the subsystem. Figure 10-2 illustrates the directory structure of the Taylor subsystem, and Example 10-1 shows the command procedure she wrote to implement it.
Figure 10-2 Directory Structure of the Taylor Company's Subsystem
[000000]
Master Directory SUPPLIERS_SUBSYSTEM.DIR
[SUPPLIERS_SUBSYSTEM]
Top-Level Directory LIB.DIR EXE.DIR l 1 [SUPPLIERS_SUBSYSTEM.EXE] [SUPPLIERS_SUBSYSTEM.LIB]
Second-Level Directory ORDERS.EXE ORDERS.DAT PAYMENTS.EXE PAYMENTS.DAT
ZK-5970A-GE 10.9.1 Protecting the Top-Level Directory McGrey implements a directory structure in which users can gain access to the subsystem only by holding an appropriate identifier: purchasing personnel hold the identifier SUPPLIERS_ORDERS, and the accounts payable administrators hold the identifier ACCOUNTS_PAYABLE. As subsystem manager, McGrey holds the identifier SUPPLIERS_SUBSYSTEM. The top-level directory SUPPLIERS_SUBSYSTEM.DIR has the following protection: $ DIRECTORY/SECURITY SYS$SYSDEVICE:[OOOOOO]SUPPLIERS_SUBSYSTEM.DIR Directory SYS$SYSDEVICE:[OOOOOO] SUPPLIERS_SUBSYSTEM.DIR;l SUPPLIERS SUBSYSTEM (RWE,RWE,,) (D (CREATOR,ACCESS=NONE) f} (DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:) ~ (IDENTIFIER=SUPPLIERS SUBSYSTEM,ACCESS=READ+WRITE+CONTROL) (t (IDENTIFIER=SUPPLIERS-ORDERS,ACCESS=EXECUTE) ~ (IDENTIFIER=ACCOUNTS PAYABLE,ACCESS=EXECUTE) ~ (IDENTIFIER=*,ACCESS~NONE) fj
10-7 Using Protected Subsystems 10.9 Example of a Protected Subsystem
(IDENTIFIER=SUPPLIERS SUBSYSTEM,OPTIONS=DEFAULT,ACCESS=READ+WRITE+CONTROL) 0 (IDENTIFIER~SUPPLIERS ORDERS,OPTIONS=DEFAULT,ACCESS=EXECUTE) (IDENTIFIER=ACCOUNTS PAYABLE,OPTIONS=DEFAULT,ACCESS=EXECUTE) (IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE) Total of 1 file.
0 The directory's protection code gives read, write, and execute access to users in the system and owner categories but no access to group or world users. Therefore, group and world users have to gain access through the ACL. 8 A Creator ACE ensures that users creating files in this directory have no special access to them. (See Section 5.5.1.2 for information on Creator ACEs.) 8 A Default Protection ACE denies group and world users access to files created in directory. 0 McGrey holds the subsystem identifier SUPPLIERS_SUBSYSTEM. This ACE gives her read, write, and control access so she can manage the subsystem directories and images. 0 Holders of the SUPPIERS_ORDERS identifier have execute access so they can access files in subdirectories. 0 Holders of the ACCOUNTS_PAYABLE identifier have execute access so they can access files in subdirectories. 0 Users holding any other identifiers have no access. 0 McGrey added the Default attribute to all Identifier ACEs and includes them here so all Identifier ACEs are propagated to subdirectory ACLs. 10.9.2 Protecting Subsystem Directories The directory EXE.DIR has the same protection as the top-level directory because subsystem users need to access the subsystem images: ORDERS.EXE and PAYMENTS.EXE. The other directory, LIB.DIR, is more restricted because only the subsystem images and McGrey need access. $DIRECTORY/SECURITY SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM •.• ]
Directory SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM] EXE.DIR;! SUPPLIERS SUBSYSTEM (RWE,RWE,,) 0 (CREATOR,ACCESS=NONE) (DEFAULT PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:) (IDENTIFlER=SUPPLIERS SUBSYSTEM,ACCESS=READ+WRITE+CONTROL) (IDENTIFIER=SUPPLIERS-ORDERS,ACCESS=EXECUTE) (IDENTIFIER=ACCOUNTS PAYABLE,ACCESS=EXECUTE) (IDENTIFIER=*,ACCESS~NONE) (IDENTIFIER=SUPPLIERS SUBSYSTEM,OPTIONS=DEFAULT,ACCESS=READ+WRITE+CONTROL) (IDENTIFIER=SUPPLIERS-ORDERS,OPTIONS=DEFAULT,ACCESS=EXECUTE) (IDENTIFIER=ACCOUNTS PAYABLE,OPTIONS=DEFAULT,ACCESS=EXECUTE) (IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE)
10-8 Using Protected Subsystems 10.9 Example of a Protected Subsystem
LIB.DIR;! SUPPLIERS SUBSYSTEM (RWE,RWE,,) f) (CREATOR,ACCESS=NONE) (DEFAULT PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:) (IDENTIFIER=SUPPLIERS SUBSYSTEM,ACCESS=READ+WRITE+CONTROL) (IDENTIFIER=*,ACCESS=NONE) (IDENTIFIER=SUPPLIERS SUBSYSTEM,OPTIONS=DEFAULT,ACCESS=READ+WRITE+CONTROL) (IDENTIFIER=~,OPTIONS~DEFAULT,ACCESS=NONE) Total of 2 files.
0 [SUPPLIERS_SUBSYSTEM.EXE] has the same protection code and ACL as the parent directory shown in Section 10.9.1. Subsystem users need to run programs stored in this directory. @ [SUPPLIERS_SUBSYSTEM.LIB] has the same protection code but a more r,estrictive ACL because only the subsystem manager and the subsystem images need access. 10.9.3 Protecting the Images and Data Files As the following listing shows, the necessary company personnel can access the subsystem's images, ORDERS.EXE and PAYMENTS.EXE, but only the images can update the data files: Directory SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM.EXE] ORDERS.EXE;! SUPPLIERS SUBSYSTEM (RWED,RWED,,) 0 (SUBSYSTEM,IDENTIFIER=SUPPLIERS SUBSYSTEM,ATTRIBUTES=RESOURCE) (IDENTIFIER=SUPPLIERS SUBSYSTEM~ACCESS=READ+WRITE+CONTROL) (IDENTIFIER=SUPPLIERS-ORDERS,ACCESS=EXECUTE) (IDENTIFIER=ACCOUNTS PAYABLE,ACCESS=EXECUTE) (IDENTIFIER=*,ACCESS~NONE) PAYMENTS.EXE;! SUPPLIERS SUBSYSTEM (RWED,RWED,,) f) (SUBSYSTEM,IDENTIFIER=SUPPLIERS SUBSYSTEM,ATTRIBUTES=RESOURCE) (IDENTIFIER=SUPPLIERS SUBSYSTEM~ACCESS=READ+WRITE+CONTROL) (IDENTIFIER=ACCOUNTS PAYABLE,ACCESS=EXECUTE) (IDENTIFIER=*,ACCESS~NONE) Total of 2 files. Directory SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM.LIB] ORDERS.DAT;! SUPPLIERS SUBSYSTEM (RWED,RWED,,) (IDENTIFIER=SUPPLIERS SUBSYSTEM,ACCESS=READ+WRITE) (IDENTIFIER=*,ACCESS=NONE) PAYMENTS.DAT;! SUPPLIERS SUBSYSTEM (RWED,RWED,,) (IDENTIFIER=SUPPLIERS SUBSYSTEM,ACCESS=READ+WRITE) (IDENTIFIER=*,ACCESS=NONE) Total of 2 files. Grand total of 3 directories, 6 files.
0 All subsystem users, those holding the SUPPLIERS_ORDERS or ACCOUNTS_PAYABLE identifier, can run ORDERS.EXE. f) Only subsystem images and holders of the ACCOUNTS_PAYABLE identifier can run PAYMENTS.EXE. 0 The data files for the subsystem reside in [SUPPLIERS_SUBSYSTEM.LIB]. Only the subsystem images and McGrey can access them.
10-9 Using Protected Subsystems 10.9 Example of a Protected Subsystem
10.9.4 Protecting the Printer The print queue for checks needs equal protection. Access is restricted to trusted administrators because they are the only ones who hold both the subsystem and the ACCOUNTS_PAYABLE identifiers. The printer loaded with checks is protected against group and world access. Only the subsystem manager and subsystem images have access to it. The following ~isplay shows that the queue is protected in such a way that only the trusted administrators can queue jobs to the printer: $ SHOW SECURITY/CLASS=QUEUE TTAl
TTAl object of class QUEUE Owner: [SYSTEM] Protection: (System: M, Owner: D, Group, World) Access Control List: (IDENTIFIER=SUPPLIERS SUBSYSTEM+ACCOUNTS PAYABLE,- ACCESS=READ+SUBMIT+MANAGE+DELETE) - (IDENTIFIER=*,ACCESS=NONE)
$ SHOW SECURITY/CLASS=DEVICE TTAl
FRODO$TTA1: object of class DEVICE - Owner: [SYSTEM] Protection: (System: RWPL, Owner: RWPL, Group, World) Access Control List: (IDENTIFIER=SUPPLIERS SUBSYSTEM,ACCESS=READ+WRITE+CONTROL) (IDENTIFIER=*,ACCESS=NONE)
10.9.5 Command Procedure for Building the Subsystem Example 10-1 shows the command procedure used to create the R. D. Taylor subsystem.
10-10 Using Protected Subsystems 10.9 Example of a Protected Subsystem
Example 10-1 Subsystem Command Procedure
$ SET NOON $ OLD PRIV = F$SETPRV("NOALL,SYSPRV,CMKRNL,OPER") $ OLD=DEFAULT = F$ENVIRONMENT("DEFAULT") $ $ ON CONTROL Y THEN GOTO LEAVE $ $ IF Pl .EQS. "REMOVE" THEN GOTO CLEANUP $ IF Pl .EQS. "VERIFY" THEN SET VERIFY $ ! $! Create the subsystem identifier and the identifiers for personnel $! performing two different tasks $! $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE ADD/IDENTIFIER SUPPLIERS SUBSYSTEM/ATTRIBUTES=(RESOURCE,SUBSYSTEM) ADD/IDENTIFIER SUPPLIERS-ORDERS ADD/IDENTIFIER ACCOUNTS PAYABLE ! ! Grant the subsystem identifier to the subsystem manager: McGrey. ! GRANT/IDENTIFIER SUPPLIERS SUBSYSTEM MCGREY/ATTRIBUTE=(RESOURCE,SUBSYSTEM) $! - $! Set up the print queue. $! $ SET SECURITY/ACL=((ID=SUPPLIERS SUBSYSTEM,ACCESS=READ+WRITE+CONTROL), - (ID=*,ACCESS=NONE))/PROTECTION=(G,W)/CLASS=DEVICE TTAl: $ INITIALIZE/QUEUE/START TTAl $ SET SECURITY/ACL=(- (ID=SUPPLIERS SUBSYSTEM+ACCOUNTS PAYABLE,ACCESS=READ+SUBMIT+MANAGE+DELETE), - (ID=*,ACCESS=NONE))/PROTECTION=(G,W)/CLASS=QUEUE TTAl: $! $! Create the directory root to hold the subsystem. $ ! $! $ ! Assume that we logged in as McGrey. $ ! $ SET RIGHTS/ENABLE SUPPLIERS SUBSYSTEM/ATTRIBUTE=(RESOURCE,SUBSYSTEM) $ SET DEFAULT SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM] $ ! $ ! Create the directories for the images and the data files. $ ! $ CREATE/DIR [SUPPLIERS SUBSYSTEM.EXE]/PROTECTION=(G,W) $ CREATE/DIR [SUPPLIERS-SUBSYSTEM.LIB]/PROTECTION=(G,W) $ SET SECURITY/ACL=((ID~SUPPLIERS ORDERS,ACCESS=EXECUTE), - (ID=ACCOUNTS PAYABLE,ACCESS~EXECUTE), - (ID=SUPPLIERS ORDERS,OPTIONS=DEFAULT,ACCESS=EXECUTE), - (ID=ACCOUNTS PAYABLE,OPTIONS=DEFAULT,ACCESS=EXECUTE))/DELETE - - [SUPPLIERS_SUBSYSTEM]LIB.DIR $! $! Emulate the creation of the subsystem images. $ ! $ SET DEFAULT [.EXE] $ CREATE ORDERS.MAR .ENTRY START,O $setpri s pri=#O 10$: BRB 10$ - ret .END START $ MACRO ORDERS
(continued on next page)
10-11 Using Protected Subsystems 10.9 Example of a Protected Subsystem
Example 10-1 (Cont.) Subsystem Command Procedure $ LINK ORDERS $ SET SECURITY/PROTECTION=(W:RWED) ORDERS.MAR;*,.OBJ;* $ DELETE ORDERS.MAR;*,.OBJ;* $ COPY ORDERS.EXE PAYMENTS.EXE $! $! Apply the appropriate protection to the images. $! $ SET SECURITY/ACL=(ID=SUPPLIERS ORDERS,ACCESS=EXECUTE)/DELETE PAYMENTS.EXE $ SET SECURITY/ACL=(SUBSYSTEM,ID~SUPPLIERS SUBSYSTEM,ATTRIBUTES=RESOURCE) ORDERS.EXE $ SET SECURITY/ACL=(SUBSYSTEM,ID=SUPPLIERS=SUBSYSTEM,ATTRIBUTES=RESOURCE) PAYMENTS.EXE $! $! Create and protect the data files used by the applications. $! $ SET DEFAULT [-.LIB] $ CREATE ORDERS.DAT $ CREATE PAYMENTS.DAT $ SET SECURITY/ACL=((ID=SUPPLIERS SUBSYSTEM,ACCESS=READ+WRITE), - (ID=*,ACCESS=NONE)) ORDERS.DAT $ SET SECURITY/LIKE=(NAME=ORDERS.DAT) PAYMENTS.DAT $! $! Show the directory structure and the device and queue protection. $ ! $ SET DEFAULT 'OLD DEFAULT' $ DEFINE SYS$0UTPUT SUBSYS.LIS $ DIRECTORY/SECURITY SYS$SYSDEVICE:[OOOOOO]SUPPLIERS SUBSYSTEM.DIR $ DIRECTORY/SECURITY SYS$SYSDEVICE:[SUPPLIERS SUBSYSTEM •.. ] $ SHOW SECURITY/CLASS=DEVICE TTAl - $ SHOW SECURITY/CLASS=QUEUE TTAl $ DEASSIGN SYS$0UTPUT $ $ LEAVE: $ IF Pl .EQS. "VERIFY" THEN SET NOVERIFY $ SET DEFAULT 'OLD DEFAULT' $ SET PROC/PRIV=('OLD PRIV') $ EXIT - $ $ CLEANUP: $ SET PROC/PRIV=BYPASS $ SET DEFAULT SYS$SYSDEVICE:[OOOOOO] $ DELETE [SUPPLIERS SUBSYSTEM ••• ]*.*·* $ DELETE [SUPPLIERS-SUBSYSTEM]EXE.DIR; $ DELETE [SUPPLIERS-SUBSYSTEM]LIB.DIR; $ DELETE SUPPLIERS SUBSYSTEM.DIR; $ STOP/QUE/NEXT TTAl $ DELETE/QUEUE TTAl $ GOTO LEAVE
10-12 A Assigning Privileges
Privileges restrict the use of certain system functions to processes created on behalf of authorized users. These restrictions protect the integrity of the operating system's code, data, and resources and thus, the integrity of user service. Grant privileges to individual users only after carefully considering the following two factors: • Whether the user has the skill and experience to use the privilege without disrupting the system • Whether the user has a legitimate need for the privilege Privileges fall into the following seven categories according to the damage that the user possessing them could cause the system: • None: No privileges • Normal: Minimum privileges to use the system effectively • Group: Potential to interfere with members of the same group • Devour: Potential to consume noncritical systemwide resources • System: Potential to interfere with normal system operation • Objects: Potential to compromise the security of protected objects (files, devices, logical name tables, global sections, and so on) • All: Potential to control the system Users cannot execute an image that requires a privilege they do not possess, unless the image is installed as a known image with the privilege in question or the image runs within a protected subsystem. (See the Open VMS System Management Utilities Reference Manual for information on installing privileged known images.) Execution of a known image with temporary privileges (for the duration of the image's execution) grants those privileges to the user process executing the image. Thus, you should install user images with amplified privileges only after ensuring that the user needs the access and is unlikely to misuse it. When a privileged image runs within a protected subsystem, a user can execute the image because the user's process holds a subsystem identifier granting access. That subsystem identifier can be held only while the user's process is within the subsystem. A user's privileges are recorded in the user's UAF record in a 64-bit privilege mask. When a user logs in to the system, the user's privileges are stored in the header of the user's process. In this way, the user's privileges are passed on to the process created for the user. Users can use the DCL command SET PROCESS/PRIVILEGES to enable and disable privileges for which they are authorized and to further control the privileges available to the images they run. Moreover, any user with the SETPRV privilege can enable any privilege.
A-1 Assigning Privileges
Table 5-5 lists the privileges by category and gives brief, general definitions of them. The following sections describe all privileges available on OpenVMS systems; each section title identifies the privilege category (Normal, Devour, and so on). For each privilege, the appendix describes the capabilities granted by the privilege and the users who should receive them. Note that a system manager can select specific privileges to control the use of DECnet objects, which are specified during network configuration. In such instances, it becomes a privileged operation to connect to a privileged DECnet object or use an outgoing DECnet object.
A.1 ACNT Privilege (Devour) The ACNT privilege lets a process use the RUN (Process) command and the Create Process ($CREPRC) system service to create processes in which accounting is disabled. A process in which accounting is disabled is one whose resource usage is not logged in the current accounting file. A.2 ALLSPOOL Privilege (Devour) The ALLSPOOL privilege lets the user's process allocate a spooled device by executing the Allocate Device ($ALLOC) system service or by using the DCL command ALLOCATE. The $ALLOC system service lets a process allocate or reserve a device for its exclusive use. A shareable mounted device cannot be allocated. Grant this privilege only to users who need to perform logical or physical I/O operations to a spooled device. Ordinarily, the privilege of allocating a spooled device is granted only to symbionts. A.3 ALTPRI Privilege (System) The ALTPRI privilege allows the user's process to: • Increase its own base priority • Set the base priority of a target process • Change the priority of its batch or print jobs The base priority is increased by executing the Set Priority ($SETPRI) system service or the DCL command SET PROCESS/PRIORITY. As a rule, this system service lets a process set its own base priority or the base priority of another process. However, one process can set the priority of a second process only if one of the following conditions applies: • The process calling the $SETPRI system service has the same UIC as the target process. • The calling process has process control privilege (GROUP or WORLD) over the target process. With ALTPRI, a process can create a detached process with a priority higher than its own. It creates such a process by using an optional argument to the Create Process ($CREPRC) system service or to the DCL command RUN/PRIORITY. ALTPRI also lets you adjust the scheduling priority of a job ($SNDJBC) to a value even greater than that established with the system parameter MAXQUEPRI.
A-2 Assigning Privileges A.3 ALTPRI Privilege {System)
Do not grant this privilege widely; if unqualified users have the unrestricted ability to set base priorities, fair and orderly scheduling of processes for execution can easily be disrupted. A.4 AUDIT Privilege (System) The AUDIT privilege allows software to append audit records to the system security audit log file using one of four system services: $AUDIT_EVENT, $CHECK_PRIVILEGE, $CHKPRO, or $CHECK_ACCESS. In addition, the $AUDIT_EVENT system service allows all components of an audit message to be specified. As a result, this privilege permits the logging of events that appear to have come from the operating system or another user process. Grant this privilege only to trusted images that need to append audit messages to the system audit log file. Users possessing this privilege can provoke a system failure by attempting to log invalid events with the NSA$M_INTERNAL flag set. A.5 BUGCHK Privilege {Devour) The BUGCHK privilege allows the process to make bugcheck error log entries from user, supervisor, or compatibility mode (EXE$BUG_CHECK) or to send messages to the system error logger ($SNDERR). Restrict this privilege to Digital-supplied system software that uses the Bugcheck facility. A.6 BYPASS Privilege (All) The BYPASS privilege allows the user's process full access to all protected objects, totally bypassing UIC-based protection, access control list (ACL) protection, and mandatory access controls. With the BYPASS privilege, a process has unlimited access to the system. Among the operations that can be performed are: • Modification of all user authorization records (SYSUAF.DAT) • Modification of all rights identifier and holder records (RIGHTSLIST.DAT) • Modification of all network proxy records (NETPROXY.DAT) • Modification of all DECnet object passwords and accounts (NETOBJECT.DAT) • Unlimited access to all files on all volumes Grant this privilege with extreme caution because it overrides all object protection. It should be reserved for use by well-tested, reliable programs and command procedures. The SYSPRV privilege is adequate for interactive use because it ultimately grants access to all objects while still providing access checks. The READALL privilege is adequate for backup operations. The BYPASS privilege lets a process perform the following tasks:
Task Interface Perform file system operations: Modify file ownership SET SECURITY/OWNER, $QIO request to FllBXQP Access a file that is marked for deletion $QIO request to FllA ACP or FllBXQP Access a file that is deaccess locked $QIO request to FllA ACP or FllBXQP
A-3 Assigning Privileges A.6 BYPASS Privilege (All)
Task Interface
Override creation of an owner ACE on a newly $QIO request to FllBXQP created file Clear the directory bit in a directory's file header $QIO request to FllBXQP Operate on an extension header $QIO request to FllBXQP Acquire or release a volume lock $QIO request to FllBXQP Force mount verification on a volume $QIO request to FllBXQP Create a file access window with the no access $QIO request to FllBXQP lock bit set Specify null lock mode for volume lock $QIO request to FllBXQP Access a locked file $QIO request to FllBXQP Enable or disable disk quotas on a volume $QIO request to FllBXQP Operate on network databases: Display permanent network database records NCP Display permanent DECnet object password NCP Display volatile DECnet object password NCP Adjust discretionary or mandatory access controls: Read a user authorization record $GETUAI Modify a user authorization record $SETUAI Modify mailbox protection $QIO request request to the mailbox driver (MBDRIVER) Modify shared memory mailbox protection $QIO request request to the mailbox driver (MBXDRIVER) Bypass discretionary or mandatory object $CHKPRO protection Miscellaneous: Initialize a magnetic tape $INIT_VOL Unload an Info Server $QIO request request to the lnfoServer (DADDRIVER)
A.7 CMEXEC Privilege (All) The CMEXEC privilege allows the user's process to execute the Change Mode to Executive ($CMEXEC) system service. This system service lets a process change its access mode to executive mode, execute a specified routine, and then return to the access mode that was in effect before the system service was called. While in executive mode, the process is allowed to execute the Change Mode to Kernel ($CMKRNL) system service. Grant this privilege only to users who need to gain access to protected and sensitive data structures and internal functions of the operating system. If unqualified users have unrestricted access to sensitive data structures and functions, the operating system and service to other users can be easily disrupted. Such disruptions can include failure of the system, destruction of all system and user data, and exposure of confidential information.
A-4 Assigning Privileges A.8 CMKRNL Privilege (All)
A.8 CMKRNL Privilege (All) The CMKRNL privilege allows the user's process to execute the Change Mode to Kernel ($CMKRNL) system service. This system service lets a process change its access mode to kernel mode, execute a specified routine, and then return to the access mode that was in effect before the system service was called. While in kernel mode, a process can enable any system privilege. A process holding both CMKRNL and SYSNAM can set the system time. Grant this privilege only to users who need to execute privileged instructions or who need to gain access to the most protected and sensitive data structures and functions of the operating system. If unqualified users have unrestricted use of privileged instructions and unrestricted access to sensitive data structures and functions, the operating system and service to other users can be easily disrupted. Such disruptions can include failure of the system, destruction of all system and user data, and exposure of confidential information. The CMKRNL privileges lets a process perform the following tasks:
Task Interface Modify a multiprocessor operation START/CPU, STOP/CPU Modify systemwide RMS defaults SET RMS/SYSTEM Suspend a process in kernel mode SET PROCESS/SUSPEND=KERNEL Modify another process' rights list or its SET RIGHTS nondynamic identifier attributes Grant an identifier with modified attributes SET RIGHTS/ATTRIBUTE Modify the system rights list SET RIGHTS/SYSTEM Change a process UIC SET VIC Modify the number of interlocked queue retries $QIO request to an Ethernet 802 driver (DEBNA/NI) Connect to a device interrupt vector $QIO request to an interrupt vector (CONINTERR) Start or modify a line in Genbyte mode $QIO request to a synchronous communications line (XGDRIVER) Set the spin-wait time on the port command $QIO request to an Ethernet 802 register driver (DEBNA) Modify a known image list INSTALL Process the following item codes: Send to Job Controller system service ($SNDJBC) SJC$_ACCOUNT_NAME item SJC$_UIC SJC$_USERNAME
Create a detached process with unrestricted RUN/DETACHED, $CREPRC quotas
A-5 Assigning Privileges A.9 DETACH Privilege (All)
A.9 DETACH Privilege (All) Processes can create detached processes that have their own UIC without the DETACH privilege, provided the processes do not exceed their MAXJOBS and MAXDETACH quotas. However, the DETACH privilege becomes valuable when a process wants to specify a different UIC for the detached process. There is no restriction on the UIC that can be specified for a detached process if you have the DETACH privilege. Thus, there are no restrictions on the files, directories, and other objects to which a detached process can gain access. In addition, the DETACH privilege lets a process create a detached process with unrestricted quotas. A process can create detached processes by executing the Create Process ($CREPRC) system service. Detached processes remain in existence even after the user who created them has logged out of the system. A.10 DIAGNOSE Privilege (Objects) The DIAGNOSE privilege lets a process run online diagnostic programs and intercept and copy all messages written to the error log file. The DIAGNOSE privilege also lets a process perform the following tasks:
Task Interface Issue a $QIO request with associated diagnostic $QIO buffer Modify the number of interlocked queue retries $QIO request to an Ethernet 802 driver (DEBNA/NI) Set the spin wait time on the port command $QIO request to an Ethernet 802 register driver (DEBNA) Access the Diagnostic and Utilities Protocol $QIO request to the DUP class driver (DUP) class driver used by SET HOST/HSC (FYDRIVER) Execute a special passthrough function in the $QIO request to the SCSI driver SCSI generic class driver (GKDRIVER) Process a diagnostic buffer $QIO request to a TU58 magnetic tape (TUDRIVER)
A.11 DOWNGRADE Privilege (All) The DOWNGRADE privilege permits a process to manipulate mandatory access controls. The privilege lets a process write to an object of lower secrecy, in violation of the Bell and LaPadula confinement (*) property.1 This privilege is reserved for enhanced security products like SEVMS. A.12 EXQUOTA Privilege (Devour) The EXQUOTA privilege allows the space taken by the user's files on given disk volumes to exceed any usage quotas set for the user (as determined by UIC) on those volumes.
1 Name of the restriction on write-downs. Multilevel security requires the complete prohibition of write-downs by untrusted software.
A-6 Assigning Privileges A.13 GROUP Privilege {Group)
A.13 GROUP Privilege (Group) The GROUP privilege allows the user's process to affect other processes in its own group by executing the following process-control system services: Suspend Process ($SUSPND) Resume Process ($RESUME) Delete Process ($DELPRC) Set Priority ($SETPRI) Wake ($WAKE) Schedule Wakeup ($SCHDWK) Cancel Wakeup ($CANWAK) Force Exit ($FORCEX) With GROUP privilege, a user's process can control another process in the same group. The user's process is allowed to examine other processes in its own group by executing the Get Job/Process Information ($GETJPI) system service. A process with GROUP privilege can issue the SET PROCESS command for other processes in its group. GROUP privilege is not needed for a process to exercise control over, or to examine, subprocesses that it created or other detached processes of its UIC. You should, however, grant this privilege to users who need to exercise control over the processes and operations of other members of their UIC group.
A.14 GR~NAM Privilege (Devour) The GRPNAM privilege lets the user's process bypass discretionary access controls and insert names into (and delete names from) the logical name table of the group to which the process belongs by the use of the Create Logical Name ($CRELNM) and Delete Logical Name ($DELLNM) system services. In addition, the privileged process can issue the DCL commands ASSIGN and DEFINE to add names to the group logical name table and the DCL command DEASSIGN to delete names from the table. The privilege allows the use of the /GROUP qualifier with the DCL commands MOUNT and DISMOUNT (as well as the system services $MOUNT and $DISMOUNT) when sharing volumes among group members. Do not grant this privilege to all users of the system because it allows the user's process to create an unlimited number of group logical names. When unqualified users have the unrestricted ability to create group logical names, excessive use of system dynamic memory can degrade system performance. In addition, a process with the GRPNAM privilege can interfere with the activities of other processes in the same group by creating definitions of commonly used logical names such as SYS$SYSTEM. A.15 GRPPRV Privilege (Group) When the process's group matches the group of the object owner, the GRPPRV privilege gives a process the access rights provided by the object's system protection field. GRPPRV also lets a process change the protection or the ownership of any object whose owner group matches the process's group by using the DCL commands SET SECURITY.
A-7 Assigning Privileges A.15 GRPPRV Privilege (Group)
Grant this privilege only to users who function as group managers. If this privilege is given to unqualified users who have no need for it, they can modify group UAF records to values equal to those of the group manager. They can increase resource allocations and grant privileges for which they are authorized. The GRPPRV privilege lets a process perform the following tasks:
Task Interface Modify object ownership SET SECURITY/OWNER, $QIO request to FllBXQP Read or modify a user authorization record $GETUAI, $SETUAI File system operations: $QIO request to FllBXQP
• Override the creation of an owner ACE on a newly created file • Clear the directory bit in a directory's file header • Operate on an extension header • Acquire or release a volume lock • Force mount verification on a volume • Create a file access window with the no access lock bit set • Specify a null lock mode for a volume lock • Access a locked file • Enable or disable disk quotas on a volume
A.16 IMPORT Privilege {Objects) The IMPORT privilege lets a process manipulate mandatory access controls. The privilege lets a process mount unlabeled tape volumes. This privilege is reserved for enhanced security products like SEVMS. A.17 LOG_IO Privilege {All) The LOG_IO privilege lets the user's process execute the Queue I/O Request ($QIO) system service to perform logical-level I/O operations. LOG_IO privilege is also required for certain device control functions, such as setting permanent terminal characteristics. A process with the typical privileges of NETMBX and TMPMBX that also holds LOG_IO and SYSNAM can reconfigure the Ethernet using the Phase IV network configuration procedure, NICONFIG.COM. Usually, process I/O requests are handled indirectly by use of an I/O package such as OpenVMS Record Management Services (RMS). However, to increase their control over I/O operations and to improve the efficiency of I/O operations, skilled users sometimes prefer to handle the interface between their process and a system I/O driver program directly. They can do this by executing $QIO; in many instances, the operation called for is a logical-level I/O operation. Note that logical level functions are permitted without LOG_IO privilege on a device mounted with the /FOREIGN qualifier and on non-file-structured devices.
A-8 Assigning Privileges A.17 LOG_IO Privilege (All)
Grant this privilege only to users who need it because it allows a process to access data anywhere on the selected volume without the benefit of any file structuring. If this privilege is given to unqualified users who have no need for it, the operating system and service to other processes can be easily disrupted. Such disruptions can include the destruction of information on the system device, the destruction of user data, and the exposure of confidential information. The LOG_IO privilege also lets a process perform the following tasks:
Task Interface Issue physical 1/0 calls to a private, non-file $QIO structured device Modify the following terminal attributes: SET TERMINAL (or TTDRIVER) HANGUP /[NO]HANGUP SET_SPEED /[NO]SET_SPEED SECURE_SERVER /[NO]SECURE_SERVER
A.18 MOUNT Privilege (Normal) The MOUNT privilege lets the user's process execute the mount volume QIO function. The use of this function should be restricted to system software supplied by Digital. A.19 NETMBX Privilege (Normal) The NETMBX privilege lets a process perform functions related to a DECnet computer network. For example, it allows a process to switch a terminal line to an asynchronous DECnet protocol or assign a channel to a network device. Grant this privilege to general users who need to access the network. A.20 OPER Privilege (System) The OPER privilege allows a process to use the Operator Communication Manager (OPCOM) process to reply to user's requests, to broadcast messages to all terminals logged in, to designate terminals as operators' terminals and specify the types of messages to be displayed on these operators' terminals, and to initialize and control the log file of operators' messages. In addition, this privilege lets the user spool devices, create and control all queues, and modify the protection and ownership of all non-file-structured devices. Grant this privilege only to the operators of the system. These are the users who respond to the requests of ordinary users, who tend to the needs of the system's peripheral devices (mounting reels of tape and changing printer forms), and who attend to all the other day-to-day chores of system operation. (A nonprivileged user can log in on the console terminal to respond to operator requests, for example, to mount a tape.)
A-9 Assigning Privileges A.20 OPER Privilege (System)
The OPER privilege lets a process perform the following tasks:
Task Interface Modify device protection SET PROTECTION/DEVICE Modify device ownership SET PROTECTION/DEVICE/OWNER Access the SYSMAN utility SYS MAN Perform operator tasks: Issue a broadcast reply REPLY, $SNDOPR Cancel a system operator request REPLY/ABORT, $SNDOPR Initialize the system operator log file $SNDOPR Reply to a pending system operator request REPLY/TO, REPLY/PENDING, REPLY/INITIALIZE_ TAPE, $SNDOPR Issue a system operator request REQUEST, $SNDOPR Enable system operator classes REPLY/ENABLE, $SNDOPR, $SNDMSG Disable system operator classes REPLY/DISABLE, $SNDOPR Send a broadcast message $BRKTHRU, $BRDCST Write an event to the operator log $SNDOPR Initialize a system operator log REPLY/LOG, $SNDOPR Close the current operator log REPLY/NOLOG,$SNDOPR Send a message to an operator REPLY, $SNDOPR Enable or disable autostart $SNDJBC (SJC$_DISABLE_AUTO_START, SJC$_ ENABLE_AUTO_START) Stop all queues $SNDJBC (SJC$_STOP_ALL_QUEUES_ON_NODE) Modify the characteristics of devices: Modify device availability SET DEVICE/[NOJAVAILABLE Modify device dual-porting SET DEVICE/[NOJDUAL_PORT Modify device error logging SET DEVICE/[NOJERROR_LOGGING Modify device spooling SET DEVICE/[NOJSPOOLED Modify default definitions of days: Set default day type to PRIMARY SET DAY/PRIMARY Set default day type to SECONDARY SET DAY/SECONDARY Return day type to DEFAULT SET DAY/DEFAULT Modify or override login limits: Modify interactive login limit SET LOGIN/INTERACTIVE Modify network login limit SET LOGIN/NETWORK Modify batch login limit SET LOGIN/BATCH Create and modify queues: Bypass discretionary access to a queue Create a queue $SNDJBC (SJC$_CREATE_QUEUE) Define queue characteristics $SNDJBC (SJC$_DEFINE_CHARACTERISTICS) Define forms $SNDJBC (SJC$_DEFINE_FORM) Delete characteristics $SNDJBC (SJC$_DELETE_CHARACTERISTICS) Delete forms $SNDJBC (SJC$_DELETE_FORM)
A-10 Assigning Privileges A.20 OPER Privilege (System)
Task Interface
Set the base priority of batch processes $SNDJBC (SJC$_BASE_PRIORITY) Set the scheduling priority of a job $SNDJBC (SJC$_PRIORITY) Start accounting SET ACCOUNTING/ENABLE, $SNDJBC (SJC$_ START_ACCOUNTING) Stop accounting SET ACCOUNTING/DISABLE, $SNDJBC (SJC$_ STOP_ACCOUNTING) Operate the LAT device: Transmit LAT solicit information message $QIO request to a LAT port driver (LTDRIVER) Set static rating for LAT service $QIO request to a LAT port driver (LTDRIVER) Read last LAT response message buffer $QIO request to a LAT port driver (LTDRIVER) Change port type from dedicated to application $QIO request to a LAT port driver (LTDRIVER) Change port type from application to dedicated $QIO request to a LAT port driver (LTDRIVER) Modify tape operations: Specify number of file window mapping pointers MOUNT/WINDOWS, $MOUNT Mount a volume with an alternate ACP MOUNT/PROCESSOR, $MOUNT Mount a volume with alternate cache limits MOUNT/CACHE, $MOUNT Modify write caching for a tape controller MOUNT/CACHE, $MOUNT Modify ODSl directory FCB cache limit SET VOLUME/ACCESSED, MOUNT/ACCESSED, $MOUNT Perform network operations: Connect to an object while executor state is restricted Read network event logging buffer NETACP Modify network volatile database NETACP Access the permanent database for an update DECnet/NML Connect to a DECnet circuit $QIO request to the DECnet downline load and loopback class driver (NDDRIVER) Display the permanent DECnet service password NCP Display the volatile DECnet service password NCP Control character conversion by terminals: Load terminal fallback table TFU, $QIO request to the terminal fallback driver (FBDRIVER) Unload terminal fallback table TFU, $QIO request to the terminal fallback driver (FBDRIVER) Establish system default terminal fallback table TFU, $QIO request to the terminal fallback driver (FBDRIVER) Control cluster operations: Request expected votes modification SET CLUSTER/EXPECTED_VOTES Request MSCP serving of a device SET DEVICE/SERVED Request quorum modification SET CLUSTER/QUORUM Add an adapter to the failover list $QIO request to the DEBNI BI-bus NI driver (EFDRIVER) Remove an adapter from the failover list $QIO request to the DEBNI BI-bus NI driver (EFDRIVER)
A-11 Assigning Privileges A.20 OPER Privilege {System)
Task Interface
Set an adapter to be the current adapter $QIO request to the DEBNI Bl-bus NI driver (EFDRIVER) Set the new adapter test interval $QIO request to the DEBNI BI-bus NI driver (EFDRIVER)
Used in combination with other privileges, OPER lets processes perform the following tasks:
Privileges Task Interface OPER and CMKRNL Mount a volume with a private MOUNT/PROCESSOR, $MOUNT ACP OPER and LOG_IO Set the system time SET TIME, $SETIME OPER and SYSNAM Start or stop the queue manager START/QUEUE/MANAGER, STOP/QUEUE /MANAGER, $SNDJBC OPER and VOLPRO Initialize a blank tape or $INIT_VOL, MOUNT, $MOUNT override access checks while initializing a blank tape
A.21 PFNMAP Privilege (All) The PFNMAP privilege lets a user's process create and map page frame number (PFN) global sections to specific pages of physical memory or I/O device registers, no matter who is using the pages or registers. Such a privileged process can also delete PFN-based global sections with the system service $DGBLSC. Exercise caution when granting this privilege. If unqualified user processes have unrestricted access to physical memory, the operating system and service to other processes can be easily disrupted. Such disruptions can include failure of the system, destruction of all system and user data, and exposure of confidential information. · A.22 PHY _10 Privilege (All) The PHY_IO privilege lets the user's process execute the Queue I/O Request ($QIO) system service to perform physical-level I/O operations. Usually, process I/O requests are handled indirectly by use of an I/O package such as OpenVMS Record Management Services (RMS). However, to increase their control over I/O operations and to improve the efficiency of their applications, skilled users sometimes prefer to handle directly the interface between their process and a system I/O driver program. They can do this by executing the $QIO system service; in many instances, the operation called for is a physical-level I/O operation. Grant the PHY_IO privilege only to users who need it; grant this privilege even more carefully than the LOG_IO privilege. If this privilege is given to unqualified users who have no need for it, the operating system and service to other users can be easily disrupted. Such disruptions can include the destruction of information on the system device, the destruction of user data, and the exposure of confidential information.
A-12 Assigning Privileges A.22 PHY_10 Privilege (All)
The PHY_IO privilege also lets a process perform the following tasks:
Task Interface Access an individual shadow-set member unit $ASSIGN, $QIO Create or delete a watchpoint $QIO request to the SMP watchpoint driver (WPDRIVER) Map an LTA device to a server/port (I0$_TTY_ $QIO request to a LAT port driver (LTDRIVER) PORT!I0$M_LT_MAPPORT) Issue the following 1/0 requests: $QIO • Logical 1/0 request • Logical or virtual 1/0 request with IO$M_ MSCPMODIFS modifier • Physical 1/0 to private, non-file-structured device
Modify the following terminal attributes: SET TERMINAL or the terminal driver (TTDRIVER) HANGUP /[NO]HANGUP SET_SPEED /[NO]SET_SPEED SECURE_SERVER /[NO]SECURE_SERVER Issue IO$_ACCESS (diagnostic) function to $QIO request to a synchronous communications line DEBNA/NI device driver (XGDRIVER) Enable Ethernet promiscuous mode listening Issue I0$_ACCESS (diagnostic) function to Ethernet common driver
A.23 PRMCEB Privilege (Devour) The PRMCEB privilege lets the user's process create or delete a permanent common event flag cluster by ~xecuting the Associate Common Event Flag Cluster ($ASCEFC) or the Delete Common Event Flag Cluster ($DLCEFC) system service. Common event flag clusters enable cooperating processes to communicate with each other and thus synchronize their execution. Grant this privilege with care. If permanent common event flag clusters are not explicitly deleted, they tie up space in system dynamic memory, which may degrade system performance. A.24 PRMGBL Privilege (Devour) The PRMGBL privilege lets the user's process create or delete permanent global sections by executing the Create and Map Section ($CRMPSC) or the Delete Global Section ($DGBLSC) system service. In addition, a process with this privilege (plus CMKRNL and SYSGBL privileges) can use the Install utility (INSTALL). Global sections are shared structures that can be mapped simultaneously in the virtual address space of many processes. All processes see the same code or data. Global sections are used for reentrant subroutines or data buffers. Grant this privilege with care. If permanent global sections are not explicitly deleted, they tie up space in the global section and global page tables, which are limited resources.
A-13 Assigning Privileges A.25 PRMMBX Privilege (Devour)
A.25 PRMMBX Privilege (Devour) The PRMMBX privilege lets the user's process create or delete a permanent mailbox by executing the Create Mailbox and Assign Channel ($CREMBX) system service or the Delete Mailbox ($DELMBX) system service. The privilege also allows the creation of temporary mailboxes with the $CREMBX service. Mailboxes are buffers in virtual memory that are treated as if they were record oriented I/O devices. A mailbox is used for general interprocess communication. Do not grant PRMMBX to all users of the system. Permanent mailboxes are not automatically deleted when the creating processes are deleted and, thus, continue to use a portion of system dynamic memory. System performance degrades as system dynamic memory becomes scarce. A.26 PSWAPM Privilege (System) The PSWAPM privilege lets the user's process control whether it can be swapped out of the balance set by executing the Set Process Swap Mode ($SETSWM) system service. A process must have this privilege to lock itself in the balance set (to disable swapping) or to unlock itself from the balance set (to enable swapping). With this privilege, a process can create a process that is locked in the balance set (swap mode is disabled) by using an optional argument to the Create Process ($CREPRC) system service or, when the DCL command RUN is used to create a process, by using the /NOSWAPPING qualifier of the RUN command. Furthermore, a process can lock a page or range of pages in physical memory using the Lock Pages in Memory ($LCKPAG) system service. Grant this privilege only to users who need to lock a process in memory for performance reasons. Typically, this will be a real-time process. If unqualified processes have the unrestricted ability to lock processes in the balance set, physical memory can be held unnecessarily and thereby degrade system performance. A.27 READALL Privilege (Objects) The READALL privilege lets the process bypass existing restrictions that would otherwise prevent the process from reading an object. However, unlike the BYPASS privilege, which permits writing and deleting, READALL permits only the reading of objects and allows updating of such backup-related file characteristics as the backup date. See the Open VMS System Management Utilities Reference Manual for a discussion of backup operations. READALL is intended to be an adequate privilege for backing up volumes, so grant this privilege to operators so they can perform system backups. The READALL privilege lets a process perform the following tasks:
Task Interface Read a user authorization record $GETUAI Display permanent network database records NCP
A-14 Assigning Privileges A.28 SECURITY Privilege (System)
A.28 SECURITY Privilege (System) The SECURITY privilege lets a process perform security-related functions such as modifying the system password with the DCL command SET PASSWORD /SYSTEM or modifying the system alarm and audit settings using the DCL command SET AUDIT. The privilege not only lets a user process start and stop the audit server process with SET AUDIT, it also permits the process to use SET AUDIT to modify the characteristics of the auditing database, including those of the audit server, the system audit journal, the security archive file, resource monitoring, and the audit, alarm, or failure mode. Grant this privilege only to security administrators. Irresponsible users who obtain this privilege can subvert the system's security mechanisms, can lock out users through improper application of system passwords, and can disable security auditing. The SECURITY privilege also lets a process perform the following tasks:
Task Interface Display system auditing information about the SHOW AUDIT system audit log file, audit server settings, the contents of another user's audit log files, and so on Display Hidden ACEs SHOW SECURITY Display the system intrusion list or delete a SHOW INTRUSION, DELETE record /INTRUSION Enable the security operator terminal REPLY/ENABLE=SECURITY, $SNDOPR Enable protected subsystems on a volume MOUNT/SUBSYSTEM, $MOUNT, SET VOLUME/SUBSYSTEM
A.29 SETPRV Privilege (All) The SETPRV privilege lets the user's process create processes whose privileges are greater than its own by executing the Create Process ($CREPRC) system service with an optional argument or by issuing the DCL command RUN to create a process. A process with this privilege can also execute the DCL command SET PROCESS/PRIVILEGES to obtain any desired privilege. Exercise the same caution in granting SETPRV as in granting any other privilege because SETPRV lets a process enable any or all privileges. A.30 SHARE Privilege (All) The SHARE privilege lets processes assign channels to devices allocated to other processes or to a nonshared device using the Assign I/O Channel ($ASSIGN) system service. Grant this privilege only to system processes such as print symbionts. Otherwise, an irresponsible user can interfere with the operation of devices belonging to other users.
A-15 Assigning Privileges A.31 SHMEM Privilege (Devour)
A.31 SHMEM Privilege. (Devour) The SHMEM privilege lets the user's process create global sections and mailboxes (permanent and temporary) in memory shared by multiple processors if the process also has appropriate PRMGBL, PRMMBX, SYSGBL, and TMPMBX privileges. Just as in local memory, the space required for a temporary mailbox in multiport memory counts against the buffered I/O byte count limit (BYTLM) of the process. The privilege also lets a user's process create or delete an event flag cluster in shared memory using the Associate Common Event Flag Cluster ($ASCEFC) or the Disassociate Common Event Flag Cluster ($DACEFC) system service. A.32 SYSGBL Privilege {Files) The SYSGBL privilege lets the user's process create or delete system global sections by executing the Create and Map Section ($CRMPSC) or the Delete Global Section ($DGBLSC) system service. In addition, a process with this privilege (plus the CMKRNL and PRMGBL privileges) can use the Install utility (INSTALL). Exercise caution when granting this privilege. System global sections require space in the global section and global page tables, which are limited resources. A.33 SYSLCK Privilege (System) The SYSLCK privilege lets the user's process lock systemwide resources with the Enqueue Lock Request ($ENQ) system service or obtain information about a system resource with the Get Lock Information ($GETLKI) system service. Grant this privilege to users who need to run programs that lock resources in the systemwide resource namespace. However, exercise caution when granting this privilege. Users who hold the SYSLCK privilege can interfere with the sychronization of all system and user software. A.34 SYSNAM Privilege (All) The SYSNAM privilege lets the user's process bypass discretionary access controls and insert names into the system logical name table and delete names from that table by using the Create Logical Name ($CRELNM) and Delete Logical Name ($DELLNM) system services. A process with this privilege can use the DCL commands ASSIGN and DEFINE to add names to the system logical name table in user or executive mode and can use the DEASSIGN command in either mode to delete names from the table. To mount a system volume or to dismount a system or group volume with the appropriate mount or dismount command or system service, you must have the SYSNAM privilege. Grant this privilege only to the system operators or to system programmers who need to define system logical names (such as names for user devices, library directories, and the system directory). Note that a process with SYSNAM privilege could redefine such critical system logical names as SYS$SYSTEM and SYSUAF, thus gaining control of the system.
A-16 Assigning Privileges A.34 SYSNAM Privilege (All)
The SYSNAM privilege also lets a process perform the following tasks:
Task Interface Access a MAIL maintenance record MAIL Modify a MAIL forward record MAIL Declare a network object NETACP Create an IPC association $IPC With CMKRNL, add or remove an identifier to SET RIGHTS/SYSTEM, $GRANTID, system rights list $REVOKID
A.35 SYSPRV Privilege (All) The SYSPRV privilege lets a process access security objects by the system protection field and also read and modify the owner (UIC), the DIC-based protection code, and the ACL of an object. Even if an object is protected against system access, a process with SYSPRV privilege can change the object's protection to gain access to it. Any process with SYSPRV privilege can add, modify, or delete entries in the system user authorization file (SYSUAF.DAT). Exercise caution when granting this privilege. Normally, grant this privilege only to system managers and security administrators. If unqualified users have system access rights, the operating system and service to others can be easily disrupted. Such disruptions can include failure of the system, destruction of all system and user data, and exposure of confidential information. The SYSPRV privilege also lets a process perform the following tasks:
Task Interface Modify a file's expiration date SET FILE/EXPIRATION Modify the number of interlocked queue retries $QIO request to an Ethernet 802 driver (DEBNA/NI) Set the spin wait time on the port command $QIO request to an Ethernet 802 register driver (DEBNA) Set the FROM field in a mail message Callable MAIL Access a MAIL maintenance record MAIL Modify or delete a MAIL database record MAIL Modify the group number and password of a local CLUSTER_AUTHORIZE component area cluster ofSYSMAN Perform transaction recovery, join a transaction DECdtm as coordinator, transition a transaction
A-17 Assigning Privileges A.35 SYSPRV Privilege (All)
A process whose group UIC is less than or equal to the system parameter MAXSYSGRP has implied SYSPRV. When a process has SYSPRV or implied SYSPRV, it can also perform the following tasks:
Task Interface Initialize a magnetic tape $!NIT_VOL Override creation of an owner ACE on a newly $QIO request to FllBXQP created file Clear the directory bit in a directory's file header $QIO request to the FllBXQP, SET FILE/NODIRECTORY Operate on an extension header $QIO request to FllBXQP Acquire or release a volume lock $QIO request to FllBXQP Force mount verification on a volume $QIO request to FllBXQP Create a file access window with the no access $QIO request to FllBXQP lock bit set Specify null lock mode for a volume lock $QIO request to FllBXQP Access a locked file $QIO request to FllBXQP Disable disk quotas on volume $QIO request to FllBXQP Enable disk quotas on volume $QIO request to FllBXQP
A.36 TMPMBX Privilege (Normal) The TMPMBX privilege lets the user's process create a temporary mailbox by executing the Create Mailbox and Assign Channel ($CREMBX) system service. Mailboxes are buffers in virtual memory that are treated as if they were record oriented I/O devices. A mailbox is used for general interprocess communication. Unlike a permanent mailbox, which must be explicitly deleted, a temporary mailbox is deleted automatically when it is no longer referenced by any process. Grant this privilege to all users of the system to facilitate interprocess communication. System performance is not likely to be degraded by permitting the creation of temporary mailboxes, because their number is controlled by limits on the use of system dynamic memory (BYTLM quota). A.37 UPGRADE Privilege (All) The UPGRADE privilege lets a process manipulate mandatory access controls. The privilege allows a process to write to an object of higher integrity, in violation of the Biba confinement (*) property. This privilege is reserved for enhanced security products like SEVMS. A.38 VOLPRO Privilege (Objects) The VOLPRO privilege lets the user's process: • Initialize a previously used volume with an owner UIC different from the user's own UIC • Override the expiration date on a tape or disk volume owned by another user
A-18 Assigning Privileges A.38 VOLPRO Privilege (Objects)
• Use the /FOREIGN qualifier to mount a Files-11 volume owned by another user • Override the owner UIC protection of a volume The VOLPRO privilege permits control only over volumes that the user's process can mount or initialize. Volumes mounted with the /SYSTEM qualifier are safe from a process with the VOLPRO privilege as long as the process does not also have the SYSNAM privilege. Exercise extreme caution when granting the VOLPRO privilege. If unqualified users can override volume protection, the operating system and service to others can be disrupted. Such disruptions can include destruction of the database and exposure of confidential information. The VOLPRO privilege lets a process perform the following tasks:
Task Interface Dismount a volume DISMOUNT/ABORT, $DISMOU Initialize a volume $INIT_VOL Mount foreign multivolume magnetic tape set MOUNT/MULTI_VOLUME Override volume label(s) or accessibility $MOUNT Initialize blank tape REPLY/BLANK_TAPE,$SNDOPR Override access while initializing a magnetic tape $INIT_VOL after a file access error Override write-locking of volume on errors $MOUNT Override write protection of former shadow set $MOUNT member Override volume expiration, protection, or $MOUNT ownership
A.39 WORLD Privilege (System) The WORLD privilege lets the user's process affect other processes both inside and outside its group by executing the following process control system services: Suspend Process ($SUSPND) Resume Process ($RESUME) Delete Process ($DELPRC) Set Priority ($SETPRI) Wake ($WAKE) Schedule Wakeup ($SCHDWK) Cancel Wakeup ($CANWAK) Force Exit ($FORCEX) The user's process is also allowed to examine processes outside its own group by executing the Get Job/Process Information ($GETJPI) system service. A process with WORLD privilege can issue the SET PROCESS command for all other processes. Any process with WORLD privilege can also obtain information about a lock held by a process in another group using the Get Lock Information ($GETLKI) system service.
A-19 Assigning Privileges A.39 WORLD Privilege (System)
To exercise control over subprocesses that it created or to examine these subprocesses, a process needs no special privilege. To affect or examine other processes inside its own group, a process needs only the GROUP privilege. You should, however, grant this privilege to users who need to affect or examine processes outside their own group.
A-20 B Protection for OpenVMS System Files
The display of protection codes and ownership in this appendix corresponds to values that Digital supplies for the key system files following a normal installation. The display includes files in four directories: • The common system directory [SYSCOMMON] (Example B-1) • The directory of system executables [SYSEXE] (Example B-2) • The system library [SYSLIB] (Example B-3) • The system manager directory [SYSMGR] (Example B-4) Monitor these values regularly to ensure that no tampering has occurred. (The DCL commands DIRECTORY/SECURITY/OUTPUT and DIFFERENCES facilitate such checks.) You can obtain a full listing of system files during an OpenVMS installation. Enter the following DCL command from the system manager's account: $ DIRECTORY/SECURITY/OUTPUT=SYSTEM_FILES.LIS SYS$SYSROOT:[* •.• ]
Example B-1 SYSCOMMON Files: Protection Codes and Ownership Directory SYS$SYSROOT:[SYSCOMMON] CDA$LIBRARY.DIR;l [SYSTEM] (RWE,RWE,RE,RE) DECW$BOOK.DIR;l [SYSTEM] (RWE,RWE,RE,RE) DECW$DEFAULTS.DIR;l [SYSTEM] (RWE,RWE,RE,RE) DECW$INCLUDE.DIR;l [SYSTEM] (RWE,RWE,RE,RE) MOM$SYSTEM.DIR;l [376,375] (RWE,RWE,RE,RE) SYS$KEYMAP.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYS$LDR.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYS$STARTUP.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYSCBI.DIR; 1 [SYSTEM] (RWE,RWE,RE,RE) SYSERR.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYSEXE.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYSFONT.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYSHLP.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYSLIB.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYSMAINT. DIR; 1 [SYSTEM] (RWE,RWE,RE,RE) SYSMGR.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYSMSG.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYSTEST.DIR;l [SYSTEM] (RWE,RWE,RE,RE) SYSUPD.DIR;l [SYSTEM] (RWE,RWE,RE,RE) VUE$LIBRARY.DIR;l [SYSTEM] (RWE,RWE,RE,RE) XDPS$INCLUDE.DIR;l [SYSTEM] (RWE,RWE,RE,RE) Total of 21 files.
8-1 Protection for OpenVMS System Files
Example B-2 SYSEXE Files: Protection Codes and Ownership Directory SYS$SYSROOT:[SYSCOMMON.SYSEXE] ACC.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ACLEDT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) AGEN$FEEDBACK.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ANALAUDIT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ANALIMDMP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ANALYZBAD.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ANALYZOBJ.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ANALYZRMS.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) AUDIT SERVER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) AUTHORIZE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) BACKUP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) BADBLOCK.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) BOOT58.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) BOOTBLOCK.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CDA$CONVERT.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) CDU.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CHECKSUM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CIA.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CLUE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CONFIGURE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CONVERT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) COPY.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CREATE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CREATEFDL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CSP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CVTNAFVS.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DBLMSGMGR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DCL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DCLDEF.STB;l [SYSTEM] (RWED,RWED,RWED,RE) DDIF$VIEW.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECDTMDEF.STB;l [SYSTEM] (RWED,RWED,RWED,RE) DECSOUND.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$BOOKREADER.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$CALC.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$CALENDAR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$CARDFILER.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
B-2 Protection for OpenVMS System Files
Example 8-2 (Cont.) SYSEXE Files: Protection Codes and Ownership
DECW$CBI.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$CLOCK.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWT DECNET.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWT FONT DAEMON.EXE;l - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWT STARTXTDRIVER.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) DECW$ENDSESSION.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$FONTCOMPILER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$LWK MANAGER.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) DECW$LWK_SETUP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$MAIL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$MESSAGEPANEL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$MKFONTDIR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$MWM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$NOTEPAD.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$PAINT.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$PAUSESESSION.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$PRINTSCREEN.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$PUZZLE.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$SERVER MAIN.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SESSION.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$SETSHODIS.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$STARTLOGIN.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$TERMINAL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$TERMINAL CREATE.EXE;2 - [SYSTEM] (RWED,RWED,RWED,RE) DECW$UILCOMPILER.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$UILMOTIF.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$WAITFORSM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$WINMGR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$WML.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$WSCUST.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$WSINIT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
B-3 Protection for OpenVMS System Files
Example 8-2 (Cont.) SYSEXE Files: Protection Codes and Ownership
DELETE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DIFF.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DIRECTORY.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DISKQUOTA.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DISMOUNT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DNS$ADVER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DNS$ANALYZE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DNS$SOLICIT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DSRINDEX.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DSRTOC.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DTEPAD.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DTR.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DTRECV.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DTSEND.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DUMP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) EDF.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) EDT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERF.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFADPTR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFBRIEF.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFBUS.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFCNTRL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFCVAX.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFDISK.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFDISK2.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFMISC.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFMSCP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFNVAX.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFRLTIM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFSCSI.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFSUMM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFTAPE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFUVAX.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFV14.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFV9000.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFVAX7XX.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFVX8200.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFVX8600.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFVX87XX.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFXRP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERRFMT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERRSNAP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ESS$LADCP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ESS$LASTCP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) EVL.COM;l [SYSTEM] (RWED,RWED,RWED,RE) EVL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) EXCHANGE$NETWORK.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) EXCHANGE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) FllAACP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-4 Protection for OpenVMS System Files
Example 8-2 (Cont.) SYSEXE Files: Protection Codes and Ownership
FllBXQP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) FllCACP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) FllDACP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) FAL.COM;l [SYSTEM] (RWED,RWED,RWED,RE) FAL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) FILESERV.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) HLD.COM;l [SYSTEM] (RWED,RWED,RWED,RE) HLD.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) HSCPAD.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) IMGDEF.STB;l [SYSTEM] (RWED,RWED,RWED,RE) !NIT.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) INPSMB.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) INSTALL.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) IPCACP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) IPCDEF.STB;l [SYSTEM] (RWED,RWED,RWED,RE) ISL LVAX 060.SYS;l [SYSTEM] (RWED,RWED,RE,RE) ISL-SVAX-060.SYS;l [SYSTEM] (RWED,RWED,RE,RE) JBC$COMMAND.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) JBC$JOB CONTROL.EXE;! - [SYSTEM] (RWED,RWED,RWED,RE) LALOAD.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LALOADER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LATACP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LATCP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LATSYM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LIBRARIAN.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) LINK.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) LMCP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LMF$LICENSE.LDB;l [SYSTEM] (RWED,RWED,RWED,RE) LMF$LURT.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) LMF.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LOGINOUT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LTPAD.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) MACR032.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) MAIL.COM;! [SYSTEM] (RWED,RWED,RWED,RE) MAIL.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) MAILEDIT.COM;l [SYSTEM] (RWED,RWED,RWED,RE) MAIL SERVER.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) MESSAGE.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) MIRROR.COM;! [SYSTEM] (RWED,RWED,RWED,RE) MIRROR.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) MOM.COM;! [SYSTEM] (RWED,RWED,RWED,RE) MOM.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) MONITOR.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) MSCP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) MSGHLP$MAIN.EXE;l [SYSTEM] (RE,RE,RE,RE) MTAAACP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) NCP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) NCS.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) NET$NAME SERVER.EXE;! - [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
B-5 Protection for OpenVMS System Files
Example B-2 (Cont.) SYSEXE Files: Protection Codes and Ownership
NETACP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) NETDEF.STB;l [SYSTEM] (RWED,RWED,RWED,RE) NETSERVER.COM; 1 [SYSTEM] (RWED,RWED,RWED,RE) NETSERVER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) NICONFIG.COM;l [SYSTEM] (RWED,RWED,RWED,RE) NICONFIG.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) NML.COM;l [SYSTEM] (RWED,RWED,RWED,RE) NML.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) OPCCRASH.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) OPCOM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) PATCH.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) PHONE.COM;l [SYSTEM] (RWED,RWED,RWED,RE) PHONE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) PRTSMB.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) QMAN$QUEUE MANAGER.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) QUEMAN.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) QUEMAN OLD.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) RECLAIM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) RECOVER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) REMACP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) RENAME.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) REPLY.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) REQSYSDEF.STB;l [SYSTEM] (RWED,RWED,RWED,RE) REQUEST.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) RIGHTSLIST.DAT;l [SYSTEM] (RWED,RWED,R,) RMSDEF.STB;l [SYSTEM] (RWED,RWED,RWED,RE) RMSREC$SERVER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) RTB.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) RTPAD.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) RUNDET.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) RUNOFF.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SCSDEF.STB;l [SYSTEM] (RWED,RWED,RWED,RE) SDA.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SDLNPARSE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SEARCH.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SET.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SETAUDIT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SETFILENOMOVE.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SETFILENOMOVE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SETPO.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SETRIGHTS.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SETSHOSECUR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SETWATCH.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SHADOW_SERVER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SHOW.EXE;l [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-6 Protection for Open VMS System Files
Example B-2 (Cont.) SYSEXE Files: Protection Codes and Ownership
SHUTDOWN.COM;3 [SYSTEM] (RWED,RWED,RWED,RE) SHUTDOWN.COM;2 [SYSTEM] (RWED,RWED,RWED,RE) SHWCLSTR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SMGBLDTRM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SMGMAPTRM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SMGTERMS.TXT;l [SYSTEM] (RWED,RWED,RWED,RE) SMISERVER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SMPUTIL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT$DRIVER.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT$IMAGE.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT$LOADED IMAGES.DAT;l - [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT$WATCHDOG.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SORTMERGE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SRTTRN.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) STABACCOP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) STABACKUP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) STACONFIG.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) STANDCONF.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) STARTUP.COM;3 [SYSTEM] (RWED,RWED,RWED,RE) STARTUP.COM;2 [SYSTEM] (RWED,RWED,RWED,RE) STASYSGEN.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) STOPREM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SUBMIT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SUCCESS.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SUMSLP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SYS.MAP;l [SYSTEM] (RWED,RWED,RWED,RE) SYS.STB;l [SYSTEM] (RWED,RWED,RWED,RE) SYSBOOT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SYSBOOT_XDELTA.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SYSDEF.STB;l [SYSTEM] (RWED,RWED,RWED,RE) SYSGEN.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SYSINIT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SYSMAN.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SYSUAF.DAT;l [SYSTEM] (RWE,RWE,RWE,) SYSUAF.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) TEC032.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TERMTABLE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TERMTABLE.TXT;l [SYSTEM] (RWED,RWED,RWED,RE) TERTIARY VMB.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TFF$MASTER.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) TFU.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TMSCP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TPSERV.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TPU.EXE;l [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-7 Protection for OpenVMS System Files
Example B-2 (Cont.) SYSEXE Files: Protection Codes and Ownership
TYPE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) UNLOCK.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) UTC$CONFIGURE TDF.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) VAXVMSSYS.PAR;3 [SYSTEM] (RWED,RWED,RWED,RE) VERIFY.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) VMB.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) VMB9AQ.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) VMBUVAXlP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) VMOUNT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) VMS$CREATE SYSDIRS.COM;l - [SYSTEM] (RWED,RWED,RWED,RE) VMS$FILE ATTRIBUTES.DAT;l - [SYSTEM] (RWED,RWED,RWED,RE) VMS$IMAGE VERSION.DAT;l - [SYSTEM] (RWED,RWED,RWED,RE) VMS$INSTALL UPG DATA.COM;l - - [SYSTEM] (RWED,RWED,RWED,RE) VMS$0BJECTS.DAT;l [SYSTEM] (RWE,RWE,RE,) VMSHELP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) VMSMAIL PROFILE.DATA;l - [SYSTEM] (RWE,RWE,,) VMSPARAMS.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) VPM.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) VUE$MASTER.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) WP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) WRITEBOOT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) XDPS$PSWRAP.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) XFLOADER.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) Total of 278 files.
Example B-3 SYSLIB Files: Protection Codes and Ownership Directory SYS$SYSROOT:[SYSCOMMON.SYSLIB] ACLEDIT.TPU;l [SYSTEM] (RWED,RWED,RWED,RE) ACLEDT$SECTION.TPU$SECTION;l [SYSTEM] (RWED,RWED,RWED,RE) ACLEDTSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ADARTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) ADARTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) BASRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) BASRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) BASRTL2.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) BASRTL2.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) BLAS1RTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) BLASlRTL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CDA$ACCESS.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$CDA .ADA;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$DEF-:-BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$DEF.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$DEF.H;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$DEF.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$DEF.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$DEF.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-8 Protection for OpenVMS System Files
Example B-3 (Cont.) SVSLIB Files: Protection Codes and Ownership
CDA$DEF.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$DTIF TO DDIF.EXE;2 - - [SYSTEM] (RWED,RWED,RWED,RE) CDA$MSG.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$MSG.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$MSG.H;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$MSG.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$MSG.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$MSG.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$MSG.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) CDA$PTP.H;l [SYSTEM] (RWED,RWED,RWED,RE) CDA$TYP.H;l [SYSTEM] (RWED,RWED,RWED,RE) CDA$WRITE ANALYSIS.EXE;2 - [SYSTEM] (RWED,RWED,RWED,RE) CDDSHR.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) CDDSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) CLIMAC.REQ;l [SYSTEM] (RWED,RWED,RWED,RE) CMA$LIB SHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CMA$0PEN LIB SHR.EXE;l - - [SYSTEM] (RWED,RWED,RWED,RE) CMA$0PEN RTL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CMA$RTL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CMA$TIS SHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CMA.H;l- [SYSTEM] (RWED,RWED,RWED,RE) CMALIB CRTLX.H;l [SYSTEM] (RWED,RWED,RWED,RE) CMA CONFIG.H;l [SYSTEM] (RWED,RWED,RWED,RE) CMA-ERRNO.H;l [SYSTEM] (RWED,RWED,RWED,RE) CMA-HOST.H;l [SYSTEM] (RWED,RWED,RWED,RE) CMA-LIBRARY.H;l [SYSTEM] (RWED,RWED,RWED,RE) CMA-PX.H;l [SYSTEM] (RWED,RWED,RWED,RE) CMA-SIGWAIT.H;l [SYSTEM] (RWED,RWED,RWED,RE) COBRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) COBRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) CONVSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) CRFSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DBGSSISHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DBG_ACAS_DEFS.COL;l [SYSTEM] (RWED,RWED,RWED,RE) DBG_ACAS_DEFS.CRL;l [SYSTEM] (RWED,RWED,RWED,RE) DBG STARTUP.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DBLRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DBLRTL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DCLTABLES.EXE;4 [SYSTEM] (RWED,RWED,RWED,RE) DCLTABLES.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) DCXSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DDIF$DDIF .ADA;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$DEF.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$DEF.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$DEF.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$DEF.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$DEF.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$DEF.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$DEF.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$READ_TEXT.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-9 Protection for OpenVMS System Files
Example 8-3 (Cont.) SYSLIB Files: Protection Codes and Ownership
DDIF$VIEWSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$WRITE_PS.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DDIF$WRITE_TEXT.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DEBUG.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DEBUGSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DEBUGUISHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECC$SHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$AILSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$BKRSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$CALENDAR_PROLOG.PS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$CURSOR.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$D2DXLIBSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$DRIVER.MLB;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTDEF.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTDEF.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTDEF.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTDEF.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTDEF.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTDEF.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTDEF.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTDEF.UIL;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTENTRY.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTENTRY.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTENTRY.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTENTRY.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTENTRY.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTENTRY.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTENTRY.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTLIBSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTMSG.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTMSG.FOR;2 [SYSTEli] (RWED,RWED,RWED,RE) DECW$DWTMSG.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTMSG.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTMSG.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTMSG.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTMSG.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTSTRUCT.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTSTRUCT.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTSTRUCT.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTSTRUCT.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTSTRUCT.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTSTRUCT.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
B-10 Protection for OpenVMS System Files
Example 8-3 (Cont.) SYSLIB Files: Protection Codes and Ownership DECW$DWTSTRUCT.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETDEF.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETDEF.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETDEF.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETDEF.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETDEF.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETDEF.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETDEF.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETSTRUCT.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETSTRUCT.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETSTRUCT.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETSTRUCT.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETSTRUCT.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETSTRUCT.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWTWIDGETSTRUCT.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DWT .ADA;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$DXMLIBSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$FONTCOMPILER.CLD;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$LOGINOUT.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$MAILSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$MOTIF.FOR;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$MOTIF.PAS;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$MOTIF .ADA;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$PEN_BUILD.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$PRINTWGTSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$SECURITY.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$SECURITY C2.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-11 Protection for OpenVMS System Files
Example 8-3 {Cont.) SYSLIB Files: -Protection Codes and Ownership
DECW$SERVER DDX GA.EXE;! - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SERVER DDX GB.EXE;! - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SERVER DDX GC.EXE;l - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SERVER DDX GE.EXE;! - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SERVER DDX GF.EXE;l - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SERVER DIX.EXE;! - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SERVER EXTENSION XTRAP V54.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SERVER XINPUT IE.EXE;! - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SESSIONSHRP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT ADOBE DPS EXTENSION.EXE;! - - -[SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT D2DX EXTENSIONS.EXE;! - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT DEC XTRAP.EXE;l - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT MULTI BUFFERING.EXE;! - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT X3D PEX.EXE;l - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT X3D PEX GB.EXE;! - - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT X3D PEX GB UCODE.EXE;l - - - (SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT X3D PEX GE.EXE;! - - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT_XIE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$SVEXT XINPUTEXTENSION.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) DECW$TERMINALSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$TRANSPORT COMMON.EXE;! - [SYSTEM] (RWED,RWED,RWED,RE) DECW$TRANSPORT DECNET.EXE;! - [SYSTEM] (RWED,RWED,RWED,RE) DECW$TRANSPORT LAT.EXE;! - [SYSTEM] (RWED,RWED,RWED,RE) DECW$TRANSPORT LOCAL.EXE;! - [SYSTEM] (RWED,RWED,RWED,RE) DECW$TRANSPORT TCPIP.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) DECW$UIL.ENV;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$WML TOKENS.DAT;! - [SYSTEM] (RWED,RWED,RWED,RE) DECW$XEXTLIBSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-12 Protection for OpenVMS System Files
Example 8-3 (Cont.) SYSLIB Files: Protection Codes and Ownership
DECW$XKEYSYMDB.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBDEF.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBDEF.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBDEF.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBDEF.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBDEF.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBDEF.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBDEF.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBMSG.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBMSG.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBMSG.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBMSG.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBMSG.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBMSG.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBMSG.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XLIBSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XMLIBSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$XMULIBSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$XPORTCOM.H;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$XPORTCOM.MAR;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$XPORTCOM.R32;1 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XPORTDEF.H;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$XPORTDEF.MAR;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$XPORTDEF.R32;1 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XPORTMAC.R32;1 [SYSTEM] (RWED,RWED,RWED,RE) DECW$XPORTMSG.R32;1 [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-13 Protection for OpenVMS System Files
Example B-3 (Cont.) SYSLIB Files: Protection Codes and Ownership DECW$XTRAPLIBSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$XTSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$X .ADA;2 [SYSTEM] (RWED,RWED,RWED,RE) DELTA.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) . DELTA.OBJ;l [SYSTEM] (RWED,RWED,RWED,RE) DGIT$LIBSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DISMNTSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DIVA$LIB SHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DIVA$WGT-SHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DNS$CLIENT.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DNS$RTL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DNS$SHARE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DNSDEF.BAS;l [SYSTEM] (RWED,RWED,RWED,RE) DNSDEF.FOR;l [SYSTEM] (RWED,RWED,RWED,RE) DNSDEF.H;l [SYSTEM] (RWED,RWED,RWED,RE) DNSDEF.MAR;l [SYSTEM] (RWED,RWED,RWED,RE) DNSDEF.PAS;l [SYSTEM] (RWED,RWED,RWED,RE) DNSDEF.PLI;l [SYSTEM] (RWED,RWED,RWED,RE) DNSDEF.R32;1 [SYSTEM] (RWED,RWED,RWED,RE) DNSMSG.BAS;l [SYSTEM] (RWED,RWED,RWED,RE) DNSMSG.FOR;l [SYSTEM] (RWED,RWED,RWED,RE) DNSMSG.H;l [SYSTEM] (RWED,RWED,RWED,RE) DNSMSG.MAR;l [SYSTEM] (RWED,RWED,RWED,RE) DNSMSG.PAS;l [SYSTEM] (RWED,RWED,RWED,RE) DNSMSG.PLI;l [SYSTEM] (RWED,RWED,RWED,RE) DNSMSG.R32;1 [SYSTEM] (RWED,RWED,RWED,RE) DTE_DF03.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DTE DF112. EXE; 1 [SYSTEM] (RWED,RWED,RWED,RE) DTE-DMCL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DTI$SHARE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DTIF$DEF.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DTIF$DEF.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) DTIF$DEF.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DTIF$DEF.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) DTIF$DEF.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) DTIF$DEF.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) DTIF$DEF.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) DTIF$DTIF .ADA;2 [SYSTEM] (RWED,RWED,RWED,RE) DTKSHR. EXE; 1 [SYSTEM] (RWED,RWED,RWED,RE) DTMIMG$SHRLIB.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) DVR$CC DEF.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DVR$CC-PTP.H;l [SYSTEM] (RWED,RWED,RWED,RE) DVR$DECW DEF.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DVR$DECW-PTP.H;l [SYSTEM] (RWED,RWED,RWED,RE) DVR$MSG.H;2 [SYSTEM] (RWED,RWED,RWED,RE) DYNSWITCH.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) EDTSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ENCRYPSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) ENCRYPSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) EPC$FACILITY.TLB;3 [SYSTEM] (RWED,RWED,RWED,RE) EPC$FACILITY.TLB;2 [SYSTEM] (RWED,RWED,RWED,RE) EPC$SHR.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) EPC$SHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
B-14 Protection for OpenVMS System Files
Example B-3 (Cont.) SYSLIB Files: Protection Codes and Ownership
EPM$SRVSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFCOMMON.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFCTLSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFLIB.TLB;l [SYSTEM] (RWED,RWED,RWED,RE) ERFSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ERFSHR2.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) EVE$SECTION.TPU$SECTION;l [SYSTEM] (RWED,RWED,RWED,RE) EVE$WIDGETS MOTIF.UID;l - [SYSTEM] (RWED,RWED,RWED,RE) EVE.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) EXC HANDLING.H;l [SYSTEM] (RWED,RWED,RWED,RE) EXC=HANDLING_VMS.H;l [SYSTEM] (RWED,RWED,RWED,RE) FDLSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) FORDEF.FOR;l [SYSTEM] (RWED,RWED,RWED,RE) FORIOSDEF.FOR;l [SYSTEM] (RWED,RWED,RWED,RE) FORRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) FORRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) FORRTL2.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) FORRTL2.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) IMAGELIB.OLB;l [SYSTEM] (RWED,RWED,RWED,RE) IMG$SHRLIB.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) IMGDMP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) INIT$SHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) IPC$SHARE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LAT$SHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) LBRSHR.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) LBRSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) LIB.MLB;l [SYSTEM] (RWED,RWED,RWED,RE) LIB.REQ;l [SYSTEM] (RWED,RWED,RWED,RE) LIBDEF.FOR;l [SYSTEM] (RWED,RWED,RWED,RE) LIBRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) LIBRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) LIBRTL2 .EXE; 3 [SYSTEM] (RWED,RWED,RWED,RE) LIBRTL2.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) LWK$DXMSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) MAILSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) MAILSHRP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) MOUNTSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) MSGHLP$ENGLISH.EXE;l [SYSTEM] (RE,RE,RE,RE) MSGHLP$SHARE.EXE;l [SYSTEM] (RE,RE,RE,RE) MTHDEF.FOR;l [SYSTEM] (RWED,RWED,RWED,RE) MTHRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) MTHRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) NCS$LIBRARY.NLB;l [SYSTEM] (RWED,RWED,RWED,RE) NCSSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) NISCS LAA.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) NISCS-LOAD.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) NMLSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) PASRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) PASRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) PHIGS$CRTL.EXE;l [SYSTEM] (RWED,RWED,RE,) PLIRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) PLIRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) PPLRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) PPLRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) PTD$SERVICES SHR.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-15 Protection for OpenVMS System Files
Example B-3 (Cont.) SYSLIB Files: Protection Codes and Ownership PTHREAD.H;l [SYSTEM] (RWED,RWED,RWED,RE) PTHREAD EXC.H;l [SYSTEM] (RWED,RWED,RWED,RE) RPGRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) RPGRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) SCNRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) SCNRTL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SCRSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SDATP$SHARE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SDA EXTEND VECTOR.EXE;l - - [SYSTEM] (RWED,RWED,RWED,RE) SECURESHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SECURESHRP.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SIGDEF.FOR;l [SYSTEM] (RWED,RWED,RWED,RE) SMBSRVSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SMGSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SMI$0BJSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SMI$SHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT$SHARE.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SORTSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) SPISHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) STARLET.MLB;l [SYSTEM] (RWED,RWED,RWED,RE) STARLET.OLB;2 [SYSTEM] (RWED,RWED,RWED,RE) STARLET.REQ;l [SYSTEM] (RWED,RWED,RWED,RE) STARLETSD.TLB;l [SYSTEM] (RWED,RWED,RWED,RE) SUMSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TC$LIBRARY.OLB;l [SYSTEM] (RWED,RWED,RWED,RE) TECOSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TFFSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TPAMAC.REQ;l [SYSTEM] (RWED,RWED,RWED,RE) TPU$CCTSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TPU$DEBUG.TPU;l [SYSTEM] (RWED,RWED,RWED,RE) TPU$MOTIFSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TPU.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) TPUSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) TRACE.EXE;! [SYSTEM] (RWED,RWED,RWED,RE) UISSHR.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) UISSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) UVMTHRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) UVMTHRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) VAXCCURSE.OLB;l [SYSTEM] (RWED,RWED,RWED,RE) VAXCRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) VAXCRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) VAXCRTL.OLB;l [SYSTEM] (RWED,RWED,RWED,RE) VAXCRTLG.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) VAXCRTLG.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) VAXCRTLG.OLB;l [SYSTEM] (RWED,RWED,RWED,RE) VBLAS1RTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) VBLASlRTL.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) VECTOR EMULATOR.EXE;l - [SYSTEM] (RWED,RWED,RWED,RE) VME$LIBRARY.OLB;l [SYSTEM] (RWED,RWED,RWED,RE) VMESUPPORT.MLB;l [SYSTEM] (RWED,RWED,RWED,RE) VMS$FORMAT AUDIT SYSTEM.EXE;l - - [SYSTEM] (RWED,RWED,RWED,RE) VMS$PASSWORD DICTIONARY.DATA;! - [SYSTEM] (RE,RE,,) VMSDEBUGUIL.UID;l [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
B-16 Protection for OpenVMS System Files
Example B-3 {Cont.) SYSLIB Files: Protection Codes and Ownership
VMSRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) VMSRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) VMTHRTL.EXE;3 [SYSTEM] (RWED,RWED,RWED,RE) VMTHRTL.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) VUE$MASTERSHR.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSBINDINGSSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSCLIENTSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSLIBSHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSOPS.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSOPS.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSOPS.H;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSOPS.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSOPS.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSXCLIENT.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSXCLIENT.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSXCLIENT.H;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSXCLIENT.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$DPSXCLIENT.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$MASTERDPSVM.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) XDPS$PSOPS.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$PSOPS.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$PSOPS.H;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$PSOPS.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$PSOPS.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPS.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPS.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPS.H;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPS.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPS.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPSLIB.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPSLIB.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPSLIB.H;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPSLIB.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) XDPS$XDPSLIB.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) XFDEF.FOR;l [SYSTEM] (RWED,RWED,RWED,RE) XIE$SHRLIB.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) XNL$DEF.ADA;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$DEF.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$DEF.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$DEF.H;2 [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
B-17 Protection for OpenVMS System Files
Example B-3 (Cont.) SYSLIB Files: Protection Codes and Ownership
XNL$DEF.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$DEF.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$DEF.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$DEF.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$MSG.ADA;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$MSG.BAS;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$MSG.FOR;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$MSG.H;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$MSG.MAR;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$MSG.PAS;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$MSG.PLI;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$MSG.R32;2 [SYSTEM] (RWED,RWED,RWED,RE) XNL$SHR.EXE;2 [SYSTEM] (RWED,RWED,RWED,RE) Total of 407 files.
Example 8-4 SYSMGR Files: Protection Codes and Ownership Directory SYS$SYSROOT:[SYSCOMMON.SYSMGR] AGEN$NEW NODE DEFAULTS.DAT;l - - [SYSTEM] (RWED,RWED,RWED,RE) AGEN$NEW NODE DEFAULTS.TEMPLATE;! - - [SYSTEM] (RWED,RWED,RWED,RE) AGEN$NEW SATELLITE DEFAULTS.DAT;l - - [SYSTEM] (RWED,RWED,RWED,RE) AGEN$NEW SATELLITE DEFAULTS.TEMPLATE;l - - [SYSTEM] (RWED,RWED,RWED,RE) AGENPARAMS.EXE;l [SYSTEM] (RWED,RWED,RWED,RE) ALFMAINT.COM;l [SYSTEM] (RWED,RWED,RWED,RE) VMS$AUDIT SERVER.DAT;2 - [SYSTEM] (RWED,RWED,RE,) CLUSTER_CONFIG.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DBLSTRTUP.COM;2 [SYSTEM] (RWED,RWED,RWED,RE) DBLSTRTUP.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$AUTOGEN.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$CHECK PARAMS.COM;2 - [SYSTEM] (RWED,RWED,RWED,RE) DECW$DEVICE.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$DEVICE_GE.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$DEVICE_GF.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$DEVICE_GG.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$LOGICALS.COM;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$MWM.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$PRIVATE APPS SETUP.TEMPLATE;l - - [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-18 Protection for OpenVMS System Files
Example 8-4 (Cont.) SYSMGR Files: Protection Codes and Ownership
DECW$PRIVATE SERVER SETUP.TEMPLATE;l - - [SYSTEM] (RWED,RWED,RWED,RE) DECW$RGB.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$RGB.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$STARTAPPS.COM;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$STARTI18N.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$STARTLIBS.COM;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$STARTSERVER.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$STARTSM.COM;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$STARTUP.COM;2 [SYSTEM] (RWED,RWED,RWED,RE) DECW$STARTXTERMINAL.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$SYLOGIN.COM;l [SYSTEM] (RWED,RWED,RWED,RE) DECW$SYLOGIN.TEMPLATE;2 [SYSTEM] (RWED,RWED,RWED,RE) DNS$CHANGE DEF FILE.COM;l - - [SYSTEM] (RWED,RWED,RWED,RE) DNS$CLIENT STARTUP.COM;l - [SYSTEM] (RWED,RWED,RWED,RE) DNS$CLIENT STOP.COM;l - [SYSTEM] (RWED,RWED,RWED,RE) EDTINI.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) LAT$SYSTARTUP.COM;l [SYSTEM] (RWED,RWED,RWED,RE) LAT$SYSTARTUP.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) LIB$DT_STARTUP.COM;l [SYSTEM] (RWED,RWED,RWED,RE) LOADNET.COM;l [SYSTEM] (RWED,RWED,RWED,RE) LOGIN.COM;l [SYSTEM] (RWED,RWED,RWED,RE) LOGIN.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) LPAllSTRT.COM;l [SYSTEM] (RWED,RWED,RWED,RE) LTLOAD.COM;l [SYSTEM] (RWED,RWED,RWED,RE) MAKEROOT.COM;l [SYSTEM] (RWED,RWED,RWED,RE) NETCONFIG.COM;l [SYSTEM] (RWED,RWED,RWED,RE) RTTLOAD.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SECURITY.AUDIT$JOURNAL;l [SYSTEM] (RWED,RWED,RE,) SECURITY AUDIT.AUDIT$JOURNAL;2 - [SYSTEM] (RWED,RWED,RE,) SMISERVER.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT$CLEANUP.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT$NEW DISK.COM;l - [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT$SYCLEANUP.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT$SYSHUTDOWN.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) SNAPSHOT.COM;l [SYSTEM] (RWED,RWED,RWED,RE) STARTNET.COM;l [SYSTEM] (RWED,RWED,RWED,RE)
(continued on next page)
8-19 Protection for OpenVMS System Files
Example B-4 (Cont.) SYSMGR Files: Protection Codes and Ownership
SYCONFIG.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SYCONFIG.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) SYLOGICALS.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SYLOGICALS.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) SYLOGIN.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SYLOGIN.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) SYPAGSWPFILES.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SYPAGSWPFILES.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) SYSECURITY.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SYSECURITY.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) SYSHUTDWN.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SYSHUTDWN.TEMPLATE;l [SYSTEM] (RWED,RWED,RWED,RE) SYSTARTUP_VMS.COM;2 [SYSTEM] (RWED,RWED,RWED,RE) SYSTARTUP_VMS.COM;l [SYSTEM] (RWED,RWED,RWED,RE) SYSTARTUP VMS.TEMPLATE;l - [SYSTEM] (RWED,RWED,RWED,RE) TFF$STARTUP.COM;l [SYSTEM] (RWED,RWED,RWED,RE) UTC$CONFIGURE TDF.COM;l - [SYSTEM] (RWED,RWED,RWED,RE) VMS$IMAGES MASTER.DAT;l - [SYSTEM] (RWED,RWED,RWED,RE) VMSIMAGES.DAT;l [SYSTEM] (RWED,RWED,RWED,RE) WELCOME.TEMPLATE;2 [SYSTEM] (RWED,RWED,RE,RE) WELCOME.TEMPLATE;l [SYSTEM] (RWED,RWED,RE,RE) WELCOME.TXT;2 [SYSTEM] (RWED,RWED,RE,RE) WELCOME.TXT;l [SYSTEM] (RWED,RWED,RE,RE) Total of 79 files.
8-20 c Running an OpenVMS VAX System in a C2 Environment
This appendix describes how to operate an OpenVMS operating system in a C2 environment. C2 is a United States government rating of the security of an operating system; it identifies OpenVMS as an operating system that meets the criteria of a Division C, class 2 system, as described in Section C.1.1. Terminology used in this appendix is drawn from the United States government's evaluation criteria. C.1 Introduction to C2 Systems This section describes the requirements for a C2 system and explains the documentation that the OpenVMS product provides to support such a system. C.1.1 Definition of the C2 Environment A C2 environment is one that meets the United States Defense Department's criteria for tru'sted computer systems and that contains only those hardware and software components that were included in the government's evaluation of the OpenVMS operating system. The criteria for C2 systems are defined in the Department of Defense Trusted Computer System Evaluation Criteria, published by the Department of Defense Computer Security Center (DOD 5200.28-STD). They include the following: • Access controls, which if used, can identify individual users as well as groups of users. • User accountability through login procedures that clearly identify a user • Auditing of security-relevant events • Resource isolation so objects are erased before being reallocated C.1.2 Documentation The trusted facility manual is intended for the system administrator. Chapters 5-8 and Appendixes A-D of this manual and the portion of the Open VMS System Management Utilities Reference Manual describing the Audit Analysis utility make up the C2 trusted facility manual. Both this manual and the Open VMS System Management Utilities Reference Manual draw from reference material listed in the Associated Documents section of this manual's preface. Part I and Part II of this guide constitute the security features user's guide and should be made available to all users.
C-1 Running an OpenVMS VAX System in a C2 Environment C.2 Trusted Computing Base (TCB) for C2 Systems
C.2 Trusted Computing Base (TCB) for C2 Systems The federal government's evaluation of a computer system measures the trusted computing base (TCB) against the criteria summarized in Section C.1.1. The TCB is a combination of computer hardware and an operating system that enforces a security policy. C.2.1 Hardware in the TCB The architectural design of VAX processors prevents competing programs from interfering with the data of another program. VAX hardware prevents one program from interfering with the memory of another program. The security features described in this guide apply to any VAX processor in the evaluated hardware configurations and to all supported mass storage and communications devices. The Final Evaluation Report, Digital Equipment Corporation, Open VMS VAX and SEVMS Version 6.0 provides a full listing of the evaluated hardware. C.2.2 Software in the TCB In OpenVMS operating systems, the TCB encompasses much of the operating system. It includes the entire m~ecutive and file system, all other system components that do not execute in user mode (such as device drivers, RMS, and DCL), most system programs installed with privilege, and a variety of other utilities used by system managers to maintain data relevant to the TCB. I As a convenience to customers, the OpenVMS operating system ships with more than the base operating system. The software package includes supportive images for layered products typically run on OpenVMS operating systems. Yet only the base operating system was evaluated as a C2 system. Layered products, such as DECwindows software and Display PostScript support, were not part of the evaluation. For this reason, the C2 rating does not extend to OpenVMS VAX systems running the software listed in Table C-1. The exclusion of these software components in no way implies they are insecure; it means only they were not part of the evaluated system. After the introduction of any such software, the base system must be accredited for its particular usage.
Table C-1 Software Not Included in the C2-Evaluated System Software Function Description DECwindows software Windowing DECwindows is a layered product. interface Although DECwindows has been designed to meet the C2 requirements, it has not been evaluated. Digital's Distributed Name Client support DECdns requires server software, Service (DECdns) which is a layered product. A cluster can make DECnet connections independently of DECdns. LASTport and LASTport Supporting Digital's Infoserver products, which /DISK protocols protocols are outside the security domain of a clustered system, depend on these protocols. (continued on next page)
C-2 Running an OpenVMS VAX System in a C2 Environment C.2 Trusted Computing Base (TCB) for C2 Systems
Table C-1 (Cont.) Software Not Included in the C2-Evaluated System Software Function Description
LAT protocol Supporting protocol The LAT protocol is used for connections to DECserver terminal servers, which are outside the domain of the evaluated configuration.
C.2.3 Site-Specific Additions to the TCB Site-specific additions to the evaulated TCB hardware and software discussed in Section C.2.2 and Section C.2.2 include any of the following: • Hardware-including modems-not on the evaluated product list (see Section C.2.1). • Software installed with a security-relevant privilege. Images can be installed with a privilege in the Normal or Devour category (see Table 5-5). • Software installed as shared/protected, such as user-written system services • Software executing in supervisor, executive, or kernel mode. • Software linked into a TCB executable with the SYSMAN command SYS_ LOADABLE. • Software used for system administration by a privileged user. Typical site additions may include DECwindows software, loginout callouts, and other privileged Digital or third-party products. Before you add layered products, become familiar with the behavior of these products and understand their impact on your existing system. Also study the the SYSMAN database, from which layered products can be started, in the context of a C2 environment. All site-specific additions to the TCB must be controlled. Any configuration not defined in the Final Evaluation Report, Digital Equipment Corporation, Open VMS VAX and SEVMS Version 6.0 may negate the C2 status of the system. If new software or hardware is added to the TCB, the system must go through site certification of the new TCB to make sure that it still meets C2 requirements. C.3 Protecting Objects The OpenVMS operating system controls access to objects that contain information. Protected objects include ODS-2 disk files, common event flag clusters, devices, all group and system global sections, logical name tables, queues, resource domains, and ODS-2 disk volumes. The capability object and the security class object enjoy full discretionary access protection but they are not objects according to the C2 evaluation criteria. Chapter 4 describes object protection and explains how the operating system provides template profiles so all new objects have UICs, protection codes and, possibly, ACLs. Section 4.4.7, Section 4.5.6, and Section 5.5.2, in particular, explain how to set default protection for newly created objects.
C-3 Running an OpenVMS VAX System in a C2 Environment C.3 Protecting Objects
The default protections assigned to global section and mailbox objects are less restrictive than those assigned to other objects. This is due to the fact that certain software products assume that mailbox and global section objects are created, by default, with the less restrictive protections. You can modify the template profiles for these objects so they have more stringent protection, but do keep in mind that some software products may be adversely affected. To change the default protection, you need to modify both the template profile for the object and any existing object. For example, the following command modifies the mailbox template for the device class: $ SET SECURITY/CLASS=SECURITY CLASS/PROFILE=TEMPLATE=MAILBOX - _$ /PROTECTION=(S:RWPL,O:RWPL~G,W) DEVICE The operating system applies this value to all new mailboxes. The protection on each existing mailbox still has to be made more restrictive using the SET SECURITY command. For example: $ SET SECURITY/CLASS=DEVICE - _$ /PROTECTION=(S:RWPL,O:RWPL,G,W) mailbox_name The default object protections specified in security templates survive system shutdown and reboot, so rebooting the system automatically ensures that all objects created after the reboot are created with the new default protections unless an object's creator specifies an alternate protection. C.4 Protecting the TCB The code and data that make up the OpenVMS TCB reside in files and, in part, in the address space of the running operating system. They are protected by the use of file access controls and memory page protection. Memory page protection is set up by the operating system as it executes and is normally not of concern to the system manager. C.4.1 Protecting Files The files comprising the TCB are correctly protected when the operating system is installed; however, the protection can be altered by sufficiently privileged users. Appendix B of this guide describes the correct file protection of operating system files. When installing an OpenVMS operating system, avoid modifying any system files except those specific to your site. You want to maintain the security of the base operating system. C.4.2 Privileges for Trusted Users Certain privileges allow the holder to bypass normal file and memory access controls directly or indirectly and, therefore, must not be granted to persons other than the system manager, security administrator, or other trusted users. Privileges in four categories are appropriate only for trusted users: Objects, All, System, and Group. Refer to Table 5-5 for the privileges belonging to each of these categories. The privileges themselves are described in detail in Appendix A of this guide. Privileges in the Objects and All categories allow the holder to violate the isolation of the TCB from untrusted users. Privileges in the System category allow the holder to interfere with normal system operation and cause denial of service, but they do not allow the holder to actually violate object access controls.
C-4 Running an OpenVMS VAX System in a C2 Environment C.4 Protecting the TCB
Some privileges in the System category also allow access controls to be ultimately bypassed. Privileges in the Group category permit the holder to interfere with the operations of others in the same group. The GRPPRV privilege, in particular, permits the holder to violate normal access controls within that holder's group because it grants access (through the system field of the protection code) to objects owned by subjects sharing the same group UIC. All trusted users should be familiar with all the effects of any operations they perform. In particular, they need to know all software products an operation might use because a trusted user's privileges can allow untrusted software to perform operations that OpenVMS security policy would otherwise preclude. C.4.3 Privileges for Untrusted Users Untrusted users can hold any privilege in the Normal and Devour category with the exception of GRPNAM. Execise caution in granting privileges from the Devour category, however, for they permit the holder to consume resources without limit, thereby causing possible denial of service and interference with the operations of other users on the system. Table C-2 lists privileges allowed to untrusted users.
Table C-2 Privileges for Untrusted Users Category Privilege Activity Permitted Normal NETMBX Create network connections TMPMBX Create temporary mailbox Devour ACNT Disable accounting ALLSPOOL Allocate spooled devices BUGCHK Make bugcheck error log entries EXQUOTA Exceed disk quotas PRMCEB Create/delete permanent common event flag clusters PRMGBL Create permanent global sections PRMMBX Create permanent mailboxes SHMEM Create/delete structures in shared memory
C.4.4 Physical Security Physical and environmental security are critical to the secure operation of the system. All physical components of the TCB require adequate protection or else unauthorized people can jeopardize the system's security. Because the following practices and features jeopardize the security of the TCB, they must not be used in a C2 environment: • Do not put the console terminal in a public area. The console terminal must always be physically secured because it controls operation of the CPU and, consequently, operation of the system. • Do not leave the console password disabled if the console has the password feature. (It is available on some VAXstation 3100s and most later models.) The console password prevents unauthorized personnel from using commands to boot from alternate media, to perform a conversational boot, or to modify memory. • Do not allow modems. Modems provide an avenue into the trusted system, and the possibilities for compromising system security are enormous.
C-5 Running an OpenVMS VAX System in a C2 Environment C.4 Protecting the TCB
• Do not leave remote diagnostics enabled. Remote diagnostics provide another avenue into the trusted system. Disable remote diagnostics by placing the diagnostics switch in the off position. • Do not permit physical access to cluster communication media. Intruders can penetrate the system if they have physical access to any processor or cable. The operating system protects all communications interfaces against world access by default. This includes the CI and local area network (LAN) devices, such as the Ethernet, DSSI, and FDDI. The CI interface is a trusted interface among members of a CI cluster and is inaccessible to unprivileged users. Unprivileged users should not be granted access to LAN devices. • Do not allow untrusted users to access the RSC console. Place the console in an area where only authorized personnel can use it. You do not want untrusted users to perform sensitive operations, such as backing up and restoring disk volumes. • Do not allow users to read printer output of other users. Protect printer output so users have access only to their own data. • Do not leave storage media, such as disks, tapes, and compact discs, where unauthorized users can access it. Once a user has the media in their possession, they can read and modify its contents.
C.5 Configuring a C2 System This section discusses C2 constraints on the use of OpenVMS features. It includes the following topics: • Requirements for maintaining individual accountability • Correct management of the audit log file • Correct use of terminals, volumes, and printers • Cluster requirements • Required settings for system parameters • Commands and software excluded from system operation C.5.1 Keeping Individuals Accountable The proper use of names, UICs, and passwords ensures that individual accountability is enforced by the OpenVMS operating system. As a general practice, Digital recommends that you use generated passwords on privileged accounts. Because the following practices and features result in the loss of individual accountability, they must not be used in a C2 environment: • Do not assign the same UIC to more than one user. The UIC is used as the universal internal user identifier; therefore, unique UICs must be assigned to all users. • Do not allow open accounts. Lack of a password makes an account available to all users aware of its identity. The system manager can prevent open accounts by never setting null passwords with the Authorize utility (AUTHORIZE) and by ensuring that all accounts are set up with a nonzero minimum password length. • Do not allow group accounts. Individual accountability is lost when more than one person shares an account. Each user must be given a unique account.
C-6 Running an OpenVMS VAX System in a C2 Environment C.5 Configuring a C2 System
• Do not allow guest accounts because they allow multiple users access to resources on your system through a common account. Most needs for a guest account can be handled by special proxy login accounts. • Do not enable autologin. The automatic login facility (ALF) associates an account with a particular terminal instead of a particular person and, therefore, causes a loss of individual accountability. • Do not initiate network proxy accounts for groups. In order to preserve individual accountability, each individual in a network must be given a unique network proxy account on each node to which that user has access. Assign the same user name and UIC on all applicable nodes, and then set up individual proxies among the corresponding accounts. • Do not grant privileged access to proxy accounts. • Do not log operator HSC activities to a video terminal. You must use a hardcopy printer to log operator activities so it is possible to associate a specific system operation with the person performing it. • Do not allow operators to perform any task from the HSC console without signing the operator log. The sign-in log is required to track who performed HSC console operations and when. Together with the hardcopy output, the log provides a record of HSC operations. C.5.2 Managing the Auditing Trail The security-auditing system lets you to track security-relevant activity on the system provided you manage it correctly. To follow a trail of activity in the audit logs, you must have complete and accurate records. Security event messages can be recorded in the security audit log file and on any terminal designated to receive security-class event messages. Because the following practices jeopardize a site's ability to track security-relevant events in the system, they must not be used in a C2 environment: • Do not disable the audit server or OPCOM. The audit server must be running to process audit event messages and OPCOM is required to deliver alarms. • Do not use multiple audit log files in a cluster. You must use the clusterwide audit log file, which the system establishes by default. Without this clusterwide file, it is difficult to show the precise relationship among events that occur on various cluster nodes during any given time period. • Do not use a video terminal as a security operator terminal. You must enable a hardcopy terminal to receive security event messages. • Do not place the security operator terminal in a public location. Physically secure the terminal so that only authorized personnel have access to it. • Do not ignore the audit log file. You must review the security audit log file regularly for all audit events. In particular, notice whether any auditing modifications have been made. (Any use of the SET AUDIT command indicates some modification has taken place.) The audit log file is normally protected against reading or modification by unauthorized users. • Do not allow tampering with the audit log file. Alway place security-auditing ACEs on the system security audit log file to enable auditing of all attempts to modify or delete the audit log file.
C-7 Running an OpenVMS VAX System in a C2 Environment C.5 Configuring a C2 System
For example: $ SET SECURITY SYS$MANAGER:SECURITY.AUDIT$JOURNAL - $ /ACL=((ALARM=SECURITY,ACCESS=WRITE+DELETE+CONTROL+SUCCESS+FAILURE), =$ (AUDIT=SECURITY,ACCESS=WRITE+DELETE+CONTROL+SUCCESS+FAILURE)) The operating system audits ACL events by default, and you can verify this setting with the DCL command SHOW AUDIT. If necessary, reenable ACL alarms and audits with the following command: $ SET AUDIT/ALARM/AUDIT/ENABLE=ACL • Do not allow trusted users to operate without supervision. You should audit the actions of trusted users (such as operators, managers, and security administrators) by enabling auditing of changes to the Authorization database. Also place security-auditing ACEs on captive login command procedures and the directories containing them so you can detect modifications. C.5.3 Reusing Objects Before allocating memory or protected objects like volumes and devices to new users, sites must ensure that they are free of old data. The memory management subsystem protects against the reuse of system memory pages, and it cannot be defeated. Because the following practices jeopardize the clearing of old data from volumes and terminals before reallocation, they must not be followed in a C2 environment: • Do not disable highwater marking on system disk volumes. The highwater marking and erase-on-delete features of the operating system protect against reuse of disk blocks (see Section 5.18). • Do not allow users to leave their terminals on after logging out. They must turn off their terminals so the logout message is erased. The logout message reveals a user name and sometimes a node name. Moreover, by turning off the terminal, terminal characteristics are reset and memory buffers are cleared. Some Trojan horse attacks use hardware frame buffers and the answerback capabilities that are built into newer terminals. • Do not recycle tape volumes to new users until the tapes have been erased externally by operations personnel. The operating system provides no protection against reuse of tape volumes. (This is because the OpenVMS operating system considers tape drives to be single-user devices. It provides tape protection only at the volume level; an entire volume can be assigned ownership and protection but individual files on the volume cannot.) Digital recommends that sites clear printers between jobs to ensure that print jobs do not interfere with one another. A security administrator can reset printers automatically at the start or end (or both) of each job by associating a device control library with the print queue. Consult the documentation supplied with your printer to determine the appropriate reset sequence, and then refer to the Open VMS System Manager's Manual for directions on adding that sequence to a library and associating the library with the queue.
C-8 Running an OpenVMS VAX System in a C2 Environment C.5 Configuring a C2 System
C.5.4 Configuring Clusters All valid cluster configurations, when configured as common-environment clusters, fully support the OpenVMS security features.· Because the, following practices and features result in the loss of a common-environment cluster, they must not be used in a C2 environment: • Do not operate with multiple authorization databases or audit log files. A clustered system is considered a single security and management domain and must operate with a shared authorization database and a single audit log file. If you have multiple system disks for performance reasons, system managers should ensure that the system files are identical. The following files must be shared across all cluster members: NETOBJECT.DAT VMS$AUDIT_SERVER.DAT NETPROXY.DAT VMSMAIL_PROFILE.DATA QMAN$MASTER.DAT VMS$0BJECTS.DAT RIGHTSLIST.DAT VMS$PASSWORD_DICTIONARY.DATA SYS$QUEUE_ VMS$PASSWORD_HISTORY.DATA MANAGER.QMAN$QUEUES SYSUAF.DAT VMS$PASSWORD_POLICY.EXE SYSUAFALT.DAT • Do not attach nodes to the cluster that are not part of the evaluated system. The evaluated OpenVMS configuration includes DECnet software bounded to the cluster environment that is a single security domain. All physically attached nodes must be part of the evaluated system. C.5.5 Starting Up and Operating the System A C2 system is the shipped system that has been configured according to the guidelines in this appendix. When configuring your system, you must observe the following guidelines: • Use the following settings for security-sensitive parameters:
System Parameter Setting Description LGI_CALLOUTS 0 Disables use of LOGINOUT callouts LOAD_PWD_POLICY 0 Disables site-specific password filters MAXSYSGROUP 7 Sets the maximum UIC value for the system category to single-digit UICs NISCS_CONV_BOOT 0 Disables use of a conversational system bootstrap RMS_FILEPROT 65,280 Sets a default protection code for user's files of S:RWED,O:RWED,G,W SECURITY_POLICY 0 Disables certain unevaluated operating system components. STARTUP_Pl Disables the minimum sequence of the startup procedure
• Do not use the CONNECT CONSOLE command to connect to a console storage device, except on a VAX 9000 system. On a VAX 9000 system, use the console command SET SPU_UPDATE OFF to isolate the storage device. Some console subsystems support a storage device, such as a tape or disk, that is used to load system and diagnostic programs; however, the operating
C-9 Running an OpenVMS VAX System in a C2 Environment C.5 Configuring a C2 System
system also supports the capability to read and write data on a console storage device so it is neccessary to isolate the console storage device from the system. • Do not enable console operations by booting with FYDRIVER. FYDRIVER would make two DCL commands operative: SET HOST/RSC allows a user to initiate certain HSC console operations from an OpenVMS node SET HOST/DUP is used for configuring DSSI devices If you need to install FYDRIVER during system startup to configure your HSC devices and disks or perform necessary diagnostics, then perform a minimum boot and install FYDRIVER so you can configure devices and so on. Then shut down the system and reboot without FYDRIVER.
C.6 Checklist for Generating a C2 System The previous sections of this appendix describe the U.S. government requirements for running the OpenVMS operating system in a C2 environment. The following list reviews the government's security requirements: Installing the System D Did you perform a full installation (not an upgrade) as described in the Open VMS VAX Version 6.0 Upgrade and Installation Manual? Using Evaluated Components D Is all hardware in your configuration listed on the evaluated hardware list? (See Final Evaluation Report, Digital Equipment Corporation, Open VMS VAX and SEVMS Version 6.0.) D Have you excluded the following software products: DECdns, LASTport, LASTport/DISK, LAT? D Do system files have the same protection as when Digital delivered them to you? (See Appendix B.) D Did you avoid installing DECwindows software or other privileged layered products? Making Individuals Accountable D Have you trained privileged users so they understand the effect of operations they may perform? D Does each user have a unique UIC? D Do all accounts have passwords of nonzero length? D Does each user have a separate account? D Have you eliminated any guest accounts? D Have you disabled all autologins? D Does each user have a unique proxy? D Are all proxy accounts nonprivileged? D Do you log operators' HSC activities on a hardcopy printer?
C-10 Running an OpenVMS VAX System in a C2 Environment C.6 Checklist for Generating a C2 System
D Does the HSC console have a sign-in log, and are your operators trained to use it? Managing the Audit Reporting System D Are the audit server and OPCOM processes running? D Do you have one audit log file for the entire cluster? D Are you using a hardcopy terminal as the security operator terminal? D Is the security operator terminal accessible only to authorized personnel? D Do you have a procedure for reviewing the audit log file on a regular basis? D Does the audit log file have both Audit and Alarm ACEs? D Are the Authorization and ACL event classes enabled? D Did you put Audit ACEs on all captive login command procedures and their home directories? Reusing Disks, Tapes, and Terminals D Is highwater marking enabled on system disk volumes? D Are users trained to shut off their terminals after logging out? D Do you have a procedure for erasing tapes before they are used again? Building a Single Security Domain D Does your cluster have only one copy of the following files? NETOBJECT.DAT VMS$AUDIT_SERVER.DAT NETPROXY.DAT VMSMAIL_PROFILE.DATA QMAN$MASTER.DAT VMS$0BJECTS.DAT RIGHTSLIST.DAT VMS$PASSWORD_DICTIONARY.DATA SYS$QUEUE_ VMS$PASSWORD_HISTORY.DATA MANAGER.QMAN$QUEUES SYSUAF.DAT VMS$PASSWORD_POLICY.EXE SYSUAFALT.DAT D Are all nodes in the cluster part of the C2 configuration? Starting the System D Do security sensitive parameters have the following settings? LGI_CALLOUTS 0 LOAD_PWD_POLICY 0 MAXSYSGROUP 7 NISCS_CONV_BOOT 0 RMS_FILEPROT 65,280 SECURITY_POLICY 0 STARTUP_Pl 0 Is the CONNECT CONSOLE command disabled? (On VAX 9000 systems, is the SET SPU_UPDATE_OFF command in effect?) D Have you excluded FYDRIVER from your system?
C-11
D Alarm Messages
This appendix describes alarm messages that result from auditing various system events. Refer to the Open VMS System Management Utilities Reference Manual for a description of the record format of audit messages. The information included in the alarm message depends on the type of event. In all cases, the alarm message contains the operator communication manager (OPCOM) heading, which includes the date and time the alarm was sent. It contains the type of alarm event, the date and time the alarm event occurred, and the user who caused the event, as identified by the user name and process identification (PID). Other information contained in alarm messages is specific to the type of event that the alarm signaled. Alarms Announcing an Object Access You can audit successful or unsuccessful access to a protected object by specifying the ACCESS keyword with the /ENABLE qualifier of the SET AUDIT· command. You designate the object type with the /CLASS qualifier. See Section 4·. 7 for a description of object auditing. For example: %%%%%%%%%%% OPCOM 17-SEP-1993 10:13:20.46 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Object access Event time: 17-SEP-1993 10:13:20.09 PID: 30200117 Process name: Hobbit Username: GREG Process owner: [MTI,GREG] Terminal name: RTAl: Image name: DSAl:[GREG.TEST.ACCESS]ACCESS.EXE;SO Object class name: COMMON EVENT CLUSTER Object name: FOO - - Access requested: READ Deaccess key: 808E3380 Status: %SYSTEM-S-NORMAL, normal successful completion Privileges used: none You can also audit access through the use of GRPPRV, READALL, SYSPRV, or BYPASS privilege.
D-1 Alarm Messages
Alarms Requested by an ACL You can audit successful or unsuccessful access to individual protected objects by adding an Alarm ACE or an Audit ACE to an object's ACL and enabling ACL events by specifying the ACL keyword with the /ENABLE qualifier of the SET AUDIT command. For example: %%%%%%%%%%% OPCOM 12-NOV-1992 10:53:16.34 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) and security audit (SECURITY) on FNORD, system id: 19681 Auditable event: Object deletion Event information: file deletion request (IO$ DELETE) Event time: 12-NOV-1992 10:53:16.30 - PID: 20200158 Process name: FNORD$RTA2 Username: HUBERT Process owner: [LEGAL,HUBERT] Terminal name: RTA2: Image name: $1$DIAl:[SYSO.SYSCOMMON.][SYSEXE]DELETE.EXE Object class name: FILE Object owner: [SYSTEM] Object protection: SYSTEM:RWE, OWNER:RWE, GROUP:, WORLD: File name: $1$DIA3:[USERS.HUBERT.TMP]FOO.BAR;2 File ID: (4134,20,0) Access requested: DELETE Sequence key: 0005E05F Status: %SYSTEM-F-NOPRIV, insufficient privilege or object protection violation Alarms Due to Modification of the Authorization Databases The Authorization class of security events is enabled by default. All changes to the rights database, the system user authorization file, and the network user authorization file immediately produce an audit event message. Changes to the rights database result from such actions as the creation of a new database or the addition, modification, or removal of an identifier. The audit server also reports when there is a change in a user's identifiers. Note that the alarm message cites the image used to modify the rights database and the change itself. For example: %%%%%%%%%%% OPCOM 15-DEC-1993 12:27:17.44 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 Auditable event: Identifier modified Event time: 15-DEC-1993 12:27:17.43 PID: 00000113 Username: SYSTEM Image name: LASSIE$DMAO:[SYSO.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE Identifier name: ROBINSON Identifier value: %X80010014 New attributes: RESOURCE
D-2 Alarm Messages
In reporting changes to the system or network user authorization files, the audit server also notes any kind of modification as well as the record modified and the change made. For example: %%%%%%%%%%% OPCOM 18-DEC-1993 19:53:25.99 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 Auditable event: System UAF record addition Event time: 18-DEC-1993 19:53:25.98 PID: 20200B25 Username: SYSTEM Image name: $1$DUSO:[SYSO.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE Object name: SYS$COMMON:[SYSEXE]SYSUAF.DAT;2 Object type: file User record added: COOPER Fields modified: FLAGS,PWDLIFETIME The following alarm message is an example of an alarm resulting from a password change: %%%%%%%%%%% OPCOM 26-SEP-1993 15:12:35.95 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) and security audit (SECURITY) on FNORD, system id: 20300 Auditable event: System UAF record modification Event time: 26-SEP-1993 15:12:35.92 PIO: 52C00119 Process name: Hobbit Username: GREG Process owner: [RTB,GREG] Terminal name: RTA2: Image name: $99$DUAO:[SYSO.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE Object name: CLU$COMMON:
D-3 Alarm Messages
Alarms Announcing Creation of an Object You can audit the creation of objects by specifying the CREATE keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm notes the class of the object as well as its object name. For example: %%%%%%%%%%% OPCOM 17-SEP-1993 10:13:20.29 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Object creation Event time: 17-SEP-1993 10:13:20.01 PIO: 30200117 Process name: Hobbit Username: HUBERT Process owner: [SST,HUBERT] Terminal name: RTAl: Image name: DSAl:[HUBERT.TEST.ACCESS]ACCESS.EXE;SO Object class name: COMMON EVENT CLUSTER Object name: FOO - - Status: %SYSTEM-S-NORMAL, normal successful completion Alarms Announcing Deaccess from an Object You can audit the deaccess of a process from an object by specifying the DEACCESS keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm notes the class of the object. For example: %%%%%%%%%%% OPCOM 17-SEP-1993 10:13:38.34 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Object deaccess Event time: 17-SEP-1993 10:13:38.31 PIO: 30200117 Object class name: COMMON EVENT CLUSTER Deaccess key: 808E33BO - Alarms Announcing Deletion of an Object You can audit the deletion of objects by specifying the DELETE keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm notes the class of the object as well as its object name. For example: %%%%%%%%%%% OPCOM 17-SEP-1993 10:13:36.17 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Object access Event time: 17-SEP-1993 10:13:36.08 PIO: 30200117 Process name: Hobbit Username: HUBERT Process owner: [MTI,HUBERT] Terminal name: RTAl: Image name: DSAl:[HUBERT.TEST.ACCESS]ACCESS.EXE;SO Object class name: COMMON EVENT CLUSTER Object name: FOO - - Access requested: DELETE Status: %SYSTEM-S-NORMAL, normal successful completion Privileges used: none
0-4 Alarm Messages
Alarms Announcing Use of the Install Utility You can audit the use of the Install utility (to install an image or to remove an installed image) by specifying the INSTALL keyword with the /ENABLE qualifier of the SET AUDIT command. Install alarms identify the type of operation, the name of the image affected by the operation, the flags set by the Install operation, and the privileges used. For example: %%%%%%%%%%% OPCOM 7-DEC-1993 12:37:49.69 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) on LASSIE, system id: 19661 Auditable event: Installed file addition Event time: 7-DEC-1993 12:37:49.68 PIO: 00000113 Username: SYSTEM Object name: LASSIE$DMAO:[SYSO.SYSCOMMON.][SYSEXE]NCP.EXE;l Object type: file INSTALL flags: /OPEN/HEADER RESIDENT/SHARED Alarms Announcing Logins You can audit successful logins by specifying the LOGIN keyword with the /ENABLE qualifier of the SET AUDIT command. You can audit batch, dialup, local, remote, network, subprocess and detached login types. This type of alarm notes the type of login, the device used, the origin of the login (if it was remote or network), the parent PID (if the login was subprocess), and the parent user name (if the login was detached). For example: %%%%%%%%%%% OPCOM 18-DEC-1993 18:49:40.09 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) on LASSIE, system id: 19611 Auditable event: Batch process login Event time: 18-DEC-1993 18:49:40.08 PIO: 20002001 Username: LEWIS Alarms Announcing Login Failures You can audit login failures by specifying the LOGFAILURE keyword with the /ENABLE qualifier of the SET AUDIT command. You can audit the batch, dial up, local, remote, network, subprocess and detached login failure types. This type of alarm contains the type of login, the device used, a status message detailing the reason for the failure, the origin of the login (if it was remote or network), the parent PID (if the login was subprocess), and the parent user name (if the login was detached). For example: %%%%%%%%%%% OPCOM 7-DEC-1993 12:48:43.50 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) on LASSIE, system id: 19611 Auditable event: Network login failure Event time: 7-DEC-1993 12:48:43.49 PIO: 00000110 Username: DECNET Remote nodename: TIGER Remote node id: 3218 Remote username: PROBER Status: %LOGIN-F-INVPWD, invalid password
D-5 Alarm Messages
Alarms Announcing Logouts You can audit logouts by specifying the LOGOUT keyword with the /ENABLE qualifier of the SET AUDIT command. You can audit batch, dialup, local, remote, network, subprocess and detached logout types. This type of alarm contains the type of logout, the device used, the origin of the login (if it was remote or network), and the parent PID (if the login was subprocess). For example: %%%%%%%%%%% OPCOM 18-DEC-1993 19:14:22.03 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) on LASSIE, system id: 19611 Auditable event: Dialup interactive logout Event time: 18-DEC-1993 19:14:22.02 PID: 20200001 Username: DANCER Terminal name: TTAl: Alarms Announcing Volume Mounts and Dismounts You can audit mount or dismount requests by specifying the MOUNT keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm contains the name of the image used to mount or dismount the volume, the device used, the log file recording the operation, the volume name, its UIC and protection code, and the flags set during the operation. For example: %%%%%%%%%%% OPCOM 18-DEC-1993 17:43:26.94 %%%%%%%%%%% Message from user AUDIT$SERVER on CANINE Security alarm (SECURITY) on CANINE, system id: 19681 Auditable event: Volume mount Event time: 18-DEC-1993 17:43:26.04 PID: 00000038 Username: HOBBIT Image name: CANINE$DUAO:[SYSO.SYSCOMMON.][SYSEXE]VMOUNT.EXE;l Object name: CANINE$MUAO: Object type: device Object owner: [DEVO,HOBBIT] Object protection: SYSTEM:RWEDC, OWNER:RWEDC, GROUP:RWEDC, WORLD:RWEDC Logical name: TAPE$DBACK1 Volume name: DBACKl Mount flags: /OVERRIDE=IDENT/MESSAGE Alarms Reporting Network Connections You can audit Network Control Program (NCP) command lines with the associated completion status as well as the creation and termination of logical links with other nodes in the network. To do so, specify the CONNECTION keyword with the /ENABLE qualifier of the SET AUDIT command. For example: Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19681 Auditable event: DECnet logical link deleted Event time: 12-NOV-1992 10:54:25.01 PID: 202002EB Process name: FAL 16729 Username: HUBERT N Process owner: [ACCOUNTS,HUBERT] Image name: $1$DIAl:[SYSO.SYSCOMMON.][SYSEXE]FAL.EXE Remote nodename: JPT Remote node id: 19586 Remote username: HUBERT DECnet logical link ID: 16729 DECnet object name: FAL DECnet object number: 17 Remote logical link ID: 35429 Status: %SYSTEM-S-NORMAL, normal successful completion
D-6 Alarm Messages
Alarms Reporting Use of Process Control System Services You can audit use of the process control system services, such as $CREPRC or $GETJPI, by specifying the PROCESS keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm reports the system service used to control a process, the device used, the name of the process and its user name. For example: %%%%%%%%%%% OPCOM 25-JUL-1993 16:07:09.20 %%%%%%%%%%% Message from user AUOIT$SERVER on FNORO Security alarm (SECURITY) on FNORO, system id: 20300 Auditable event: Process suspended ($SUSPNO) Event time: 25-JUL-1993 16:07:08.77 PID: 30C00119 Process name: Hobbit Username: HUBERT Process owner: [LEGAL,HUBERT] Terminal name: RTAl: Image name: $99$0UAO:[SYSO.SYSCOMMON.][SYSEXE]SET.EXE Status: %SYSTEM-S-NORMAL, normal successful completion Target PIO: 30C00126 Target process name: SMISERVER Target username: SYSTEM Target process owner: [SYSTEM] Alarms Reporting Use of Privilege You can audit the use of privilege by specifying the PRIVILEGE keyword with the /ENABLE qualifier of the SET AUDIT command. The alarm reports the privilege used and what it was used to do. For example: %%%%%%%%%%% OPCOM 17-SEP-1993 10:13:20.16 %%%%%%%%%%% Message from user AUOIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Privilege used Event information: PRMCEB used to create permanent common event flag cluster ($ASCEFC) Event time: 17-SEP-1993 10:13:20.01 PIO: 30200117 Process name: Hobbit Username: HUBERT Process owner: [MTI,HUBERT] Terminal name: RTAl: Image name: OSAl:[HUBERT.TEST.ACCESS]ACCESS.EXE;50 Event flag cluster name: FOO Privileges used: PRMCEB
D-7 Alarm Messages
Alarms Reporting Modification of a System Parameter You can audit the modification of a system parameter by specifying the SYSGEN keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm reports on both the active parameters and the parameters stored on disk. For example: %%%%%%%%%%% OPCOM 25-JUL-1993 16:09:04.67 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 20300 Auditable event: SYSGEN parameter set Event time: 25-JUL-1993 16:09:04.65 PID: 30C00119 Process name: Hobbit Username: HUBERT Process owner: [LEGAL,HUBERT] Terminal name: RTAl: Image name: $99$DUAO:[SYSO.SYSCOMMON.][SYSEXE]SYSGEN.EXE Parameters write: SYS$SYSROOT:[SYSEXE]VAXVMSSYS.PAR;68 Parameters inuse: SYS$SYSROOT:[SYSEXE]VAXVMSSYS.PAR;68 NSA PAGES: New: 15 Original: 10 Alarms Reporting a Change in System Time You can audit changes to system time by specifying the TIME keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm reports the old and the new system time, the name of the user making the modification, and the device used. For example: %%%%%%%%%%% OPCOM 25-JUL-1993 16:08:25.23 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 20300 Auditable event: System time recalibrated Event time: 25-JUL-1993 16:08:25.21 PID: 30C00119 Process name: Hobbit Username: HUBERT Process owner: [LEGAL,HUBERT] Terminal name: RTAl: Image name: $99$DUAO:[SYSO.SYSCOMMON.][SYSEXE]SET.EXE New system time: 25-JUL-1993 16:08:25.19 Old system time: 25-JUL-1993 16:08:25.18 Alarms Resulting from Execution of the SET AUDIT Command All uses of the SET AUDIT command are automatically audited, and you cannot disable it. The following alarm messages are examples of SET AUDIT alarms: %%%%%%%%%%% OPCOM 12-NOV-1992 10:54:11.91 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) and security audit (SECURITY) on FNORD, system id: 19681 Auditable event: Security alarm state set Event time: 12-NOV-1992 10:54:11.58 PID: 20200158 Alarm flags: ACL,AUTHORIZATION,CONNECTION BREAKIN: (DIALUP,LOCAL,REMOTE,NETWORK,DETACHED) LOGFAIL: (BATCH,DIALUP,LOCAL,REMOTE,NETWORK, SUBPROCESS,DETACHED)
D-8 Glossary
This glossary provides definitions of security-related terms used in this guide.
access control Restrictions on the ability of a subject (user or process) to use the system or an object in the computing system. Authentication of the user name and password controls access to the system, while protection codes and access control lists regulate access to protected objects in that system.
access control entry An entry in an access control list (ACL). Access control entries (ACEs) may specify identifiers and the access rights to be granted or denied the holders of the identifiers, default protection for directories, or security details. ACLs for each object can hold many entries, limited only by overall space and performance considerations. See also access control list, identifier.
access control string A character string used in remote logins. It consists of the user name for the remote account and the user's password enclosed within quotation marks. access control list A list that defines the kinds of access to be granted or denied to users of an object. Access control lists (ACLS) can be created for all protected objects such as files, devices, and logical name tables. Each ACL consists of one or more entries known as access control entries (ACEs). See also access control entry. access matrix A table that lists subjects on one axis and objects on the other. Each crosspoint in the matrix thus represents the access that one subjeCt has to one object. access type The capability required to perform an operation on a protected object. OpenVMS security policy can require multiple capabilities to complete an operation. The most commonly accessed object, a file, can require read, write, execute, delete, or control access.
ACE See access control entry.
ACL See access control list.
Glossarv-1 ACL editor An OpenVMS utility that helps users create and maintain access control lists. See also access control list.
alarm See security alarm.
ALF file See automatic login.
alphanumeric UIC A format of a user identification code (UIC). The group and member names can each contain up to 31 alphanumeric characters, at least one of which is alphabetic. The other format of a UIC is numeric: it contains a group number and a member number. See also user identification code, numeric UIC.
attribute In the security context, a characteristic of an identifier or the holder of an identifier. Attributes can enhance or limit the rights granted with an identifier; for example, a user holding an identifier with the Resource attribute can charge disk space to the identifier.
audit See security audit.
auditing Recording the occurrence of security-relevant events as they occur on the system and, later, examining system activity for possible security violations or improper use of the system. Security-relevant events include activities such as logins, break-ins, changes to the authorization database, and access to protected objects. Event messages can be sent as alarms to an operator terminal or written as audit records to a log file. See also security audit, security alarm.
audit trail A pattern of security-relevant activity sometimes found in the audit log file. The audit log file maintains a record of security-relevant events, such as access attempts, successful or not, as required by the authorization database. See also security audit.
authentication The act of establishing the identity of users when they start to use the system. OpenVMS systems (and most other commercial operating systems) use passwords as the primary authentication mechanism. See also password.
authorization database A database that contains the security attributes of subjects and objects. From these attributes, the reference monitor determines what kind of access (if any) is authorized. _
authorization file See system user authorization file.
Glossary-2 automatic login A feature that permits users to log in without specifying a user name. The operating system associates the user name with the terminal (or terminal server port) and maintains these assignments in the file SYS$SYSTEM:SYSALF.DAT, referred to as the automatic login file or the ALF file. breach A break in the system security that results in admittance of a person or program to an object. break-in attempt An effort made by an unauthorized source to gain access to the system. Because the first system access is achieved through logging in, break-in attempts primarily refer to attempts to log in illegally. These attempts focus on supplying passwords for users known to have accounts on the system through informed guesses or other trial-and-error methods. See also evasive action.
C2 system A U.S. government rating of the security of an operating system; it identifies an operating system as one that meets the criteria of a Division C, class 2 system. capability A resource to which the system controls access; currently, the only defined capability is the vector processor. OpenVMS security policy protects vector processors from improper access. An operation can require use or control access. captive account A type of account that confines the user to the captive login command procedure. The use of Ctrl/Y is disabled. If errors in the captive command procedure cause the procedure to terminate and attempt to return the user to the DCL command level, the process is deleted. (This type of account is synonymous with a turnkey or tied account.) common event flag cluster A set of 32 event flags that enable cooperating processes to post event notifications to each other. OpenVMS security policy protects common event flag clusters from improper access. An operation can require associate, delete, or control access. control access The right to modify an object's security profile. Control access is granted explicitly in an ACL and implicitly in a protection code. (All users qualifying for system or owner categories have control access.) decryption The process that restores encoded information to its original unencoded form. The information was encoded by using encryption.
Glossary-3 Default attribute An option added to an ACE that indicates the ACE is to be included in the ACL of any files created within a directory. When the entry is propagated, the Default attribute is removed from the ACE of the created file. An Identifier ACE with the Default attribute has no effect on access. See also access control entry, Identifier ACE.
device A class of peripherals connected to a processor that are capable of receiving, storing, or transmitting data. OpenVMS security policy protects devices from improper access. An operation can require read, write, physical, logical, or control access.
discretionary controls Security controls 'that are applied at the user's option; that is, they are not required. Access control lists (ACLs) are typical of such optional security features. Discretionary controls are the opposite of mandatory controls.
disk scavenging Any method of obtaining information from a disk that the owner intended to discard. The information, although no longer accessible to the original owner by normal means, retains a sufficient amount of its original magnetic encoding that it can be retrieved and used by one of the scavenging methods. See also erase-on-allocate, erase-on-delete, erasure pattern.
encryption A process of encoding information so that its content is no longer immediately obvious to anyone who obtains a copy of it. The information is decoded using decryption.
environmental identifier One of four classes of identifiers. Environmental identifiers are provided by the system to identify groups of users according to their usage of the system. Environmental identifiers correspond to login classes. For example, all users who access the system by dialing up receive the dialup identifier. See also identifier.
erase-on-al locate A technique that applies an erasure pattern whenever a new area is allocated for a file's extent. The new area is erased with the erasure pattern so that subsequent attempts to read the area can yield only the erasure pattern and not some valuable remaining data. This technique is used to discourage disk scavenging. See also disk scavenging, erase-on-delete, erasure pattern, highwater marking.
erase-on-delete A technique that applies an erasure pattern whenever a file is deleted or purged. This technique is used to discourage disk scavenging. See also disk scavenging, erase-on-allocate, erasure pattern.
erasure pattern A character string that can be used to overwrite magnetic media for the purpose of erasing the information that was previously stored in that area.
Glossary-4 evasive action A responsive behavior performed by the operating system to discourage break-in attempts when they appear to be in progress. The operating system has a set of criteria it uses to detect that break-in attempts may be underway. Typically, once the operating system becomes suspicious that an unauthorized user is attempting to log in, the evasive action consists of locking out all login attempts by the offender for a limited period of time. · event classes Categories of security-relevant events. The operating system audits several event classes by default, and the security administrator can enable additional ones, if desired. event messages In terms of security, any notification has to do with a user's access to the system or to a protected object within the system. The operating system can record both successful and unsuccessful events so the security administrator can know when security-relevant activity occurs on the system. facility identifier An identifier that combines the facility code for an application with a value assigned by the $ADD_HOLDER and $ADD_IDENTIFIER system services during the product's installation. See also identifier. file A set of data elements arranged in a structure significant to the user. A file is any named, stored program or data, or both, to which the system has access. Access can be of two types: read-only, meaning the file is not to be altered, and read/write, meaning the contents of the file can be altered. See also volume. OpenVMS security policy protects files from improper access. An operation can require read, write, execute, delete, or control access. file encryption See encryption. general identifier One of four possible types of identifiers that specify one or more groups of users. The general identifier is alphanumeric and typically is a convenient term that symbolizes the function of the group of users. For example, typical general identifiers might be PAYROLL for all users allowed to run payroll applications or RESERVATIONS for operators at the reservations desk. See also identifier. global section A shared memory area (for example, FORTRAN global common) potentially available to all processes in the system. A global section can provide access to a disk file (called a file-backed global section), provide access to dynamically created storage (called a page file-backed global section), or provide access to specific physical memory (called a page frame number [PFN] global section). See also group global section, system global section.
Gln~~~rv-5 group A set of users in a system. Any user whose group UIC is identical to the group UIC of the object qualifies for the access rights granted through a protection code. The group name appears as the first field of a user identification code (UIC): [group,member].
group global section A shareable memory section potentially available to all processes in the same group. OpenVMS security policy protects group global sections from improper access. Operations on file-backed sections require read, write, execute, delete, or control access. Operations on other types of sections require read, write, execute, or control access. See also global section, system global section.
group number The number or its alphanumeric equivalent in the first field of a user identification code (UIC): [group,member].
Hidden attribute An option added to an ACE that indicates the ACE should be changed only by the application that adds it. Although the Hidden attribute is valid for any ACE type, its inte.nded use is to hide Application ACEs. See also access control entry.
highwater mark A mark identifying the physical end of file, beyond which the user cannot read.
highwater marking A technique for discouraging disk scavenging. This technique tracks the furthest extent that the owner of a file has written into the file's allocated area (the highwater mark). It then prohibits any attempts at reading beyond the written area, on the premise that any information that exists beyond the currently written limit is information some user had intended to discard. The operating system accomplishes the goals of highwater marking with its erase-on-allocate strategy. See also erase-on-allocate.
holder A user who possesses a particular identifier. Users and the identifiers they hold are recorded in the rights database. Whenever an object requires an accessor to hold an identifier, the system checks the process rights list (which is built from the rights database) in processing the access request.
identifier An alphanumeric string representing a user or group of users recorded in the rights database and used by the system in checking access requests. There are four types of identifiers: environmental, facility, general, and UIC. See also environmental identifier, facility identifier, general identifier, UIC identifier, resource identifier.
Identifier ACE An access control entry that controls the type of access allowed to a particular user or group of users.
Glossary-6 journal Name of the auditing log file where the system records events with security implications, such as logins, break-ins, or changes to the authorization database. locked password A password that cannot be changed by the account's owner. Only system managers or users with the SYSPRV privilege can change locked passwords. log A record of performance or system-relevant events. logical 1/0 access Right to perform a set of I/O operations that allow restricted direct access to device-level I/O operations using logical block addresses. logical name table A shareable table of logical names and their equivalence names for the operating system or a particular group. OpenVMS security policy protects logical name tables from improper access. An operation can require read, write, create, delete, or control access. login The series of actions involved in authenticating a user to the system and creating a process that runs on the user's behalf. login class A user's method of logging into the system. System managers can control system access based on the login class: local, dialup, remote, batch, or network. mandatory controls Security controls that are imposed by the system upon all users. There are no examples of mandatory controls within the OpenVMS system. Access controls on this operating system are optional (discretionary). ·
NETPROXV See network proxy authorization file. network proxy authorization file (NETPROXV.DAT) A file containing an entry for each user authorized to connect to the local system from a remote node in the network. It is sometimes referred to as the network user authorization file (NETUAF.DAT). nondiscretionary controls See mandatory controls. non privileged Describes a type of account with no privilege other than TMPMBX and NETMBX and a user identification code (UIC) greater than the system parameter MAXSYSGROUP.
Glossary-7 Nopropagate attribute An option added to an ACE that indicates the ACE cannot be copied by operations that usually propagate ACEs, such as SET SECURITY/LIKE. See also access control entry.
numeric UIC A format of a user identification code (UIC) that specifies the user's group and member number in numeric form. The group number is an octal number in the range of 1 through 37776; the member number is an octal number in the range of 0 through 177776.
object A passive repository of information to which the system controls access. Access to an object implies access to the information it contains. See also capability, common event fiag cluster, device, file, group global section, logical name table, queue, resource domain, security class, system global section, volume.
object class A set of protected objects with common elements. For example, all files belong to the file class whereas all devices belong to the device class.
object security profile A set of security elements that define access requirements. The elements include an owner (UIC), a DIC-based protection code, and, possibly, an ACL. See also access control list, owner, protection code.
open accounts Accounts that do not require passwords.
operator terminal A terminal attended by a system operator. The system can send system event messages to the terminal, provided the event class is enabled.
owner A user with the same user identification code (UIC) as the protected object. An owner always has control access to the object and can therefore modify the object's security profile. When the operating system processes an access request from an owner, it considers the access rights in the owner field of a protection code.
password A character string that users provide at login time to validate their identity and as a form of proof of their authorization to access the account. There are system passwords and user passwords. User passwords include both primary and secondary passwords. See also primary password, secondary password, system password, user password.
physical 1/0 access Right to perform a set of 1/0 functions that allows access to all device-level 1/0 operations except maintenance mode using physical block addresses.
Glossary-a primary password A type of user password that is the first user password requested from the user. Systems may optionally require a secondary password. A primary or a secondary password must be associated with the user name in the user authorization file. See also secondary password. privileges A means of protecting the use of certain system functions that can affect system resources and integrity. System managers grant privileges according to user's needs and deny them to users as a means of restricting their access to the system. process security profile The set of security elements the system assigns to a process at creation. Elements include the process UIC plus all of its identifiers and privileges. See also identifier, privileges, user identification code.
Protected attribute An option added to an ACE that indicates the ACE is protected against casual deletion. It can be deleted by using the ACL editor or by specifying the ACE explicitly when deleting it. protected object An object containing shareable information to which the system controls access. See also object. protected subsystem An application with enhanced access control. While users run the application, their process rights list contains identifiers giving them access to objects owned by the subsystem. As soon as they exit the application, these identifiers and, therefore, access rights to objects are taken away. protection The attributes of an object that limit the type of access available to users. See also access control list, protection code, user identification code. protection code A code defining the type of access that users are allowed to objects, based on the user's relationship to the object's owner. The code defines four sets of users: those with system rights, those with ownership rights, those belonging to the same group, and all users on the system, who are called world users. See also group, owner, system, world. proxy login A type of login that permits a user from a remote node to effectively log in to a local node as if the user owned an account on the local node. However, the user does not specify a password in the access control string. The remote user may own the account or share the account with other users. pseudodevice An entity like a mailbox that is treated as an 1/0 device by the user or system, although it is not any particular physical device.
Glossary-9 queue A set of jobs to be processed. There are four types of generic queues: batch, terminal, server, and print. OpenVMS security policy protects queues from improper access. An operation can require read, submit, manage, delete, or control access.
reference monitor The control center within the operating system that authenticates subjects and implell1:ents and enforces the security policy for every access to an object by a subject.
Resource attribute An option specified when an identifier is added to the rights database, and later when the identifier is granted to a user. When a user holds the identifier with the Resource attribute, that user can charge disk space to the identifier.
resource domain A namespace controlling access to OpenVMS distributed lock management resources. OpenVMS security policy protects resource domains from improper access. An operation can require read, write, lock, or control access.
resource identifier An identifier with the Resource attribute. Thus, holders of the identifier can charge disk space to the identifier.
restricted account A type of account with a secure login procedure. The user is not allowed to use the Ctrl/Y key sequence during the system or process login command procedure. Control may be turned over to the user following execution of the login command procedures.
rights database The collection of data the system maintains and uses to define identifiers and associate identifiers with the holders of the identifiers.
rights identifier See identifier.
rights list The list associated with each process that includes all the identifiers the process holds.
AWED The abbreviation for read, write, execute, delete, which are types of access to data files and directory files.
Glossary-10 secondary password A user password that may be required at login time immediately after the primary password has been submitted correctly. Primary and secondary passwords can be known by separate users to ensure that more than one user is present at the login. A less common use is to require a secondary password as a means of increasing the password length so that the total number of combinations of characters makes password guessing more time-consuming. See also primary password. secure terminal server Operating system software designed to ensure that users can log in only to terminals that are already logged out. When the user presses the Break key on a terminal, the secure server (if enabled) responds by first disconnecting any logged-in process and then initiating a login. If no process is logged in at the terminal, the login can proceed immediately. security administrator The person or persons responsible for protecting the security of the computer system. This role is sometimes performed by the same person who functions as a system manager. It requires the same skills as the system manager but includes additional privilege (the SECURITY privilege) as well as knowledge of the security features provided with the operating system. security alarm A message sent to an operator terminal that is enabled to receive messages pertaining to security events. Security alarms are triggered by the occurrence of an event previously designated as worthy of the alarm because of its security implications. security audit An auditing message written to the security audit log file. These messages report the occurrence of events with security implications, such as logins, break-ins, and changes to the authorization database. A system administrator uses the log file to examine system activity for possible security violations or improper use of the system. security auditing See auditing. security class A data structure containing the elements and management routines for all members of the security class. OpenVMS security policy protects security classes from improper access. An operation can require read, write, or control access. security manager See security administrator.
Glossary-11 security operator terminal A class of terminal that has been enabled to receive messages sent by OPCOM to security operators. These messages are security alarm messages. Normally such a terminal is a hardcopy terminal in a protected room. The output provides a log of security-related events and details that identify the source of the event.
security profile A set of elements that describe either an object's access requirements or a subject's access rights. See also object security profile, process security profile.
subject A prinicpal, either a user process or an application, that accesses information or is prevented from accessing information. The operating system controls access to any object that contains shareable information. Therefore, subjects must be authorized to access objects. See also process security profile.
system In the context of a protection code, identifies a set of users in a system. System users typically have a UIC is in the range 1 through 10 (octal); however, the exact range of a system UIC is determined by the system parameter MAXSYSGROUP. Other ways to become a system user include having SYSPRV privilege or being in the same group as the owner and holding GRPPRV. System operators and system managers are usually system users.
system-defined identifier See environmental identifier.
system global section A shareable memory section potentially available to all processes in the system. OpenVMS security policy protects system global sections from improper access. Operations on file-backed sections require read, write, execute, delete, or control access. Operations on other types of sections require read, write, execute, or control access.
system password A password controlling access to particular terminals. System passwords are usually necessary to control access to terminals that might be targets for unauthorized use, such as dialup and public terminal lines. After an authorized person enters the system password, a user can enter his user password. See also user password.
system user authorization file (SYSUAF.DAT) A file containing an entry for every user that the system manager authorizes to gain access to the system. Each entry identifies the user name, password, default account, user identification code (UIC), quotas, limits, and privileges assigned to individuals who use the system.
SYSUAF See system user authorization file.
TCB See trusted computing base.
Glossary-12 template profile The default set of security elements applied to new objects of a class. See also object security profile. tied account See captive account. trap door An illicit piece of software in an operating system that provides a way for intruders to enter easily and without detection.
Trojan horse program A program that gains access to otherwise secured areas through its pretext of serving one purpose when its real intent is far more devious and potentially damaging. When an authorized user performs an legitimate operation using a program, the unauthorized program within it (the Trojan horse) performs an unauthorized function. trusted computing base (TCB) A combination of computer hardware and operating system software that enforces a security policy. In OpenVMS systems, the TCB includes the entire executive and file system, all other system components that do not execute in user mode (such as device drivers, RMS, and DCL), most system programs installed with privilege, and a variety of other utilities used by system managers to maintain data relevant to the TCB. turnkey account See captive account. UAF See system user authorization file.
UIC See user identification code.
UIC identifier An identifier in alphanumeric format that is based on a user's identification code (UIC). Such an identifier can appear with or without brackets. See also identifier.
UIC protection code See protection code. user category One of four fields in a protection code. The code defines the access rights for four categories of users: (a) the owner, (b) the users who share the same group UIC as the owner (the group category), (c) all users on the system (the world category), and (d) those with system privileges or rights (the system category). A code lists access rights in a fixed order: System, Owner, Group, World.
Glossary-13 user identification code (UIC) A 32-bit value assigned to users that tells what group users belong to on the system and what their unique identification is within that group. Any UIC specification is enclosed in brackets, but it can be in either an alphanumeric or a numeric format. For example, the UIC [SALES,JONES] identifies Jones as a member of the Sales group. Protected objects like files also have UICs. In most cases, their UICs come from the users who created them.
user irresponsibility Situations where the user purposely or accidentally causes some noticeable damage on a computer system.
user name The name a user enters to log in to the system. Together with a password, the user name identifies and authenticates a person as a valid of the system. See also password, user password.
user password A character string recorded in a user's record in the system user authorization file. The password and the user's name must be correctly supplied when the user attempts to log in so that the user is authenticated for access to the system. The two types of user passwords are known as primary and secondary; the terms also represent the sequence in which they are entered. System passwords control access to particular terminals. See also primary password, secondary password, system password.
user penetration Situations where the user breaks through security controls to gain access to the computer system.
user probing Situations where a user exploits insufficiently protected parts of a computer system.
volume A mass storage medium, such as a disk or tape, that is in ODS-2 format. Volumes contain files and may be mounted on devices. OpenVMS security policy protects volumes from improper access. An operation can require read, write, create, delete, or control access.
world A category of users whose access rights to an object are identified in the last field of a protection code. The world category encompasses all users or applications on the system, including system operators, system managers, and users both in the owner's group and any other group.
Glossary-14 worm A command procedure or executable image written and placed on the system for the sole purpose of seeking unauthorized access to files and accounts on the system. The worm seeks access to a user file through a flaw in the file protection. If successful, the worm modifies the file so that it carries a copy of the worm. Each time an unsuspecting user executes the code that contains the worm, the worm attempts to propagate itself into other poorly protected procedures or images, traveling along a path known as a worm-hole. The worm seeks to find its way into a procedure that will be run from a privileged account so that the worm can inflict damage to the system security.
Glossary-15
Index
Access control lists A See ACLs Access controls Access for circuits, 9-1 auditing of processes, 6-7 for nodes, 9-2 BYPASS privilege, 4-11 for protected objects, 4-1 class-specific overrides, 4-11 for systems, 9-2 denying, 4-25 Access control strings, 3-14 how the system determines, 4-10 command procedures and, 3-14 object-oriented, 2-6 exposing password in, 3-13 performance impact of auditing, 6-12 protecting information in, 3-14 privileges bypassing ACLs, 4-27 secondary passwords with, 5-23 privileges bypassing protection codes, 4-27 /ACCESS qualifier in Authorize utility, 5-44 subject-oriented, 2-5 Access requirements through ACLs, 4-16 capability object, 4-30 through GRPPRV privilege, 4-11 common event flag clusters, 4-31 through protection codes, 4-7 directories, 4-36 through READALL privilege, 4-11 file-oriented devices, 4-32 through SYSPRV privilege, 4-11 files, 4-36 to deleted file data, 4-40 global sections, 4-41 Access categories, 4-23 1/0 channel, 4-32 See also Protection codes logical name tables, 4-42 Access control non-file-oriented devices, 4-33 See also Access types queues, 4-44 See also Identifier ACEs resource domains, 4-45 ACE order, importance of, 4-18 security class objects, 4-46 assigning file defaults, 4-19 shareable devices, 4-33 bypassing ACLs, 4-27 shared devices, 4-32 bypassing protection codes, 4-27 spooled devices, 4-32 comparing security profiles, 4-1 unshareable devices, 4-33 denying access through an ACL, 4-17 volumes, 4-32 denying a class of users, 5-8 Access types evaluating a user's access request, 4-10, 4-11 abbreviations of, 4-24 Identifier ACEs and, 4-16 ACLs and, 4-19 limiting access to an environment, 4-18 associate, 4-31 limiting d~vice access, 4-17 capability class, 4-30 matrix, 2-5 class-dependency of, 4-24 object security profiles, 4-6 common event flag clusters, 4-31 object-specific considerations, 4-28 control, 4-24, 4-31 through ACLs, 4-16, 4-18 files, 4-36 through protection codes objects in general, 4-27 processing rules, 4-8 create user categories, 4-23 logical name tables, 4-42 using Identifier ACEs, 4-16, 4-19 volumes, 4-47 Access control entries delete See ACE attributes common event flag clusters, 4-31 See ACEs files, 4-36
lndex-1 Access types Accounts (cont'd) delete (cont'd) guest, 5-56 logical name tables, 4-42 initial password, 3-1 queues, 4-44 network, 9-6 volumes, 4-4 7 network objects, 9-10, 9-11 directories, 4-36 open, 3-4 execute password expiration and, 3-12 files, 4-36 password requirements for, 3-4 global sections, 4-41 passwords for multiple, 3-13 files, 4-36 privileged, 5-48 global sections, 4-41 project, 5-16 lock, 4-45 proxies for groups, C-7 logical I/O, 4-32 renewing expired, 3-12 logical name tables, 4-42 restricted, 3-4, 5-51 manage, 4-44 secondary password, 3-3 physical I/O, 4-32 setting duration, 5-45 protection codes and, 4-24 setting up to use project identifiers, 5-17 queues, 4-44 types of, 3-4 read user passwords, 3-2 devices, 4-32 ACE attributes files, 4-36 Default, 4-19 global sections, 4-41 Hidden, 4-20 logical name tables, 4-42 None, 4-17, 4-18 queues, 4-44 Nopropagate, 4-22, 4-27 resource domains, 4-45 Protected, 4-21, 4-23, 4-27 security class, 4-46 ACE options volumes, 4-47 See ACE attributes resource domains, 4-45 ACEs (access control entries) security audit and, 3-19 See also ACE attributes security class, 4-46 See also Identifier ACEs shared devices, 4-32 adding, 4-20 submit, 4-44 Alarm ACEs, 4-29, 6-5 unshared devices, 4-32 Audit ACEs, 4-29, 6-5 volumes, 4-47 creating, 4-16 write Creator ACEs, 4-38, 5-10, 5-17 devices, 4-32 Default Protection ACEs, 4-26, 5-11, 5-16 files, 4-36 examples, 9-21 global section, 4-41 deleting, 4-21 logical name tables, 4-42 deleting protected ACEs, 4-21 resource domains, 4-45 generating audit event messages, 6-2 security class, 4-46 Identifier ACEs, 4-16, 4-19, 10-4 volumes, 4-47 inserting in a list, 4-21 Accounting logs as security tool, 7-3 order of, 4-10, 4-18, 4-21 Accounts replacing, 4-22 See also Captive accounts security auditing, 4-21 See also Proxy accounts sensitive files and, 3-17 See also Restricted accounts Subsystem ACEs, 5-8, 10-3 to 10-5 accessing after password expires, 3-12 types, 4-16 auditing access, 3-16 ACL editor captive, 5-51 displaying ACLs, 4-8 DECNET account, removing, 9-12 modifying ACLs, 4-20 designing secure accounts, 5-1, 5-58 ACLs (access control lists), 4-8, 4-16, 5-16 disabling with DISUSER flag, 5-45 ACE order, 4-10, 4-18, 4-21 disguising identity, 7-4 alarms generated by, D-2 emergency and privileges, 5-48 assigning by default to new files, 4-19 expiration, 3-11, 3-12 auditing in C2 systems, C-7 first login, 3-2 bypassing with special rights, 4-27 group, C-6 copying, 4-22
lndex-2 ACLs (access control lists) (cont'd) ALF (Automatic Login facility) creating, 4-16 See Automatic login facility definition, 4-8 ALLSPOOL privilege, A-2 deleting, 4-21 Alphanumeric UICs, 4-2 deleting ACEs, 4-21 ALTPRI privilege, A-2 deleting obsolete identifiers, 5-6 Analysis of security audit records, 6-1 disadvantages of, 5-4 ANALYZE/AUDIT command, 6-18 displaying, 4-8, 4-20 effect of privileges, 4-11 See also Audit Analysis utility effect on performance, 5-4 qualifier summary, 6-19 granting access, 4-16 Announcement messages, 3-3, 3-5 interaction with protection codes, 4-25 security disadvantages, 5-30 management overview, 5-3 APPEND command, /PROTECTION qualifier, modifying, 4-20 5-16 network file sharing, 9-18 Archive files priority in access evaluation, 4-10 analyzing security-relevant events, 6-16 protection codes and, 4-17 enabling remote, 6-16 queue access rights, 4-44 for security event messages, 6-15 reordering entries, 4-21 Archive flush, 6-28 replacing ACEs, 4-22 ASCII output from Audit Analysis utility, 6-20 restoring file default, 4-26 Associate access, 4-31 restoring the default ACL, 4-22 Attacks, types of system, 7-1 security element of an object, 4-6 Attributes setting default file protection, 5-11 See ACE attributes setting file protection, 5-17 See Identifier attributes system program files, 5-44 Audit ACEs, 4-29 ACNT privilege, A-2 how to use, 6-5 ADD/IDENTIFIER command in Authorize utility, Audit analysis 5-5 See Audit Analysis utility ADD/PROXY command in Authorize utility 9-15 ' ' Audit Analysis utility (ANALYZE/AUDIT), 6-1 9-19 analyzing archive files, 6-16 Alarm ACEs, 4-29 determining criteria of the analysis, 6-21 how to use, 6-5 example, 6-22 Alarm messages, D-1 generating daily reports, 6-17 See also Security alarms interactive commands, 6-21 ACL event, D-2 invoking, 6-18 authorization database modification D-2 overview, 6-17 break-in event, D-3 ' prerequisites, 6-17 INSTALL event, D-5 report formats, 6-19 login, D-5 types of output, 6-20 login failure, D-5 when to ignore events, 6-17 logout, D-6 Audit events network connection, D-6 See Security-auditing events object access event, D-1 Auditing object creation, D-4 See also Audit Analysis Utility object deaccess, D-4 See also Security auditing object deletion, D-4 applications, 7-4 privilege use, D-7 as security feature, 7-4 process control event, D-7 of security events, 6-1 SET AUDIT use, D-8 system parameter modification, D-8 Audit log files time modification, D-8 See Audit Analysis utility volume mount/dismount, D-6 See Security auditing Alarms See Security audit log files See also Security alarms AUDIT privilege, A-3 enabling for security, 3-18
lndex-3 Audit reports Automatic password generation (cont'd) See Security audit reports minimum length, 3-10 Audit server databases, 6-24 Audit server processes 8 changing disk transfer rate, 6-28 Backup operations controlling message flow, 6-26 general recommendations, 5-60 delaying delivery of event messages, 6-25 performed from captive privileged account, disabling, 6-25 5-49 enabling, 6-25 Batch identifiers, 4-3 error handling, 6-28, 6-29 Batch jobs final server action, 6-27 affected by shift restrictions, 3-8 managing, 6-23 authorization, 3-7 memory limitations and, 6-27 password protection and cardreaders, 3-13 pre-extending log files, 6-28 Batch logins, 3-7 tasks performed by, 6-23 Binary output from Audit Analysis utility, 6-20 Audit trails Break-in alarms, D-3 See also Security alarms Break-in attempts, 1-1, 3-8 See also Security auditing auditing, 3-19, 6-3, 6-7 See also Security audit log files counteraction through dual passwords, 5-22 See also Security audit reports detection, 3-9, 5-33 in security models, 2-1 evasion, 3-9, 5-33 protecting, C-7 security audit report and, 6-22 role in security, 2-4 Break-in databases, 5-35 $AUDIT_EVENT system service, reporting Break key and secure servers, 5-36 security-relevant events, 6-9 BUGCHK privilege, A-3 Authority-based systems, 2-6 Buses, default security elements, 4-34 Authorization databases, 2-4 BYPASS privilege access matrix, 2-5, 2-6 description, A-3 adding users, 5-1 effect on control access, 4-27 . auditing, 6-3 overriding access controls, 4-11, 4-27 auditing modifications to, 6-7 contents, 2-1 synchronizing on clustered systems, 8-4 c Authorize utility (AUTHORIZE) C2 environments, C-1 ADD/IDENTIFIER command, 5-5, 5-17 See also TCB ADD/PROXY command, 9-15, 9-19 C2 systems CREATE/PROXY command, 9-14. checklist for generating, C-10 CREATE/RIGHTS command, 5-5 criteria, C-1 /GENERATE_PASSWORD qualifier, 5-20 documentation, C-1 GRANT/IDENTIFIER command, 5-17 effect of site changes on certification, C-3 GRANT/IDENTIFIER qualifier, 5-6 object protection and, C-3 MODIFY/SYSTEM_PASSWORD command, physical security requirements, C-5 5-22 SYSMAN databases, C-3 REMOVE/IDENTIFIER command, 5-6 system parameters, C-9 REMOVE/PROXY command, 9-19 system startup, C-9 SHOW/IDENTIFIER command, 5-7 Capability-based systems, 2-5 SHOW/RIGHTS command, 5-7 Capability objects Autoanswer and backup synchronous dialup, 9-7 as a protected object, 4-10 Automatic login facility (ALF), 5-37 elements of, 4-29 Autologin account as security problem, 5-39 reestablishing profile, 4-30 AUTOLOGIN flag, 5-39 template profile, 4-30 C2 systems and, C-7 types of access, 4-30 Automatic login facility (ALF) files, cluster Captive accounts requirements, 8-4 See also Accounts Automatic password generation, 3-9, 3-10 as target for penetrators, 5-52 disadvantages, 3-10 command procedures, 5-53 example, 3-10 creation of, 5-52
lndex-4 Captive accounts (cont'd) Confidential files, security auditing and, 3-17 Ctrl/Y key sequence and, 5-52 CONNECT command, /LOGOUT qualifier, 3-20 definition, 3-4 Connections, auditing of, 6-7 disabling mail and notification of delivery, Consoles, enabling passwords for, 5-28 5-31 Console terminals example of production account, 5-50 C2 system requirements, C-5 locked password and, 5-53 C2 systems and, C-9 privileged, 5-49 HSC and C2 system requirements, C-6 Card readers, default security elements, 4-34 Control access $CHECK_ACCESS system service, security acquiring, 4-10, 4-24, 4-27 auditing and, 6-9 common event flag clusters, 4-31 $CHECK_PRIVILEGE system service, reporting devices, 4-32 privilege use, 6-9 files, 4-36 $CHKPRO system service global sections, 4-41 role in access control, 4-10 limitations, 4-28 security auditing and, 6-9 logical name tables, 4-43 Circuits queues, 4-44 access control, 9-1 resource domains, 4-45 database guidelines, 9-7 security class, 4-46 verification, 9-7 volumes, 4-47 /CLITABLES qualifier, 5-44, 5-53 COPY command, /PROTECTION qualifier, 5-16 Cluster environments Create access security considerations logical name tables, 4-42 building single security domain, 8-2 volumes, 4-4 7 C2 system restrictions, C-9 CREATE/PROXY command in Authorize utility, managing audit log file, 8-5 9-14 protected object databases, 8-6 CREATE/RIGHTS command in Authorize utility, protected objects, 8-6 5-5 security implementation, 8-7 Creator ACEs, 4-38 synchronizing authorization data, 8-4 example, 5-17 SYSMAN requirements, 8-7 with resource identifiers, 5-10 system file recommendations, 8-3 Ctrl/B key sequence, 3-14 system file requirements, 8-2 Ctrl/Y key sequence and restricted accounts, 5-55 Cluster managers and security administrators, 8-1 CLUSTER_AUTHORIZE.DAT files, 8-7 D CMEXEC privilege, A-4 Databases CMKRNL privilege, A-5 authorization, 2-4, 2-5 Command mode for Audit Analysis utility, synchronizing on clustered systems, 8-4 manipulating the display, 6-21 DECnet nodes and circuits, 9-7 Command procedures, access control strings in, protected objects, 8-6 3-14 rights, 5-7 Commands, usage restrictions, 5-44 DCL tables, modifications for security, 5-44 Common event flag clusters DECnet as protected objects, 4-10 C2 system restrictions, C-9 events audited, 4-31 cluster nodes and, 8-8 privilege requirements, 4-31 Decryption, 5-42 reestablishing security profile, 4-31 DEFAULT ACCESS parameter for NCP security elements of, 4-30 commands, 9-2 system modifications of templates, 4-31 Default attribute for ACEs, 4-19 template profile, 4-31 Default network accounts and reference monitors, types of access, 4-31 9-4 Communications devices Default ownership C2 system requirements, C-6 for directories, 5-18 default security elements, 4-34 for files, 5-15 Compilers, restricting use with ACLs, 5-40 for protected objects, 5-11, 5-18
lndex-5 Default protection DIRECTORY command, /SECURITY qualifier, directories, 4-38 4-40 for processes, 5-11, 5-15 Disconnected job messages, 3-6 management, 5-11 Disconnected processes Default Protection ACEs, 4-26, 5-16 See Virtual terminals generating default file protection, 4-37 DISFORCE_PWD_CHANGE flag, 5-24 Delete access Disk quotas common event flag clusters, 4-31 as restriction for users, 5-43 files, 4-36 charging to identifiers, 5-10 granting through protection codes, 4-24 Disks logical name tables, 4-42 accessing deleted data, 4-40 queues changing message transfer rate, 6-28 through ACLs, 4-44 default security elements, 4-34 through protection codes, 4-44 erase-on-allocate, 4-39 volumes, 4-47 erasing, 4-39, 5-62 DELETE command, /ERASE qualifier, 4-39 erasure patterns, 4-39 DETACH privilege, A-6 highwater marking, 4-39 Devices managing security profiles, 4-34 access requirements, 4-32 protecting after file deletion, 4-38 as protected objects, 4-10 volume protection, 4-47 controlling access through ACLs, 4-17 Disk scavenging default security elements, 4-34 discouraging, 5-62 events audited, 4-35 preventing, 4-38, 4-39 modifying security profiles of, 4-34 Disk space privilege requirements, 4-35 charging to identifier, 5-17 profile storage, 4-35 requirements for security audit log file, 6-28 protecting BACKUP save sets, 5-61 usage and charging, 5-10 restricting access to, 5-42 Disk volumes reusing in C2 systems, C-8 controlling access, 4-47 security elements of, 4-31 restrictions, 5-43 spooled, access requirements, 4-32 DISMOUNT command, alarms, D-6 template security profiles, 4-33 DOWNGRADE privilege, A-6 terminal configuration, 5-60 DSE (data security erase), 5-62, 5-63 DIAGNOSE privilege, A-6 tailoring, 5-63 Dialup identifiers, 4-3 Dual passwords, 5-22 Dialup lines Dynamic attribute for identifiers, 5-8 backup synchronous and autoanswer, 9-7 connection security, 9-1 controlling access, 3-2 E using in a public area, 3-20 Echoing, passwords and, 3-3 Dialup logins, 3-5 EDIT/ACL command breaking connections, 3-20 See ACL editor, controlling retries, 5-30, 5-31 Editing ACLs, 4-20 to 4-23 failures, 3-8 See also ACL editor retries, 3-8 Directories Editors access control through ACLs, 4-18 See ACL editor access requirements, 4-36 Emergency accounts and privileges, 5-48 assigning a security profile, 4-38 Encryption, 5-42 controlling access to files, 4-19, 5-12 Environmental factors in security, 1-3 creating, 4-37 Environmental identifiers, 5-7 conditionalizing general identifiers, 5-8 events audited, 4-38 ownership example, 4-3, 4-4, 4-18 by resource identifier, 5-17 Identifier ACEs and, 4-18 changing access to files, 5-12 Erase-on-allocate, 4-39 setting default, 5-11 Erase-on-delete, 4-39, 5-62 setting default file protection, 4-19, 5-11 C2 systems and, C-8
lndex-6 Erasing disks, 5-62 Files Erasure patterns, 4-39, 5-62 creating (cont'd) Evasive actions requirements for, 4-37 duration, 5-35 default protection, 4-26 invoked as counteraction for break-ins, 5-33 encrypting, 5-42 Event classes erasing data from disks, 4-39 See Security-auditing events events audited, 4-38 Event tolerance, and security levels, 1-2 exceptions to the ownership rule, 4-7 Execute access managing directory defaults, 5-18 files, 4-36 naming rules, 4-35 global sections, 4-41 optimizing security, 4-40 granting through protection codes, 4-24 owned by resource identifier, 4-37, 4-38, 5-17 Expiration ownership rules, 4-37 of account, 3-12 protecting data after deletion, 4-38 of password, 3-12, 5-21 protecting mail, 4-40 of secondary password, 3-12 protection required for proxy access, 3-16 password system messages, 3-11, 3-12 restoring default security elements, 4-22 /EXPIRATION qualifier, 5-45 restoring default security profiles, 4-26 Expired passwords, system message, 3-11 security auditing and, 3-17, 4-38 EXQUOTA privilege, A-6 security elements of, 4-35 External nodes and default access rights, 9-7 setting default protection and ownership, 5-11 sharing and exchanging in network environment, 9-18, 9-22 F sharing considerations for a cluster system, F$MODE lexical function, 3-4 8-5 Facility identifiers, 4-4 transfers with MAIL, 9-18 /FLAGS=CAPTIVE qualifier, 5-52 Failure /FLAGS=DISIMAGE qualifier, 5-57 See Login failures /FLAGS=DISMAIL qualifier, 5-31 FAL (file access listener) recommendations, 9-9 /FLAGS=DISNEWMAIL qualifier, 5-30 File access /FLAGS=DISPWDDIC qualifier, 5-25 See File protection /FLAGS=DISPWDHIS qualifier, 5-25 File browsers, 3-18, 7-4, 7-6 /FLAGS=DISRECONNECT qualifier, 5-31 File protection, 4-6, 4-35, 5-11 /FLAGS=DISREPORT qualifier, 5-30 See also Files /FLAGS=DISUSER qualifier, 5-29 auditing, 7-4 /FLAGS=DISWELCOME qualifier, 5-30 C2 systems, C-4 /FLAGS=GENPWD qualifier, 5-23, 5-27 DCL commands for, 5-40 /FLAGS=LOCKPWD qualifier, 5-27 setting default ACLs, 4-19 /FLAGS=PWD_EXPIRED qualifier, 5-23 Files /FLAGS=RESTRICTED qualifier, 5-55 See also File protection Flushing messages to disk, 6-28 See also Security auditing Flush interval, 6-28 access control through ACLs, 4-18 Foreign volumes, access requirements, 4-32 accessing allocated disk blocks, 4-40 Format accessing by file identifier, 4-36 Identifier ACE, 4-16 access requirements, 4-36 protection code, 4-23 adding ACEs for security auditing, 3-17, 4-29 rights identifiers, 4-3 applying an alarm to, 3-17 security auditing ACE, 6-6 as protected objects, 4-10 UIC (user identification code), 4-2 assigning protection codes, 4-37 FYDRIVER, C2 systems and, C-10 assigning security profiles, 4-37, 5-12 auditing access, 3-16, 3-17, 4-28 changing security profiles, 4-38 G confidential, protecting, 3-18 General identifiers, 4-16 controlling access with Identifier ACEs, 4-16 design considerations, 5-3 copying from remote account, 3-16 example, 4-4, 4-18 creating format, 4-3 dependency on directory ownership, 5-12
lndex-7 Generated passwords, 3-10 Holders of a rights identifier disadvantages, 3-10 associating with identifier, 5-6 example, 3-10 displaying records, 5-7 initial passwords, 5-20 granting access to, 4-16 length, 5-24 removing from rights database, 5-6 minimum length, 3-10 HSC console terminals requiring, 5-23, 5-26 C2 system requirements, C-6 Global sections C2 system restrictions, C-7 default protection, C-3 events audited, 4-42 group, 4-10 privilege requirements, 4-42 I/O channels, access requirements, 4-32 reestablishing security profile, 4-42 I/O operations, access requirements for devices, restricting access, 4-41 4-32 security elements of, 4-41 Identifier ACEs, 4-19 system, 4-10 See also Identifier attributes template profiles, 4-41 ACE order, 4-18 types of access, 4-41 adding to an ACL, 4-20 Group accounts, C2 systems and, C-6 conditionalizing, 4-18 Group global sections conditionalizing access, 4-18 See Global sections creating, 4-16 Group numbers Default attribute, 4-19 in UICs, 4-2 definition, 4-16 reserved UICs, 4-2 denying access, 4-1 7 uniqueness requirement for clustered systems, format, 4-16 8-5 interpreting, 4-16 Group numbers and passwords, 8-7 protected subsystems and, 10-4 setting up for cluster, 8-7 using general identifiers, 4-16 GROUP privilege, A-7 Identifier attributes Groups description of, 5-8 design of, 5-7 Dynamic, 5-8 guidelines for organization, 5-2 Holder Hidden, 5-9 UIC design, 5-2 Name Hidden, 5-9 Group UIC names, 4-2 No Access, 5-9 Group users (security category), 4-7, 4-23 Resource, 5-10 GRPNAM privilege, 4-43, A-7, C-5 Subsystem, 5-11 GRPPRV privilege, A-7 Identifiers, 4-3 description, A-7 See also Identifier attributes effect on protection mechanisms, 4-27 adding to rights database, 5-5 giving rights of system user, 4-11, 4-23 as directory owners, 5-17 granting control access, 4-27 as file owners, 4-36, 4-37 trusted users and, C-5 assigning to users, 5-6 Guest accounts auditing use of, 6-7 as limited-access accounts, 5-56 creating, 4-17 C2 systems and, C-6 customizing, 5-7 displaying process, 4-4 environmental, 4-3, 4-4, 5-7 H facility, 4-4 Hardcopy output, disposal of, 3-20 format, 4-3 Hardcopy terminals, logout considerations, 3-20 general, 4-3, 4-4, 4-16 Hidden attribute, 4-20 in ACEs, 4-16 Highwater marking, 4-39, 5-63 of a process, 4-1 C2 systems and, C-8 removing, 5-6 performance and, 5-63 resource, directory ownership and, 5-12 Holder Hidden attribute, 5-9 security audit reports and, 4-5 to access protected subsystems, 10-6 types, 4-3 UIC, 4-3, 4-4
lndex-8 Identifiers (cont'd) Logging uniqueness requirement access to protected objects, 4-28 for clustered systems, 8-5 security audit events, 6-2, 6-13 Images, installing terminal session, 5-58 security ramifications, 5-47, 10-1 Logging out subsystem images, 10-3 breaking dialup connection, 3-20 IMPORT privilege, A-8 deciding when it is necessary, 3-19 INITIALIZE command, /ERASE qualifier, 4-39, from disconnected processes, 3-20 5-63 reasons for, 3-19 Install utility (INSTALL) security considerations, 3-19 alarms, D-5 Logical I/O access, 4-32 auditing changes made through, 6-7 Logical name tables security ramifications, 5-47, 10-1 as protected objects, 4-10 Interactive identifiers, 4-3 events audited, 4-43 Interactive logins, 3-4 privilege requirements, 4-43 classes, 3-5 reestablishing security profile, 4-43 dialup, 3-5, 3-8 security elements of, 4-42 local, 3-5 template profiles, 4-43 remote, 3-5 types of access, 4-42 system message, 3-6 Login alarms, D-5 Interactive mode processes, 3-4 enabling, 6-7 Login classes, 3-5 J See also Logins batch, 3-7 Job controllers dialup, 3-5 affected by shift restrictions, 3-8 interactive, 3-5 enforcing work time restrictions, 5-43 local, 3-5 Job terminations imposed by shift restrictions, network, 3-7 3-8 noninteractive, 3-7 Journalflush, 6-28 remote, 3-5 restrictions on, 3-8 L Login command procedures Last login messages, 3-17 for restricted accounts, 5-52, 5-53 disabling, 5-30 proper protection for, 5-42 Levels of security, definition, 1-2 Login failures /LGICMD qualifier and captive accounts, 5-52 alarms, D-5 LGI_BRK_DISUSER system parameter, 5-35 auditing, 6-7 LGI_BRK_LIM system parameter, 5-33 break-in evasion and, 3-9 LGI_BRK_TERM system parameter, 5-34 causes of, 3-7 LGI_BRK_TMO system parameter, 5-34 counting for break-in detection, 5-34 LGI_CALLOUTS system parameter, C-9 dialup logins, 3-8 LGI_HID_TIM system parameter, 5-35 expired accounts, 3-12 LGI_RETRY_LIM system parameter, 5-31 login class restrictions and, 3-8 LGI_RETRY_TMO system parameter, 5-31 messages, 3-6, 3-17 Lifetime of accounts, 3-12 password grabber programs, 3-13, 3-14 Lifetime of passwords, 3-9, 3-11 retries and, 3-8 LINK command, /NOTRACEBACK qualifier, 5-47 security audit report and, 6-22 Listener devices shift restrictions, 3-8 capturing audit event messages, 6-16 system passwords and, 3-8 disabling, 6-16 Login messages, 3-5 example of programs for, 6-17 announcement, 3-5 LOAD.:...PWD_POLICY system parameter, C-9 controlling, 5-30, 5-31 Local identifiers, 4-3 disconnected job, 3-6 Lock access, 4-45 expired password, 3-11, 3-12 LOCKPWD flag, 3-4 last successful interactive login, 3-6 last successful noninteractive login, 3-6 new mail, 3-6 number of login failures, 3-6
lndex-9 Login messages (cont'd) Mail utility (MAIL) suppressing, 3-6, 3-17 controlling notification messages, 5-30 welcome, 3-6 transferring text files, 9-18 Login programs, authentication by secure terminal Maintenance tasks for secure systems, 5-64 server, 3-13 Manage access, 4-44 Logins Master file directory See also Proxy logins See MFD auditing, 6-7 MAXSYSGROUP system parameter, 4-23, C-9 batch, 3-7 Media initialization changing password, 3-2 access requirements, 4-47 changing password during, 3-11 restricting with ACLs, 5-40 controlling, 3-3 Member numbers in UICs, 4-2 default process protection and, 4-38 Member UIC names, 4-2 dialup, 3-5 Memory consumption by ACLs, 5-4 controlling number of attempts, 5-31 Messages supplying password, 3-8 announcement, 3-5 disabled auditing, 6-2 by break-in evasion, 3-9 auditing security-relevant events, 3-18 by shift restriction, 3-8 disabling last login, 5-30 expired accounts, 3-12 last successful interactive login, 3-6 flags, 5-24 login, 3-5 interactive, 3-4 login failure, 3-17 classes of, 3-5 suppressing, 3-6, 5-30 most recent, 3-6 suppressing last login, 3-17 local, 3-5 welcome, 3-6 monitoring last, 3-17 MFD (master file directory), 4-38 network, 3-7 MIRROR objects, 9-9 noninteractive, 3-4 Modems, C2 system requirements, C-5 classes of, 3-7 MODIFY/SYSTEM_PASSWORD command in most recent, 3-6 Authorize utility, 5-22 permitted time periods, 3-8 MOM (maintenance operations module) objects, remote, 3-5 9-9 restricting by function, 5-32 MOUNT command, alarms, D-6 restricting with system passwords, 5-21 Mounting volumes secure terminal server, 5-36 access requirements, 4-47 security implications, 3-2 and security audit, 3-19 simplifying for user with Automatic login with protected subsystems, 10-5 facility (ALF), 5-39 MOUNT privilege, A-9 time out, 3-4 Login sequences, 5-32 Logout alarms, D-6 N Logout auditing, 6-7 Name Hidden attribute, 5-9 LOGOUT command, 3-20 Naming rules /HANGUP qualifier, 3-20 capability objects, 4-30 LOG_IO privilege, 4-35, A-8 common event flag clusters, 4-30 devices, 4-32 M files, 4-35 global sections, 4-41 Mailboxes logical name tables, 4-42 default protection, C-3 queues, 4-44 default security elements, 4-34 resource domains, 4-45 for audit event messages, 6-13 security class, 4-46 modifying security profiles, 4-34 NCP (Network Control Program utility) privilege requirements, 4-35 auditing database modifications, 6-7 Mail files, recommended protection for, 4-40 controlling proxy logins, 9-16 MAIL objects, recommended access, 9-9
lndex-10 NETMBX privilege, A-9 Object ownership (cont'd) NETPROXY.DAT files managing defaults, 5-11, 5-15 auditing, 6-3 qualifying for, 4-7 automatic maintenance, 9-16 reassigning, 4-7 normal protection, 5-29 restoring file default, 4-26 wildcards and, 9-19 zero UICs in protection checks, 4-11 Network access control strings, 3-13, 3-14, 5-23 Object permanence Network accounts capability object, 4-30 DECNET account, removing, 9-12 common event flag cluster, 4-31 guidelines for establishment, 9-6 devices, 4-35 network objects, 9-10, 9-11 global sections, 4-42 world access and, 9-5 logical name tables, 4-43 Network identifiers, 4-3 queues, 4-45 Network logins, 3-7 resource domains, 4-46 Network proxy authorization files security class object, 4-47 volumes, 4-48 See NETPROXY.DAT files Networks Object protection access control, 9-1 See Objects country usage restrictions, 9-7 See Protection password guidelines, 9-7 Objects, 4-1 protected communications security problems, See also Files 9-5 See also Protection Network security, 3-14, 9-1 access arranged by, 2-6 C2 systems and, C-7 access to, comparing security profiles, 4-1 events audited, 9-6 ACLs and, 4-8 limitations, 9-1 adding ACEs for security auditing, 4-29 network object configuration, 9-10, 9-11 alarms for creation, D-4 NISCS_CONV_BOOT system parameter, C-9 alarms for deaccess, D-4 NML (network management listener) objects, 9-9 alarms for deletion, D-4 No Access attribute, 5-9 auditing access, 4-28, 6-7 Node databases, guidelines, 9-7 C2 systems and, C-3 Nodes capability class, 4-29 access control, 9-2 changing security profile, 4-9 external, and default access rights, 9-7 characteristics of protected objects, 4-6 None attribute (ACEs), 4-17, 4-18 class descriptions, 4-29 Non-file-oriented devices, access requirements, classes of, 4-9 4-33 classes protected by operating system, 4-9, Noninteractive logins, 3-4, 3-7 4-29 batch, 3-7 class-specific access overrides, 4-28 classes, 3-7 class specification, 4-9 network, 3-7 controlling access with Identifier ACEs, 4-16, Nopropagate attribute, 4-22, 4-27, 4-38 4-17 Numeric UICs, 4-2 displaying default protection and ownership, 5-18 0 displaying security profiles, 4-8 global sections, 4-41 Object classes granting access through protection codes, 4-23 See also Objects in security models, 2-1 descriptions of, 4-29 kinds of events audited, 4-28 security attributes of, 4-9 logical name tables, 4-42 Object ownership managing default protection and ownership, assigning during file creation, 5-12 5-11 by resource identifiers, 4-36 modifying class templates, 5-20 changing, 4-9 protection codes, 4-7, 4-23 exceptions to the rule, 4-7 queues, 4-43 files, 4-37 reassigning ownership, 4-7 management of directory defaults, 5-18 resource domains, 4-45
lndex-11 Objects (cont'd) Passwords role in security models, 2-3 See also Password management rules for determining access, 4-10 See also Password protection security class, 4-46 acceptable, 3-2 security elements source, 4-6 automatically generated, 3-9, 3-10 security management overview, 4-29 chances to supply during dialups, 3-8 security profiles, 4-6, 4-10 changing, 3-9 volumes, 4-47 at login, 3-11 OPCOM (Operator Communication Manager), expired, 3-12 security auditing and, 6-25 frequency guidelines, 3-13 Open accounts, 3-4 /NEW_PASSWORD qualifier, 3-11 C2 systems and, C-6 secondary, 3-11 captive accounts and, 5-53 cluster membership management, 8-7 captive recommendation, 5-29 console, C2 system requirements, C-5 Open files and ACL consumption of memory, 5-4 dialup retries, 3-8 Operator Communication Manager dual, 3-2, 5-20 See OPCOM encoding, 2-3 OPER privilege, A-9 expiration, 3-11, 3-12 overriding access controls, 4-11 failure to change, 3-12 queue access, 4-28 first, 3-1 queue management, 4-44 forced change, 3-12 Owner format, 3-1 See also Object ownership generated category of user access, 4-23 disadvantages, 3-10 changing object ownership, 4-7 minimum length, 3-10 security element of an object, 4-6 guessing, 3-1 history list, 3-2 p incorrect, 3-6 initial, 3-1, 5-20 Paper shredders, 3-20 length, 3-1 Password generators lifetime of, 3-9, 3-11 obtaining initial password, 5-20 locked, 3-4 when to require, 5-27 advantage, 5-27 Password grabber programs, 3-13, 3-14, 5-36 for captive accounts, 5-53 catching with auditing ACEs, 6-6 minimum length, 3-2, 3-9, 5-24 Password management multiple systems and, 3-13 eliminating for networks, 9-18 new, 3-11 encryption algorithms, 5-27 null as choice for captive account, 5-53 forced change, 5-24 open accounts and, 3-4 network guidelines, 9-7 password grabber programs, 3-13 password length, 5-24 preexpiring, 5-21 password restrictions, 5-23 primary, 3-2, 3-4, 5-20 preexpiring passwords, 5-21 reason for changing, 3-17, 3-19 requiring generated passwords, 5-20 restrictions, 3-2 screening reuse, 3-1 against dictionary, 5-25 risky, 3-1 against history list, 5-26 screening with site-specific filter, 5-26 setting up secondary, 3-2, 5-22 console passwords, 5-28 changing, 3-11 expiration time, 5-23 changing expired, 3-12 primary passwords, 5-20 entering, 3-4 secondary passwords, 5-22 secure choices for, 3-1 system passwords, 5-21 secure terminal servers and, 3-13 Password protection, 3-13, 5-29 sharing, 3-13, 9-18 avoiding detection, 3-10, 5-35, 7-6 system, 3-2, 3-3 dialup retries, 3-8 system dictionary of, 3-2 proxy logins, 3-15 types, 3-2 uniqueness for each account, 3-13
lndex-12 Passwords (cont'd) Privileges (cont'd) user, 2-3, 3-2 disabling, 4-5 user guidelines, 3-1 DOWNGRADE, A-6 verifying change of, 3-9 enabling through SETPRV, 4-5 when account is created, 3-2 EXQUOTA, A-6 when to change, 3-2 file sharing and, 9-18 Performance GROUP, A-7 ACL length and, 5-4 Group category, 5-46, C-5 highwater marking and, 5-63 GRPNAM, A-7, C-5 security-auditing impact, 6-12 GRPPRV, 4-11, 4-23, 4-27, C-5 PFMGBL privilege, 4-42 IMPORT, A-8 PFNMAP privilege, 4-42, A-12 influence on object access, 4-10 PHONE objects, 9-9 LOG_IO, A-8 Physical I/O access, 4-32 MOUNT, A-9 Physical security, 1-3 NETMBX, A-9 C2 systems and, C-5 Normal category, 5-46, C-5 encrypting files, 5-42 Objects category, 5-46, C-4 restricting system access, 5-42 OPER, 4-28, A-9 violation indicators, 7-2 PFNMAP, A-12 when logging out, 3-19 PHY_IO, A-12 PHY_IO privilege, 4-35, A-12 PRMCEB, A-13 /PRCLM qualifier in AUTHORIZE, 5-53 PRMGBL, A-13 Primary passwords, 3-2 PRMMBX, A-14 /PRIMEDAYS qualifier, example, 5-43 process, A-1 Printers PSWAPM, A-14 C2 systems and, C-8 READALL, 4-11, 4-27, A-14 default security elements, 4-34 recommendations for different users, 5-48 Privileged accounts, 5-48 related to group UIC, 5-2 Privilege requirements reporting use with $CHECK_PRIVILEGE, 6-9 common event flag clusters, 4-31 requirements for security administrators, 5-1 devices, 4-35 SECURITY, A-15 global sections, 4-42 SET PROCESS/PRIVILEGES, 4-5 logical name tables, 4-43 SETPRV, A-15 queues, 4-44 SHARE, A-15 resource domains, 4-45 SHMEM, A-16 volumes, 4-48 storage in UAF record, 5-46 Privileges summary of, 5-46, A-2 ACNT, A-2 SYSGBL, A-16 affecting object access, 4-11 SYSLCK, A-16 All category, 5-46, C-4 SYSNAM, A-16 ALLSPOOL, A-2 SYSPRV, 4-11 ALTPRI, A-2 control access through, 4-27 AUDIT, A-3 effect on protection mechanisms, 4-27 auditing use of, 3-19, 6-7 giving rights of system user, 4-23 authorized process, 4-5, 5-46 tasks requiring, A-17 BUGCHK, A-3 System category, 5-46 BYPASS, 4-11,4-27,A-3 TMPMBX, A-18 bypassing ACLs, 4-27 trusted users and, C-4 bypassing protection codes, 4-27 UAF records and, 4-5 captive accounts and, 5-49 untrusted users and, C-5 categories of, 5-45, 5-46 UPGRADE, A-18 CMEXEC, A-4 VOLPRO, A-18 CMKRNL, A-5 WORLD, A-19 default process, 4-5, 5-46 PRMCEB privilege, 4-31, A-13 definition, 4-5 PRMGBL privilege, A-13 DETACH, A-6 PRMMBX privilege, 4-35, A-14 Devour category, 5-46, C-5 DIAGNOSE, A-6
lndex-13 Probers, how to catch, 5-33, 7-2, 7-4 Protection Probing, as security problem, 1-1 See also Security profiles Processes ACL-based, 5-16 access rights of, 4-1 capability, 4-30 activities permitted by privileges, 5-45 command procedures and, 5-42 adding to exclusion list, 6-27 common event flag clusters, 4-31 auditing of, 6-6, 6-7 deleted data, 4-38, 4-39 auditing system services controlling, 6-7 devices, 4-33 audit server, 6-23 global sections, 4-41 connecting to, restrictions, 3-6 logical name tables, 4-43 creating with different UICs, 4-3 managing defaults, 5-11, 5-15 default protection for, 4-38 objects, 4-6 disconnected, 3-6 queues, 4-44 displaying, 3-20 resource domains, 4-45 logging out, 3-20 security class, 4-46 displaying default protection, 4-38 through protected subsystems, 10-1 displaying process rights identifiers, 4-4 UIC-based protection codes, 4-7 interactive mode, 3-4 volumes, 4-47 logging out of current, 3-20 Protection checking, 4-10 modifying the rights list, 5-7 evaluating an object access request, 4-11 privileges exception with zero UICs, 4-11 enabling, 4-5 influenced by ownership, 5-12 reconnecting to, restrictions, 3-6 Protection codes, B-1 security profiles of, 4-1 access specification, 4-24 suspending, 6-27 access types, 4-24 UIC identifiers, 4-3 assigning during file creation, 5-12 Process exclusion list, 6-27 bypassing with special rights, 4-27 Process privileges changing, 4-25 See Privileges default file protection, 4-26 definition, 2-4, 4-7 See Processes denying all access, 4-25 Profiles effect of privileges, 4-11 See Security profiles evaluation sequence, 4-8 Project accounts, 5-17 I format, 4-23 as protected subsystems, 10-2 granting control access, 4-24 setting up, 5-17 Identifier ACEs and, 4-17 Prompts, passwords and, 3-3 interaction with ACLs, 4-26 Propagating protection, example, 9-21 interpreting, 4-7 Protected attribute, 4-23, 4-27 multiple user categories and, 4-25 deleting ACEs with, 4-21 null access specification, 4-24 Protected object databases, 8-6 priority in access evaluation, 4-11 Protected objects processing, 4-24 See Objects queue access rights, 4-44 Protected subsystems reading, 4-24 advantages of, 10-1 restoring file default, 4-26 applications for, 10-2 security element of an object, 4-6 constructing, 10-4 sequence of checking categories, 4-24 description of, 10-2, 10-6 specifying default file protection, 5-15 design requirements, 10-3 user categories, 4-7 enabling, 10-5 Proxy access, 9-17 example, 10-6 Proxy accounts, 3-15 file protection, 10-8, 10-9 as captive account, 9-15 mounting volumes with, 10-5 as restricted account, 5-57 printer protection, 10-10 C2 systems and, C-7 Subsystem ACEs, 10-4 default, 3-16 system management requirements, 10-3 example, 9-15, 9-20 user access, 10-6 general-access, 3-16 maximum number allowed, 3-15
lndex-14 Proxy accounts (cont'd) Remote identifiers, 4-3 multiple-user, 3-16 Remote logins, 3-5 naming, 3-16 logging out, 3-19 recommended restrictions, 9-14 system passwords and, 5-21 selecting from multiple, 3-16 REMOVE/IDENTIFIER command in Authorize single-user, 3-16 utility, 5-6 Proxy logins, 3-7, 3-15 REMOVE/PROXY command in Authorize utility, circuit verification and, 9-7 9-19 establishment and management, 9-13, 9-18 Reserved UIC group numbers, 4-2 security benefits, 3-15 Resource attribute, 5-10, 5-17 PSWAPM privilege, A-14 Resource domains PURGE command, /ERASE qualifier, 4-39 definition, 4-10 /PWDLIFETIME qualifier, 5-23 events audited, 4-45 /PWDMINIMUM qualifier, 5-25 privilege requirements, 4-45 profile storage, 4-46 Q security elements of, 4-45 template profile, 4-45 Queues types of access, 4-45 access granted by OPER privilege, 4-28 Resource identifiers, 5-17 ACL access rights, 4-44 as file owners, 4-37, 4-38 as protected objects, 4-10 Resource monitoring, 6-29 events audited, 4-44 disabling, 6-29 privilege requirements, 4-44 Restricted accounts, 3-4 profile storage, 4-45 danger of process spawning, 5-53 protection code access rights, 4-44 for network environment, 9-7 security elements of, 4-43 setting up, 5-51 template profiles, 4-44 Restrictions types of access, 4-44 See Security restrictions Retries, controlling number for dialups, 5-31 R Rights database Read access See also RIGHTSLIST.DAT files devices, 4-32 adding identifiers, 5-5 files, 4-36 assigning identifiers with users, 5-6 global sections, 4-41 creating and maintaining, 5-4 granting through ACLs, 4-19 displaying, 5-7 granting through protection codes, 4-24 removing identifiers and holders, 5-6 logical name tables, 4-42 Rights identifiers queues See Identifiers through ACLs, 4-44 Rights list, access arranged by capability, 2-6 through protection codes, 4-44 RIGHTSLIST.DAT files resource domains, 4-45 auditing, 6-3 security class, 4-46 creating and maintaining, 5-7 volumes, 4-47 how UICs are stored, 4-3 READALL privilege, 4-11, 4-27, A-14 Rights of users Recall buffers, 3-14 See also Identifiers RECALL command, /ERASE qualifier, 3-14 displaying, 5-7 Reconnection to processes, 5-31 RMS_FILEPROT system parameter, 4-38, 5-11, Records displaying holder of a rights identifier, 5-15, C-9 5-7 Reference monitors applying to networks, 9-2, 9-4 s concept in security, 2-1, 2-5 Save set (BACKUP), protection of, 5-61 implementation, 2-2 Screen clearing, 3-20, C-8 requirements on, 2-1 SECAUDIT.COM Remote diagnostics, C2 system requirements, C-5 See Audit Analysis utility
lndex-15 Secondary passwords, 3-2 Security auditing (cont'd) See also Passwords enabling auditing, 6-25 advantages, 5-22 enabling event classes, 6-3 changing, 3-11 enabling events, 6-2 changing expired, 3-12 error handling, 6-28, 6-29 disadvantages, 3-3 excluding processes from suspension, 6-27 entering, 3-4 files, 3-17, 4-38 login expiration, 3-4 global sections, 4-42 managing, 5-22 granularity of events, 4-28 minimum length, 3-4 high security needs, 6-11 Secure terminal servers, 3-13, 5-36 listener devices, 6-16 password protection and, 3-13 logical name tables, 4-43 SECURITY.AUDIT$JOURNAL files, 6-18 low security needs, 6-10 Security administrators managing the audit server, 6-23 cluster managers and, 8-1 memory limitations and, 6-27 goals of, 1-1 messages, 3-18 personal accounts, 5-1 moderate security needs, 6-10 privilege requirements, 5-1 object class enabled, 4-28 system passwords and, 3-3 overview, 6-1 Security alarms, 3-18 performance impact, 6-12 audit log file, C-7 queues, 4-44 disabling on system consoles, 6-15 reporting object access, 4-28 events to enable as, 6-3, 6-12 reporting object use, 4-5 events triggering, 3-19 resource domains, 4-45 example of enabling events, 6-10 Security class objects, 4-47 sample messages, 6-1, D-1 sending event messages to archive files 6-15, 6-16 ' Security archive files, losing the remote link to 6-29 ' sending event messages to mailboxes, 6-16 Security attacks, forms of, 1-1, 7-1 sending event messages to operator terminals Security audit event messages 6-15 ' changing disk transfer rate, 6-28 synchronizing cluster time, 6-28 controlling delivery to server, 6-26 volumes, 4-48 delaying delivery at startup, 6-25 Security-auditing ACEs when to ignore, 6-17 See also Alarm ACEs Security auditing, 3-16, 7-4 See also Audit ACEs See also Audit server processes position in ACL, 4-20 Security-auditing events, 3-19 See also Security-auditing events based on security needs, 6-10 See also Security audit log files classes of, 6-7 account and file access, 3-16 default classes, 6-1, 6-3, 6-10 adding ACEs to files, 3-17 disabling all classes, 6-11 analyzing audit log files, 6-17 displaying, 6-3 archive files, 6-16 enabling all classes, 6-11 assessing site requirements, 6-10 enabling as alarms, 6-10 audit server databases, 6-24 enabling as audits, 6-10 C2 system restrictions, C-7 example, 6-3 capability object, 4-30 network, 9-6 cluster considerations, 8-5 reporting, 6-3, 6-12, 6-13 common event flag clusters, 4-31 sending to audit log files, 6-13 controlling event messages, 6-26 sending to listener mailboxes, 6-16 default auditing events, 2-4 sending to operator terminals, 6-15 default characteristics, 6-24 sending to remote archive files, 6-15 devices, 4-35 suppressing privilege audits, 6-8 directories, 4-38 suppressing process control audits 6-8 disabling auditing, 6-25 system services for, 6-9 ' disabling events, 6-3 Security audit log files, 2-4, 3-18 disabling resource monitoring, 6-29 See also Audit Analysis utility effective use, 6-1 7 See also Security auditing
lndex-16 Security audit log files (cont'd) Security features (cont'd) See also Security audit reports password requirements, 3-4 advantages of, 6-12 password restrictions, 3-2 allocating disk space, 6-28 passwords, 5-20 to 5-29 C2 systems and, C-7 protected subsystems, 10-1 changing location, 6-14 proxy logins, 3-15 changing message transfer rate, 6-28 secondary passwords, 3-4, 3-11 characteristics, 6-13 secure terminal servers, 3-13, 5-36 creating, 6-13 security alarms, 3-18 description, 6-13 shift restrictions, 3-8 events to report, 6-12 system password, 3-3 interactive analysis, 6-21 system passwords, 3-8 maintaining, 6-13 Security kernel, definition, 2-2 preextending, 6-29 Security levels, 1-2, 1-3 procedures, 6-13 event monitoring and, 6-10 selecting records from, 6-20 high, 1-2, 3-17 Security audit reports, 6-17, 6-18 low, 1-2, 3-17 analyzing suspicious activity, 6-18 medium, 1-2 brief format, 6-20 Security management creating, 6-17 See also Access control defining contents of, 6-19, 6-20 See also Password management destination, 6-19 See also Protection detailed inspection, 6-21 See also Security auditing examples, 6-20, 6-22 See also Security checklists formats, 6-19 clusters, building common environment 8-2 full format, 6-20 clusters, system file recommendations, '8-3 rights identifiers in, 4-5 clusters, system file requirements, 8-2 routine inspections, 6-18 managing audit log file, 8-5 scheduling, 6-17 modifying cluster group number, 8-7 summary format, 6-21 modifying cluster password, 8-7 Security breaches, handling, 1-1, 7-6 policy development, 1-2, 7-1 Security checklist protected objects, cluster-visible, 8-6 for users, 3-21 protected objects, databases, 8-6 Security checklists synchronizing authorization data, 8-4 for C2 systems, C-10 SYSMAN requirements, 8-7 for designing a secure system, 2-7 Security models, 2-1 for maintaining a secure system, 5-64 Security operator terminals, 6-15 for training users, 5-57 SECURITY privilege, A-15 Security class object, 4-46 hidden ACEs and, 4-20 definition, 4-10 Security problems events audited, 4-47 anonymity of network and dialup users, 5-44 profile storage, 4-47 autologin accounts, reducing, 5-39 template profile, 4-46 categories of, 1-1 types of access, 4-46 disk scavenging, 4-38 Security features hardcopy terminal output, 3-20 access controls, 4-1 logging out, 3-19 account duration, 3-11, 3-12 network access control strings, 3-14 auditing, 3-17, 6-1, 7-4 network protected communications, 9-5 automatic password generation, 3-9 password detection, 3-10 break-in evasion, 3-9 telephone system as, 7-7 dialup retries, 3-8 Security profiles erase-on-allocate, 5-63 assigning to new devices, 4-34 erase-on-delete, 5-62 capability object, 4-30 highwater marking, 5-63 common event flag clusters, 4-31 login class restrictions, 3-8 devices, 4-33 password changes, 3-9 displaying class defaults, 5-19 password expiration, 3-11 files, 4-26, 4-35, 4-37 password protection, 3-13
lndex-17 Security profiles (cont'd) SET PASSWORD command (cont'd) global sections, 4-41 /SECONDARY qualifier, 3-11 in access evaluations, 4-10 /SYSTEM/GENERATE qualifier, 5-21 logical name tables, 4-43 /SYSTEM qualifier, 5-21 modification requirements, 4-10, 4-27 SET PROCESS command, /PRIVILEGES qualifier, objects, 4-6 4-5,5-46 ACLs, 4-8 SET PROTECTION/DEFAULT command, 5-11 changing, 4-9 SETPRV privilege, A-15 contents, 4-6 SET SECURITY command deleting ACLs, 4-21 /ACL qualifier, 4-20 displaying, 4-8 adding Identifier ACEs, 4-16 modifying class templates, 5-20 deleting, 4-21 origin of, 4-6 deleting ACEs, 4-21 owner element, 4-7 example, 5-16 protection codes, 4-7, 4-23 replacing ACEs, 4-22 processes, 4-1 I AFTER qualifier, 4-21 displaying, 4-4 changing object security profile, 4-9 identifiers, 4-3 changing protection codes, 4-25 privileges, 4-5 /CLASS=DEVICE qualifier, 5-43 UICs, 4-2 /CLASS qualifier, 4-9, 4-17 queues, 4-44 copying ACLs, 4-22 resource domains, 4-45 /COPY_ATTRIBUTE qualifier, 4-22 security class, 4-46 creating an ACL, 5-18 users, 4-1 /DEFAULT qualifier, 4-22 displaying, 4-4 example, 9-19 identifiers, 4-3 /DELETE qualifier, 4-21 privileges, 4-5 deleting ACEs, 4-21 UICs, 4-2, 4-3 example, 9-19 volumes, 4-47 /LIKE qualifier, 4-22 Security restrictions managing site defaults, 5-18 captive command procedures, 5-53 /OWNER qualifier, 4-9 devices, 5-42 /PROTECTION qualifier, 4-9, 4-24 login class, 3-8 modifying codes, 4-25 on command usage, 5-44 modifying for devices, 5-43 on mode of operation, 5-44 /REPLACE qualifier, 4-22 shifts, 3-8, 5-43 restoring defaults for files, 4-26 time-of-day, 3-8, 5-43 setting default file protection, 5-16 SECURITY_POLICY system parameter, 8-6, C-9 SET TERMINAL command Servers /DISCONNECT qualifier, 5-31 audit, 6-23 /HANGUP qualifier, 3-20 secure terminals, 3-13 /NOMODEM/SECURE qualifier, 5-37 SET AUDIT command /SECURE qualifier, 5-36 See also Audit server processes stopping password grabbers, .5-37 alarms, D-8 /SYSPWD qualifier, 5-21 enabling security-relevant events, 6-2 Set-Up key, 3-20 /EXCLUDE qualifier, 6-27 SET VOLUME command /INTERVAL qualifier, 6-28 /ERASE_ON_DELETE qualifier, 5-62 /LISTENER qualifier, 6-16 /NOHIGHWATER_MARKING qualifier, 4-39, opening new log files, 6-13 5-63 /SERVER qualifier, 6-27 /PROTECTION qualifier, 5-12 /SERVER qualifiernomaster, 6-28 SET VOLUME command, /ERASE_ON_DELETE suggested auditing applications, 7-4 qualifier, 4-39 /THRESHOLD qualifier, 6-28 Shareable devices, access requirements, 4-33 SET FILE command, /ERASE qualifier, 4-39 Shared files, considerations for a cluster system, SET HOST command, 3-5 8-5 SET PASSWORD command, 3-9 SHARE privilege, A-15 automatic password generation, 3-10 /GENERATE qualifier, 3-10, 5-25
lndex-18 Shift restrictions, 3-8 System Generation utility (SYSGEN), auditing SHMEM privilege, A-16 parameter modifications, 6-7 SHOW AUDIT command, 6-3, 6-24 System global sections SHOW CHAR display, 9-17 See Global sections SHOW/IDENTIFIER command in Authorize System-level access control, 9-2 utility, 5-7 System Management utility (SYSMAN) SHOW INTRUSION command, 5-35 modifying cluster security data, 8-7 SHOW PROCESS command, 4-4 modifying LGI parameters, 8-2 and WORLD privilege, 5-42 System Management utility (SYSMAN), managing SHOW PROTECTION command, 4-38 clusters, 8-7 SHOW/RIGHTS command in Authorize utility, System messages 5-7 SHOW SECURITY command, 4-20 See Messages displaying security profiles of objects, 4-8 System parameters displaying site defaults, 5-18, 5-19 auditing modification of, 6-7 displaying the object's class, 4-9 controlling dialup logins, 5-31 SHOW USERS command, disconnected jobs and, controlling disconnected processes, 5-31 3-20 defi~ing system users (security category), 4-28 Site security, 1-3 required C2 settings, C-9 SOGW user category abbreviation, 4-23 System passwords, 3-2 Spawning of processes, security implications in causing login failures, 3-8 restricted accounts, 5-53 disadvantages, 5-22 Spooled devices, access requirements, 4-32 entering, 3-3 STARTUP_Pl system parameter, C-9 guidelines, 5-21 Subjects in security models, 2-1, 2-3 minimum length requirement, 5-25 Submit access, 4-44 modifying, 5-22 Subsystem ACEs, 5-8, 10-3 to 10-5 recommended change frequency, 5-24 format, 10-4 setting up, 5-21 Subsystem attribute, 5-11 where stored, 5-22 Systems Subsystems controlling access to, 3-5 See Protected subsystems controlling use of, 3-3 Surveillance guidelines, 5-64 System services, auditing event information, 6-9 SYS$ANNOUNCE logical name, 5-30 System user authorization files SYS$NODE logical name, 5-30 SYS$WELCOME logical name, 5-30 See SYSUAF.DAT files SYSALF, automatic login facility (ALF) file, 5-37 System users (security category), 4-7, 4-28 SYSECURITY.COM command procedure, 6-14 defining with MAXSYSGROUP parameter, SYSGBL privilege, 4-42, A-16 4-23 SYSLCK privilege, 4-45, A-16 qualifications for, 4-23 SYSMAN databases, C2 environments and C-3 SYSUAF.DAT files SYSNAM privilege, 4-43, A-16 , account expiration, 3-12 modifying system operations, 4-5 auditing modifications, 6-3 overriding access controls, 4-11 effect of changes on NETPROXY (network proxy queue management, 4-44 authorization file), 9-16 SYSPRV privilege, 4-11, 4-27 LOCKPWD flag, 3-4 giving rights of system user, 4-23 login check, 5-32 tasks requiring, A-17 login class restrictions, 3-8 modifications and security audit, 3-19, 6-7 System-defined identifiers normal protection, 5-29 See Environmental identifiers password storage, 2-3 System failures, disposing of hardcopy output, privileges and, 5-45, A-1 3-20 recording privileges, 4-5 System files synchronization with rights database and, 5-5 adding ACLs, 5-40 SYSUAFs (system user authorization files) auditing recommendations, 7-5 benefiting from ACLs, 7-5 See SYSUAF.DAT files protecting, 5-40 protection codes and ownership, B-1
lndex-19 T u Tampering with system files, detecting, 7-5 UAFs (user authorization files), 3-1 Tapes See also SYSUAF.DAT files default security elements, 4-34 enabling auditing through, 6-2, 6-6 managing security profiles, 4-34 record oflast login, 3-17 TASK objects, 9-9 DIC-based protection TCB (trusted computing base), C-2 See Protection codes file protection, C-4 UIC groups hardware, C-2, C-3 design limitations, 5-3 privileges and, C-4 design of, 5-2 software, C-2, C-3 impact on user privileges, 5-2 Template devices, security elements of, 4-34 UIC identifiers Template profiles deleting when employee leaves, 5-6 See Security profiles example, 4-4, 4-18 Terminals UICs (user identification codes), 2-3 breaking dialup connection, 3-20 adding to rights database, 5-5 C2 system restrictions, C-7 alphanumeric, 4-2 clearing DECwindows screen, 3-14 C2 systems and, C-6 clearing the screen, 3-14, 3-19 changing an object's, 4-7 controlling access, 3-2, 5-21 definition, 4-2 default security elements, 4-34 format, 4-2 dialup login, 3-5 group restrictions, 4-2 failing to respond, 3-3 guidelines for creating, 4-2 hard copy, disposing of output, 3-20 numeric, 4-2 limiting access, 5-43 object access evaluations and, 4-11 lines for modems, security of, 5-60 process, 4-3 logout considerations, 3-19 storage of, 4-3 modifying security profiles, 4-34 uniqueness requirement for clustered systems, requiring a system password, 3-8 8-5 security alarms and, 6-15 zero, 4-11 session logging, 5-58 Unshareable devices, access requirements, 4-33 system password, requirement for, 3-3 UPGRADE privilege, A-18 . usage restrictions, 5-43 Use access, 4-30 user, in C2 systems, C-8 User accounts, 5-58 virtual, 3-6, 3-20, 5-31 security considerations, 5-1 Time User authorization auditing changes to system time, 6-7 account expiration, 3-12 synchronizing cluster time, 6-28 login class restrictions, 3-8 Time-of-day login restrictions, 3-8 privilege use, 4-5 Time-stamp, synchronizing in cluster, 6-28 shift restrictions, 3-8 TMPMBX privilege, A-18 User authorization files Training of users, importance to security, 5-57 See SYSUAF.DAT files Trojan horse, 4-41 See UAFs precautions against, 5-41 See User authorization Trusted Computing Base User identification codes See TCB See UICs TTY_DEFCHAR2 system parameter User irresponsibility disabling virtual terminals, 5-31 as security problem, 1-1 enabling system passwords for remote logins, training as antidote, 5-57 5-21 User names as identifiers, 2-3, 4-3 TTY_TIMEOUT system parameter User passwords setting reconnection time, 5-31 See Passwords Turnkey accounts User penetration as security problem, 1-1 See Captive accounts
lndex-20 User probing as security problem, 1-1 See also Disk volumes Users access requirements, 4-32 access through ACEs, 4-16 as protected objects, 4-10 C2 systems and, C-6 auditing mounts or dismounts, 6-7 displaying process rights identifiers, 4-4 erasing data, 5-63 displaying rights, 5-7 events audited, 4-48 file security and, 4-40 foreign, access requirements, 4-32 granting privileges, 5-45 privilege requirements, 4-48 introduction to system, 5-57 profile storage, 4-48 protection code categories, 4-23 protection, 4-47 requesting access, 4-11 reusing in C2 systems, C-8 security categories of, 4-7, 4-23 to 4-24 security elements of, 4-47 security profiles of, 4-1 template profile, 4-47 setting default object protection, 5-11 types of access, 4-47 training, 5-57 VTlOO-series terminal, clearing screen, 3-20 trusted, C-4, C-8 VT200-series terminal, clearing screen, 3-20 untrusted, C-5 User training, 5-57 User-written system services, C-3 w replacing with protected subsystems, 10-1 Weekday login restrictions, 3-8 Welcome messages, 3-6 security disadvantages, 5-30 v Wildcard characters VAXcluster environments in ADD/IDENTIFIER command, 5-5 See Cluster environments in SHOW/RIGHTS command in Authorize Verification utility, 5-7 of circuits, 9-7 PROXY command in Authorize utility, 9-19 using two passwords, 5-22 Work restrictions, 5-44 Video terminals Workstations, default security elements, 4-34 See Terminals WORLD privilege, A-19 Virtual terminals, 5-31 impact on SHOW PROCESS command, 5-42 World users (security category), 4-7, 4-23 See also Terminals disabling, 3-6 Worms, 5-41 Write access disconnected processes and, 3-20 devices, 4-32 displaying disconnected processes, 3-20 files, 4-36 logging out of, 3-20 global sections, 4-41 VMS$0BJECTS.DAT files, 8-6 VOLPRO privilege, 4-48, A-18 granting through ACLs, 4-19 granting through protection codes, 4-24 Volumes logical name tables, 4-42 resource domains, 4-45 security class, 4-46 volumes, 4-47 z Zero UICs, protection checking and, 4-11
lndex-21
NOTES NOTES
2 NOTES
3 NOTES
4 NOTES
5 NOTES
6 NOTES
7 NOTES
8 NOTES
9 NOTES
10 NOTES
11 NOTES
12 How to Order Additional Documentation
Technical Support If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825) and press 2 for technical assistance.
Electronic Orders If you wish to place an order through your account at the Electronic Store, dial 800-234-1998, using a modem set to 2400- or 9600-baud. You must be using a VT terminal or terminal emulator set at 8 bits, no parity. If you need assistance using the Electronic Store, call 800-DIGITAL (800-344-4825) and ask for an Electronic Store specialist.
Telephone and Direct Mail Orders
From Call Write U.S.A. DEC direct Digital Equipment Corporation Phone: 800-DIGITAL P.O. Box CS2008 (800-344-4825) Nashua, NH 03061 FAX: (603) 884-5597 Puerto Rico Phone: (809) 781-0505 Digital Equipment Caribbean, Inc. FAX: (809) 749-8377 3 Digital Plaza, 1st Street Suite 200 Metro Office Park San Juan, Puerto Rico 00920 Canada Phone: 800-267-6215 Digital Equipment of Canada Ltd. FAX: (613) 592-1946 100 Herzberg Road Kanata, Ontario, Canada K2K 2A6 Attn: DECdirect Sales International Local Digital subsidiary or approved distributor Internal Orders 1 DTN: 241-3023 Software Supply Business (SSB) (for software (508) 87 4-3023 Digital Equipment Corporation documentation) 1 Digital Drive Westminster, MA 01473 Internal Orders DTN: 234-4325 Publishing & Circulation Services (for hardware (508) 351-4325 Digital Equipment Corporation documentation) FAX: (508) 351-4467 NR02-2 444 Whitney Street Northboro, MA 01532
1Call to request an Internal Software Order Form (EN-01740-07).
Reader's Comments OpenVMS VAX Guide to System Security AA-PV5RA-TE
Your comments and suggestions help us improve the quality of our publications. Thank you for your assistance. I rate this manual's: Excellent Good Fair Poor Accuracy (product works as manual says) D D D D Completeness (enough information) D D D D Clarity (easy to understand) D D D D Organization (structure of subject matter) D D D D Figures (useful) D D D D Examples (useful) D D D D Index (ability to find topic) D D D D Page layout (easy to find information) D D D D
I would like to see more/less
What I like best about this manual is
What I like least about this manual is
I found the following errors in this manual: Page Description
Additional comments or suggestions to improve this manual:
For software manuals, please indicate which version of the software you are using:
Name/Title Dept. Company Date Mailing Address Phone Do Not Tear - Fold Here and Tape
No Postage Necessary if Mailed in the United States
BUSINESS REPLY MAIL FIRST CLASS PERMIT NO. 33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE
DIGITAL EQUIPMENT CORPORATION OpenVMS Documentation 110 SPIT BROOK ROAD ZK03-4/U08 NASHUA, NH 03062-2642
lll11111ll1ll1111ll1111l1l11l1l1ll111l11l11l1l1l1l1I
Do Not Tear - Fold Here ------