From gww@eng.sun.com Tue Jan 23 11:54:34 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NJsYRr003479 for ; Tue, 23 Jan 2007 11:54:34 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0NJsYx4013742; Tue, 23 Jan 2007 11:54:34 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00F0D7AY2K00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 11:54:34 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC002R87AXWKB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 11:54:33 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NJsX9i024369; Tue, 23 Jan 2007 11:54:33 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0NJspqD022004; Tue, 23 Jan 2007 11:54:51 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0NJspfU022003; Tue, 23 Jan 2007 11:54:51 -0800 (PST) Date: Tue, 23 Jan 2007 11:54:51 -0800 (PST) From: Gary Winiger Subject: PSARC/2007/016 Solaris Auditing Policy To: psarc-ext@sun.com Cc: audit-discuss@opensolaris.org Message-id: <200701231954.l0NJspfU022003@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 24560 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@sun.com and audit-discuss@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@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 From owner-sec-swg Tue Jan 23 12:37:43 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NKbh7O004235 for ; Tue, 23 Jan 2007 12:37:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0NKbhN6008227; Tue, 23 Jan 2007 12:37:43 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00J059AVJ200@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 12:37:43 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC00HJF9AU2E10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 12:37:42 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NKbgEd024017; Tue, 23 Jan 2007 12:37:42 -0800 (PST) Received: from Sun.COM (marduk [129.146.108.224]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0NKc1g6022237; Tue, 23 Jan 2007 12:38:01 -0800 (PST) Date: Tue, 23 Jan 2007 12:38:01 -0800 From: Gary Winiger Subject: PSARC/2007/016 Solaris Audit Policy To: all-arcs@sun.com, sec-swg@sun.com Reply-to: psarc-ext@sun.com Message-id: <45B67229.8040902@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040126 Status: RO Content-Length: 163 This case is being run as a psarc-ext case including audit-discuss@opensolaris.org. If you wish to follow along or comment, please do so there. Thankx, Gary.. From sac-owner Tue Jan 23 12:37:43 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0NKbhTJ004233 for ; Tue, 23 Jan 2007 12:37:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0NKbhN6008227; Tue, 23 Jan 2007 12:37:43 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCC00J059AVJ200@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 12:37:43 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCC00HJF9AU2E10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 23 Jan 2007 12:37:42 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0NKbgEd024017; Tue, 23 Jan 2007 12:37:42 -0800 (PST) Received: from Sun.COM (marduk [129.146.108.224]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0NKc1g6022237; Tue, 23 Jan 2007 12:38:01 -0800 (PST) Date: Tue, 23 Jan 2007 12:38:01 -0800 From: Gary Winiger Subject: PSARC/2007/016 Solaris Audit Policy To: all-arcs@sun.com, sec-swg@sun.com Reply-to: psarc-ext@sun.com Message-id: <45B67229.8040902@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040126 Status: RO Content-Length: 163 This case is being run as a psarc-ext case including audit-discuss@opensolaris.org. If you wish to follow along or comment, please do so there. Thankx, Gary.. From Darren.Moffat@Sun.COM Wed Jan 24 01:46:40 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0O9kejD020851 for ; Wed, 24 Jan 2007 01:46:40 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0O9kdW18184 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Wed, 24 Jan 2007 02:46:39 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCD000039TRJF00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 24 Jan 2007 02:46:39 -0700 (MST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCD00HJJ9TPDWE0@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 24 Jan 2007 02:46:39 -0700 (MST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0O9kb4S022492 for ; Wed, 24 Jan 2007 09:46:37 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCD00C019OFX400@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 24 Jan 2007 09:46:37 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCD004OT9TGK800@d1-emea-09.sun.com>; Wed, 24 Jan 2007 09:46:29 +0000 (GMT) Date: Wed, 24 Jan 2007 09:46:28 +0000 From: Darren J Moffat Subject: Re: PSARC/2007/016 Solaris Auditing Policy In-reply-to: <200701231954.l0NJspfU022003@marduk.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: PSARC-EXT@Sun.COM, audit-discuss@opensolaris.org Message-id: <45B72AF4.10101@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200701231954.l0NJspfU022003@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 81 I've reviewed this and I support this long over due policy. -- Darren J Moffat From gww@eng.sun.com Wed Jan 31 13:58:36 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0VLwaIR000710 for ; Wed, 31 Jan 2007 13:58:36 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0VLwXux011215 for <@sunmail1brm.central.sun.com:psarc-ext@sun.com>; Wed, 31 Jan 2007 21:58:35 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCR0001B6DKXK00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 31 Jan 2007 14:58:32 -0700 (MST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCR00L666DHU050@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 31 Jan 2007 14:58:29 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0VLwSdc016429; Wed, 31 Jan 2007 13:58:28 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0VLwx56020614; Wed, 31 Jan 2007 13:58:59 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0VLwxA3020613; Wed, 31 Jan 2007 13:58:59 -0800 (PST) Date: Wed, 31 Jan 2007 13:58:59 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2007/016 Solaris Auditing Policy To: gww@eng.sun.com, psarc-ext@sun.com Cc: audit-discuss@opensolaris.org Message-id: <200701312158.l0VLwxA3020613@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 64 This fast track was approved at today's PSARC meeting. Gary.. From sac-owner Wed Jan 31 14:10:16 2007 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0VMAG02000916 for ; Wed, 31 Jan 2007 14:10:16 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0VMAlVs020651; Wed, 31 Jan 2007 14:10:47 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0VMAl0E020650; Wed, 31 Jan 2007 14:10:47 -0800 (PST) Date: Wed, 31 Jan 2007 14:10:47 -0800 (PST) From: Gary Winiger Message-Id: <200701312210.l0VMAl0E020650@marduk.eng.sun.com> To: sac-review@sac.sfbay.sun.com Cc: audit-core@sun.com, sec-swg@sun.com Subject: Policy for Review: PSARC/2007/016 Solaris Auditing Policy Status: RO Content-Length: 24780 This case was approved at today's PSARC meeting. All-arcs was informed when it started in case anyone wanted to follow along. Since this is intended as a SAC policy affecting all Solaris, I'm now sending it officially for SAC review. 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. This case was externially visible at psarc-ext and audit-discuss@os.org In case you didn't notice, this case is externally visible to 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@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 From owner-sec-swg Wed Jan 31 14:10:22 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0VMAM3M000925 for ; Wed, 31 Jan 2007 14:10:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0VMAFWK020031; Wed, 31 Jan 2007 14:10:17 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCR00D0H6X5DK00@nwk-avmta-2.sfbay.sun.com>; Wed, 31 Jan 2007 14:10:17 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCR00CO46X4QE00@nwk-avmta-2.sfbay.sun.com>; Wed, 31 Jan 2007 14:10:16 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0VMAGCD026930; Wed, 31 Jan 2007 14:10:16 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0VMAlVs020651; Wed, 31 Jan 2007 14:10:47 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0VMAl0E020650; Wed, 31 Jan 2007 14:10:47 -0800 (PST) Date: Wed, 31 Jan 2007 14:10:47 -0800 (PST) From: Gary Winiger Subject: Policy for Review: PSARC/2007/016 Solaris Auditing Policy To: sac-review@sac.sfbay.sun.com Cc: audit-core@sun.com, sec-swg@sun.com Message-id: <200701312210.l0VMAl0E020650@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 24780 This case was approved at today's PSARC meeting. All-arcs was informed when it started in case anyone wanted to follow along. Since this is intended as a SAC policy affecting all Solaris, I'm now sending it officially for SAC review. 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. This case was externially visible at psarc-ext and audit-discuss@os.org In case you didn't notice, this case is externally visible to 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@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 From sac-owner Wed Feb 7 15:30:56 2007 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l17NUueX007259 for ; Wed, 7 Feb 2007 15:30:56 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l17NVcba003712; Wed, 7 Feb 2007 15:31:38 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l17NVctc003711; Wed, 7 Feb 2007 15:31:38 -0800 (PST) Date: Wed, 7 Feb 2007 15:31:38 -0800 (PST) From: Gary Winiger Message-Id: <200702072331.l17NVctc003711@marduk.eng.sun.com> To: sac-opinion@sac.sfbay.sun.com Cc: gww@eng.sun.com Subject: Policy for Archiving: PSARC/2007/016 Solaris Auditing Policy Status: RO Content-Length: 24220 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. 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@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