JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Administration: Security Services     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information


Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Verifying File Integrity by Using BART (Tasks)

7.  Controlling Access to Files (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Security Attributes in Oracle Solaris (Reference)

Part IV Cryptographic Services

11.  Cryptographic Framework (Overview)

12.  Cryptographic Framework (Tasks)

13.  Key Management Framework

Part V Authentication Services and Secure Communication

14.  Using Pluggable Authentication Modules

15.  Using Secure Shell

16.  Secure Shell (Reference)

17.  Using Simple Authentication and Security Layer

18.  Network Services Authentication (Tasks)

Part VI Kerberos Service

19.  Introduction to the Kerberos Service

20.  Planning for the Kerberos Service

21.  Configuring the Kerberos Service (Tasks)

22.  Kerberos Error Messages and Troubleshooting

23.  Administering Kerberos Principals and Policies (Tasks)

24.  Using Kerberos Applications (Tasks)

25.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

Planning Auditing (Tasks)

How to Plan Auditing in Zones

How to Plan Who and What to Audit

How to Plan Disk Space for Audit Records

How to Prepare to Stream Audit Records to Remote Storage

Understanding Audit Policy

Controlling Auditing Costs

Cost of Increased Processing Time of Audit Data

Cost of Analysis of Audit Data

Cost of Storage of Audit Data

Auditing Efficiently

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)



Planning Auditing (Tasks)

You want to be selective about what kinds of activities are audited. At the same time, you want to collect useful audit information. You also need to carefully plan who to audit and what to audit. If you are using the default audit_binfile plugin, audit files can quickly grow to fill the available space, so you must allocate enough disk space.

The following task map points to the major tasks that are required for planning disk space and which events to record.

For Instructions
Determine auditing strategy for non-global zones
Determine who and what to audit
Plan storage space for the audit trail
Plan transmission of the audit trail to a remote server

How to Plan Auditing in Zones

If your system contains non-global zones, the zones can be audited as the global zone is audited, or the audit service for each non-global zone can be configured, enabled, and disabled separately. For example, you could audit only the non-global zones, and not audit the global zone.

For a discussion of the trade-offs, see Auditing on a System With Oracle Solaris Zones.

How to Plan Who and What to Audit

Before You Begin

If you are implementing non-global zones, review How to Plan Auditing in Zones before using this procedure.

  1. Determine if you want a single-system image audit trail.

    Note - This step applies only to the audit_binfile plugin.

    Systems within a single administrative domain can create a single-system image audit trail. If your systems use different naming services, start with Step 2. Then, complete the rest of the planning steps for every system.

    To create a single-system image audit trail for a site, every system in the installation should be configured as follows:

    • Use the same naming service for all systems.

      For correct interpretation of the audit records, the passwd, group, and hosts files must be consistent.

    • Configure the audit service identically on all systems. For information about displaying and modifying the service settings, see the auditconfig(1M) man page.

    • Use the same audit_warn, audit_event, and audit_class files for all systems.

  2. Determine the audit policy.

    By default, only the cnt policy is enabled.

    Use the auditconfig -lspolicy command to see a description of available policy options.

  3. Determine if you want to modify event-to-class mappings.

    In almost all situations, the default mapping is sufficient. However, if you add new classes, change class definitions, or determine that a record of a specific system call is not useful, you might want to modify event-to-class mappings.

    For an example, see How to Change an Audit Event's Class Membership.

  4. Determine which audit classes to preselect.

    The best time to add audit classes or to change the default classes is before users log in to the system.

    The audit classes that you preselect with the -setflags and -setnaflags options to the auditconfig command apply to all users and processes. You can preselect a class for success, for failure, or for both.

    For the list of audit classes, read the /etc/security/audit_class file.

  5. Determine user modifications to the system-wide preselections.

    If you decide that some users should be audited differently from the system, you can modify the audit_flags security attribute for individual users or for a rights profile. The user preselection mask is modified for users whose audit flags are explicitly set, or who are assigned a rights profile with explicit audit flags.

    For the procedure, see How to Configure a User's Audit Characteristics. For which audit flag values are in effect, see Order of Search for Assigned Security Attributes.

  6. Decide how to manage the audit_warn email alias.

    The audit_warn script is run whenever the audit system detects a situation that requires administrative attention. By default, the audit_warn script sends email to an audit_warn alias and sends a message to the console.

    To set up the alias, see How to Configure the audit_warn Email Alias.

  7. Decide in which format and where to collect audit records.

    You have three choices.

  8. Determine when to warn the administrator about shrinking disk space.

    Note - This step applies only to the audit_binfile plugin.

    When disk space on an audit file system drops below the minimum free space percentage, or soft limit, the audit service switches to the next available audit directory. The service then sends a warning that the soft limit has been exceeded.

    To set a minimum free space percentage, see Example 28-17.

  9. Decide what action to take when all the audit directories are full.

    Note - This step applies only to the audit_binfile plugin.

    In the default configuration, the audit_binfile plugin is active, and the cnt policy is set. In this configuration, when the kernel audit queue is full, the system continues to work. The system counts the audit records that are dropped, but does not record the events. For greater security, you can disable the cnt policy, and enable the ahlt policy. The ahlt policy stops the system when an asynchronous event cannot be placed in the audit queue.

    For a discussion of these policy options, see Audit Policies for Asynchronous and Synchronous Events. To configure these policy options, see Example 28-6.

    However, if the audit_binfile queue is full, and the queue for another active plugin is not full, then the kernel queue will continue to send records to the plugin that is not full. When the audit_binfile queue can again accept records, the audit service will resume sending records to it.

    Note - The cnt or ahlt policy is not triggered if the queue for at least one plugin is accepting audit records.

