The System Audit Trail is a feature that allows the System Administrators to review a record of all system activity. The ongoing record shows general trends in system usage and also violations of your system use policy. For example, any unsuccessful attempts to use system resources can be recorded in the audit trail. If a user consistently attempts to access files owned by other users or attempts to guess passwords, this can be recorded in the audit trail. The System Administrators can monitor all system activity through the audit trail.
The System Audit Trail is described completely in the guide titled gIRIX Admin: Backup, Security, and Accounting .
In addition to those listed in the IRIX Admin: Backup, Security, and Accounting guide, the following audit events are available to the Commercial Security Pak:
| sat_access_denied | | |
| sat_ae_audit | Events from the SAT daemon. | |
| sat_ae_lp | Events from the print daemon. | |
| sat_bsdipc_dac_change | | |
| sat_bsdipc_dac_denied | | |
| sat_bsd_if_setuid |
| |
| sat_proc_acct | Extended process accounting information events. | |
| sat_proc_own_ext_attr_write |
| |
| sat_session_acct |
| |
| sat_sys_note | System internal status data. |
The Commercial Security Pak has privileges implemented that are not present in standard IRIX. Because of this, the unexpected use of privilege is of special concern to the Auditor of a system with this optional software. Every interpreted audit record contains a line beginning with the keyword “Outcome.” The field following this keyword can be equal to one of “Success,” “Failure,” or “Success due to privilege.” The last case indicates that the user made a system call that would have failed except that Superuser privilege was invoked to assure its successful completion. This is not necessarily a security violation or an unexpected use of system privilege. It is perfectly normal to see these outcomes.
When an ordinary user runs a program that contains code that uses system privilege, “success due to privilege” outcomes are generated. A good example of this kind of program is passwd(1M). An ordinary user generates a record of this type simply by changing the password on his or her account. Records of this type are also generated when users use capabilities to edit system files.
One type of record to look for is an instance where the “SAT ID” or “Effective ID” field is different from the “User ID” field. This occurs when a user executes /bin/su to gain SSO privileges or otherwise promotes the privilege level of a session. In most cases, this is not a security violation, since the privilege is necessary to successfully complete the /bin/su command.
An instance of using Superuser privilege, though, is always worth examination in the audit trail. When you encounter an instance where a user has promoted his or her login session, you should check to see that the user is authorized to have the capability. If not, check whether the user indeed executed the /bin/su command, or if he or she promoted the privilege of the session by some other means, such as a trojan horse setuid shell command.
Whenever a user promotes the privilege of his or her login session, the Auditor should also make a routine check of what actions the user took while the privilege was promoted.