Safeguard Administrator's Manual (G06.24+, H06.03+)
Table Of Contents
- What’s New in This Manual
- About This Manual
- 1 Introduction
- 2 Controlling User Access
- Introduction
- Using SAFECOM to Establish a Local User Community
- Using SAFECOM to Manage User Access to Your System
- Changing the Owner of a User Authentication Record
- Granting a User Temporary Access to Your System
- Requiring Users to Change Their Passwords
- Granting a Grace Period for Changing an Expired Password
- Forcing Immediate Expiration of a User’s Password
- Freezing a User's Ability to Access the System
- Specifying Auditing for a User ID
- Deleting Users
- Deleting Administrative Groups
- Using SAFECOM to Establish a Network of Users
- Using Safeguard With Nodes With Standard Security
- Identifying Network Users
- Granting a Network User Access to Objects on Your System
- Establishing a Community of Network Users
- Changes to the PAID During a User’s Session
- Additional Considerations for Aliases and Groups
- Additional Considerations for ACCESS with Network Specific Subject IDs
- Establishing Default Protection for a User's Disk Files
- Specifying a Default Command Interpreter for a User
- Establishing Guardian Defaults
- Assigning an Alias to a User
- 3 Managing User Groups
- 4 Securing Volumes and Devices
- 5 OBJECTTYPE Control
- 6 Managing Security Groups
- 7 Securing Terminals
- 8 Warning Mode
- 9 Configuration
- Safeguard Attributes
- Configuring User Authentication
- Configuring Password Control
- Configuring Device Control
- Configuring Process Control
- Configuring Disk-File Control
- Configuring Safeguard Auditing
- Configuring a Default Command Interpreter
- Configuring Communication With $CMON
- Configuring Logon Dialog
- Configuring Exclusive Access at Safeguard Terminals
- Configuring Warning Mode
- Configuring Persistence
- Configuring Attributes for Node Specific Subjects in ACLs
- 10 Installation and Management
- Safeguard Components
- Process Considerations for the SMP and SAFECOM
- Safeguard Subsystem Management Commands
- General Installation Procedure
- Installing the Safeguard Software
- Starting the SMP
- Converting to the Safeguard Subsystem
- Updating the Safeguard Software
- Guidelines for Securing the Safeguard Subsystem
- Monitoring the Safeguard Subsystem
- A SAFECOM Command Syntax
- Index
Installation and Management
Safeguard Administrator’s Manual—523317-013
10-2
The Security Monitors (SMONs)
Security Database Management
The SMP makes all changes to the subject and object databases on the local system.
You make changes to the databases with SAFECOM commands. SAFECOM
interprets the commands and communicates with the SMP to change the database.
When a SAFECOM user requests information about a user or a protected object,
SAFECOM requests the information from the SMP. The SMP then reads the subject or
object database to reply to the SAFECOM request.
The SMP also creates audit records of attempts to access the subject and object
databases.
User Authentication
The SMP authenticates all user attempts to log on to the system in which it is running.
When a user attempts to log on, the user's command interpreter sends a user
authentication request to the SMP. The SMP reads the subject database to
authenticate the logon request and then replies to the command interpreter with the
results of the authentication check. The SMP also authenticates any authentication
request made by an application process.
Security Monitor (SMON) Process Management
The SMP is responsible for starting all the SMON processes on the system in which it
is running. When a processor fails, the SMP is responsible for restarting the SMON in
that processor after the processor has been reloaded.
The Security Monitors (SMONs)
A separate SMON process runs in every processor of a system in which the Safeguard
software is installed. Each SMON process is responsible for authorizing all attempts to
access protected objects with primary I/O processes running in its processor. Similarly,
when an attempt is made to access a running named process that is protected, the
access must be authorized by the associated SMON process. The SMON processes
read the object database to authorize attempts to access protected objects.
The SMON processes are also responsible for creating audit records of attempts to
access the objects under their protection.