How to Plan Disk Space for Audit Records

The audit_binfile plugin creates an audit trail. The audit trail requires dedicated file space. This space must be available and secure. The system uses the /var/audit file system for initial storage. You can configure additional audit file systems for audit files. The following procedure covers the issues that you must resolve when you plan for audit trail storage.

Before You Begin

If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.

You are using the audit_binfile plugin.

  1. Determine how much auditing your site needs.

    Balance your site's security needs against the availability of disk space for the audit trail.

    For guidance on how to reduce space requirements while still maintaining site security, as well as how to design audit storage, see Controlling Auditing Costs and Auditing Efficiently.

    For practical steps, see How to Lessen the Volume of Audit Records That Are Produced, How to Compress Audit Files on a Dedicated File System, and Example 28-30.

  2. Determine which systems are to be audited and configure their audit file systems.

    Create a list of all the file systems that you plan to use. For configuration guidelines, see Storing and Managing the Audit Trail and the auditreduce(1M) man page. To specify the audit file systems, see How to Assign Audit Space for the Audit Trail.

  3. Synchronize the clocks on all systems.

    For more information, see Ensuring Reliable Time Stamps.

How to Prepare to Stream Audit Records to Remote Storage

Note - If you have a Kerberos realm configured with an identified Audit Remote Server (ARS) and all audited systems within the realm, you can skip this procedure. The steps to configure the ARS and the audited systems are covered in How to Configure a Remote Repository for Audit Files and How to Send Audit Files to a Remote Repository.

The audit_remote plugin sends the binary audit trail to an ARS in the same format as the audit_binfile plugin writes to the local audit files. The audit_remote plugin uses the libgss library to authenticate the ARS, and a GSS-API mechanism to protect the transmission with privacy and integrity. For reference, see What Is the Kerberos Service? and Kerberos Components.

The only currently supported GSS-API mechanism is kerberosv5. For more information, see the mech(4) man page.

Before You Begin

You plan to use the audit_remote plugin.

  1. Create a Kerberos realm for your audited systems.
    1. Install the master KDC package.

      You can use the system that will serve as the ARS, or you can use a nearby system. The ARS sends a significant amount of authentication traffic to the master KDC.

      If the Kerberos packages are already on the system, the output appears similar to the following:

      # pkg search -l kerberos-5
      INDEX      ACTION       VALUE                  PACKAGE
      pkg.summary   set  Kerberos version 5 support  pkg:/service/security/kerberos-5@vn
      pkg.summary   set  Kerberos V5 Master KDC      pkg:/system/security/kerberos-5@vn

      The first command checks if the Kerberos V5 Master KDC package is installed. The second command installs the package.

      # pkg info system/security/kerberos-5
      pkg: info: no packages matching these patterns are installed on the system.
      # pkg install pkg:/system/security/kerberos-5

      On the master KDC, you use the Kerberos kdcmgr and kadmin commands to manage the realm. For reference, see the kdcmgr(1M) and kadmin(1M) man pages.

  2. On every audited system that will send audit records to the ARS, install the master KDC package.
    # pkg install pkg:/system/security/kerberos-5

    This package includes the kclient command. On these systems, you run the kclient command to connect with the KDC. For reference, see the kclient(1M) man page.

  3. Synchronize the clocks in the KDC realm.

    If the clock skew is too big between the audited systems and the ARS, the attempt at connection will fail. After a connection is established, the local time on the ARS determines the names of the stored audit files, as described in Conventions for Binary Audit File Names.

    For more information about the clocks, see Ensuring Reliable Time Stamps.