I'm self sponsoring this fast track. This case is intended to codify the Solaris Audit Policy that has been in place for some time for the benefit of all ARCs and all project teams. In case you didn't notice, this case is externally visible to psarc-ext at sun.com and audit-discuss at opensolaris.org. The timer is set for 7 Feb. 2007.
The intent is that this policy will not only be available on the SAC website, but also on http://opensolaris.org/os/community/arc/policies The draft is presently available for pretty viewing from http://www.opensolaris.org/os/community/arc/policies/audit-policy/ For ease of review, a text version is part of this message. Thanks, Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Applicability Category Software.Solaris.All Audience Owner SAC Background Author Gary Winiger Policy Changes gww Advice Authority PSARC All security Implementation Policy Version 1.0 relevant operations Conformance Status DRAFT 2006/12/25 must be auditable Exemptions Effective Solaris 2.3 Appeals CaseHistory ManPages References ----------------------------------------------------------------------- Applicability All Sun Software running on Solaris that accesses resources (including user accounts) controlled by Solaris including, but not limited to: * Identification and Authentication (or reauthentication) of Solaris Users. * Introduction of Objects into a user's address space. Examples of objects: file creation/access, new processes, network endpoints, IPC objects, etc, by use of mechanisms such as open(), creat(), exec(), kill(), socket(), etc. * Removal of Objects from a user's address space. This includes removal from the system's address space. * Actions by computer operators, system administrators, and system security administrators. This is intended to include all configuration of the system and modification of "public information" supplied by the system. System "public information" is contained in objects (kernel data, files, data bases, name service data bases, ...) owned by the system (usually root, bin, sys or other system user) that are readable to all users, and are not modifiable by the normal user (e.g., the system clock, or /etc/*). Because the implementation always permits read access to all, read operations on public objects need not be auditable. However, modify operations are considered administrative actions and must be auditable. * All other security-relevant events. This is intended to include all operations that use or enforce privilege or authorization, provide access control, directly or indirectly communicate with another process, etc. (e.g., password change, screen lock, modification of public objects, addition, deletion, or modification of user accounts, creation, destruction of encryption keys, access of processes or windows not owned, signal another process). ----------------------------------------------------------------------- Audience ARCs, Project Teams ----------------------------------------------------------------------- Background Solaris (and SunOS) continues to be evaluated against various "Trusted Systems" criteria. Most recently these are the Controlled Access and Role Based Access Control Protection Profiles (CAPP, RBACPP) of the Common Criteria (CC). These criteria have various requirements for audit. Although the origin of these criteria is largely government and defense based, many IT and security conscious organizations are requiring that Solaris provide the ability to audit user's actions. Solaris Trusted Extensions (TX) (and Trusted Solaris before it) is additionally evaluated against the Labeled Security Protection Profile (LSPP). ----------------------------------------------------------------------- Policy * Applies to All Sun administrative and security enforcing software which is delivered with, installed on, or executes on Solaris. The scope of this policy is intended to cover applications, utilities and system calls. * Authority PSARC * Approval PSARC/2007/016 * Effective Solaris 2.3 * Policy Software affected by this policy must: * generate Solaris Audit Trails, * protect those Audit Trails from modification, distruction, and unauthorized access, * include information in the Solaris Audit Trail for analysis of the actions taken on the system. * Details Each audit record in the Solaris Audit trail must be able to answer: * Who is doing this? The actual user who was authenticated to the system. And, when TX is enabled, the Label at which the user is operating. This is the Audit User ID (and TX Process Label) and is generally managed by the "Solaris Audit infrastructure." * What is affected? The operation that occurred and what it operated on. This is the audit event and the information specific to that event including object name (and TX Object Label), privileges and/or authorizations enforced. This is supplied to the "Solaris Audit infrastructure" by the program/system call. * When did it happen? The date and time of the audited action. This is handled automatically by the "Solaris Audit infrastructure." * Where did it happen? Where was the user "physically" when the audited action happened. This is the Audit Terminal ID and is generally managed by the "Solaris Audit infrastructure." * What was the result? Did it succeed or fail and why? The success or failure of the auditable action. This is supplied to the "Solaris Audit infrastructure" by the program/system call. ----------------------------------------------------------------------- Advice Contact the Solaris Audit Project team at audit-discuss at opensolaris.org. ----------------------------------------------------------------------- Implementation The majority of the audit for system calls is table driven. New system calls should fit in easily, but do require review by the Solaris Audit Project team to ensure they meet the Evaluation Criteria. If the project does administration through smf(5) properties, and the project meets the SMF policy of individual authorizations and delivery of those authorizations in Rights Profiles, administrative audit is generally handled by the SMF framework. If the project does administration through CLI where the entire operation is specified on the command line and the project delivers Rights Profiles, administrative audit is generally handled by the RBAC framework. If the project does anything security relevant (e.g., authentication, authorization or privilege enforcement, administration) that is not covered by one of the preceding areas, audit must be provided for with the C interfaces described in PSARC/2000/517 and PSARC/2003/397 or their Java equivalents described in LSARC/2001/409. ----------------------------------------------------------------------- Conformance All Sun Software that runs on Solaris that falls under this policy must have its audit records (success and failure) validated by the Solaris Audit Project team or the Solaris Evaluations Project team. ----------------------------------------------------------------------- Exemptions From an Evaluation perspective, certain classes of programs may be exempt from Solaris Audit. Such programs may be those dealing exclusively with self contained users (such as "web", "database", or "anonymous" users which have no presence in Solaris) and self contained or public data (such as data within a self contained database, or web directory tree). While perhaps Solaris Audit here is not an Evaluation issue, it may well still be a business or customer issue. E.g., customers have expressed interested in audit of files sent and received through anonymous FTP. Note, this possible exemption does not include the administration/configuration of those programs on Solaris. ----------------------------------------------------------------------- Appeals Discuss during ARC review, with appeals to ARC-Chairs. ----------------------------------------------------------------------- CaseHistory +-------------------------------------------------------------+ | Case | Type | Name | Comment | |-----------------+-----------+-----------------+-------------| | /PSARC/2000/517 | OnePager | Thread-safe | Thread-safe | | | | audit API | audit API | |-----------------+-----------+-----------------+-------------| | | | Java Audit | Java Audit | | /LSARC/2001/409 | FastTrack | Session for | Session for | | | | Viper and WBEM | Viper and | | | | | WBEM | |-----------------+-----------+-----------------+-------------| | | | Contracted | Contracted | | | | audit | audit | | /PSARC/2003/397 | FastTrack | interfaces for | interfaces | | | | open source | for open | | | | | source | +-------------------------------------------------------------+ ----------------------------------------------------------------------- ManPages +-------------------------------------------------------------+ | Document | Description | |-----------------+-------------------------------------------| | bsmrecord.1m | display Solaris audit record formats | |-----------------+-------------------------------------------| | audit.log.4 | audit trail file | |-----------------+-------------------------------------------| | audit_class.4 | audit class definitions | |-----------------+-------------------------------------------| | audit_control.4 | control information for system audit | | | daemon | |-----------------+-------------------------------------------| | audit_event.4 | audit event definition and class mapping | |-----------------+-------------------------------------------| | audit_user.4 | per-user auditing data file | +-------------------------------------------------------------+ ----------------------------------------------------------------------- References * Common Criteria for Information Technology Security Evalation (CC): * Common Criteria An Introduction (PDF) * Part 1: Introduction and general model Version 2.3 (PDF) * Part 2: Security functional requirements Version 2.3 (PDF) * Part 3: Security assurance requirements Version 2.3 (PDF) * Part 1: Introduction and general model Version 3.1 (PDF) * Part 2: Security functional components Version 3.1 (PDF) * Part 3: Security assurance components Version 3.1 (PDF) * Historic Evaluation Criteria: * Department of Defense Trusted Computer System Evaluation Criteria (TCSEC or Orange Book) * Information Technology Security Evaluation Criteria (ITSEC) * Audit Specific Guidelines: * NCSC-TG-001v2 A Guide to Understanding Audit in Trusted Systems * NCSC-TG-20-C Trusted Unix Working Group (TRUSIX) Auditing in a Unix System (unpublished TRUSIX document) (PDF) * Protection Profiles (PP) for Solaris 10 Evaluations: * Controlled Access Protection Profile * Role Based Access Control Protection Profile * Labeled Security Protection Profile * Future Protection Profiles: * Single-Level Operating Systems in Medium Robustness Environments PP * Multi-Level Operating Systems in Medium Robustness Environments PP * Service Management Framework (SMF) usage * Rights Profiles/RBAC Framework * Adding RBAC Authorizations * Building RBAC Rights Profiles * suid and rbac authorizations * PSARC/1997/332 Execution Profiles for Restricted Environments
