Auditing is based on selective examination of events and actions on the system.
A record of system activities includes
-
Session log-on and session logoff
-
The beginning and ending of tasks
-
Attempts to log-on with an incorrect usercode or password
-
Unauthorized attempts to access a file
-
TCP/IP requests that do not pass security validation specified in the active rules file
The record of activities is stored in the SUMLOG file and in a companion file, the security log, which contains security-related log entries.
The security log is protected by setting the SECURITYADMIN file attribute to TRUE. Otherwise, its format and physical attributes (except its actual size) are identical to those of the SUMLOG. The SDASUPPORT library simultaneously accesses both files transparently.
| Note: | Typically all actions performed by software that is not part of the Trusted Computing Base (TCB) is logged in the SUMLOG. |
Naming Convention
The name of the current log is always SYSTEM/SUMLOG.
The name of the current security log is always SYSTEM/SECURITYLOG.
New logs are created when
-
A log is transferred with the TL (Transfer Log) system command.
-
LOG family is changed using the DL (Disk Location) system command.
-
An automatic log release is initiated.
Any log file release action affects both the SUMLOG and the security log. Both files are always released as part of the same action.
A log file is changed through the automatic log release when the MCP determines that the existing file is almost full. For example, if the SUMLOG file holds up to 90,000 records, an automatic log release takes place when the log is approximately 87,000 records long (the number of records in a SUMLOG can be tailored).
When new system log files are created, the previous versions are renamed as follows:
SUMLOG/<system serial number>/<date>/<nnnnnn>
SECURITYLOG/<system serial number>/<date>/<nnnnnn>
The <system serial number> value is the serial number of the system on which the files were created.
The <date> value is the date on which the logs were transferred. The format is mmddyy.
The <nnnnnn> value is a 6-digit integer that is incremented each time a log transfer occurs. The identical number is placed into the names of both log files (SUMLOG and SECURITYLOG). The MCP maintains this number in a disk table so that the numbers increase until the next cold-start.
Responding When the Logging Pack Fills Up
| Note: | This discussion applies only to systems that have either the
Secure Access Control Module security-enhancement software or the
Secure Accountability Facility security feature package and that are
running with the following security option settings in effect:
|
For more information on system security options, see Controlling System Security.
The SUMLOG and the security log always reside on the same disk family. If either file is nearing capacity, and there is no room on the log family to expand the file, the following warning message appears at the ODT:
<integer> SECTORS REQUIRED ON <log pack>
In the previous message,
Respond to this message to prevent a halt/load and fatal dump from occurring when the log file can no longer expand.
Respond to the message by performing one of the following procedures:
-
Remove unnecessary files from the pack where the log files are located. To request the name of this pack, use the interrogatory form of the DL (Disk Location) system command.
-
Change the location of the log files to a disk with more space available on it by using the DL system command as follows:
DL LOG ON <family name>
You must be a security administrator to use this form of the DL command when security-administrator status is authorized for the system.
-
Create free disk space on the log pack by using the SQUASH (Consolidate Disk Allocation) system command.
-
Set the security option SUMLOGFULL to DISCARD.
-
Use the RC system command to reconfigure a disk and add that disk to the disk family.
Because the TL (Transfer Log) system command does not move the previous log files, you cannot use the TL command to remedy the problem of a log pack that is nearly full and a log file that requires expansion room.
Protecting the Log Files
The log files are your record of activities on the system. If a user is deliberately misusing system resources or attempting to violate security, the user might attempt to cover his or her tracks by altering or even destroying the log files.
The system protects the log files in the following ways:
-
System log files are marked as read-only files. This read-only attribute can be set only by the MCP. Files marked as READONLY by the MCP can be written to only by the MCP.
You can use the LFILES command to interrogate the value of the read-only attribute. If the file is marked as READONLY, you can be assured that no one has tampered with the log file.
-
System log files are created with a FILEKIND of LOG. Only the MCP can create a file with such a FILEKIND, and it is not possible to change the FILEKIND of an existing file to LOG.
You can check the FILEKIND of the log file. If the FILEKIND is LOG, you can be assured that the log file was created by the MCP and has not been modified.
-
Only the MCP (through the WRITELOG procedure) can write to the system logs.
With the exception of the first and second log records, the MCP performs write operations serially. The first record is used to record time discontinuities. The second record is used to record log discard time periods.
User access to the WRITELOG procedure is through the MCSLOGGER intrinsic and the MCP_LOGGER exported interface. These interfaces limit access to appropriately privileged programs and a restricted set of log types. The privileges and log types are documented in the System Log Programming Reference Manual.
The interfaces are used by system software to create, for example, diagnostic log records and MCS activity records. They can also be used to create installation-specific records that can be analyzed by a custom SITESUPPORT library; such records benefit from the inherent integrity of the system-maintained log. For more information on installation log entries, refer to the System Log Programming Reference Manual.
The SECURITYADMIN attribute of the security log file is always TRUE. Only users with the USERDATA granulated privilege can access this file. (Refer to the discussion on SECURITYADMIN in the File Attributes Programming Reference Manual for further details.)
On systems where the SECOPT (Security Options) system command designates either CLASS = S2 or SUMLOGSECURITY = PRIVATE, SYSTEM/SUMLOG is a private file that can be accessed only by privileged users or processes.
On other systems, the default value of the SECURITYTYPE attribute is PUBLIC, and the value of the SECURITYUSE attribute is IN, meaning that all users of the system can read all records in the log.
When the TL (Transfer Log) system command is used to release the current log files and initiate new ones, the new log files inherit the security file attributes of the old log files. For example, if the value of the SECURITYTYPE attribute for the log files has been changed to GUARDED and guard files have been attached to them, then the new log files are also guarded files and have the same guard files attached to them when the TL command is used.
Due to the possibly sensitive nature of information stored in the log, there might be many log records that the typical user should not be permitted to access. On the other hand, the same user might need read access to those records that pertain to his or her legitimate system activities. The selective logging feature permits just such control over log access. The following pages describe this feature.
