From sac-owner Wed Mar 12 20:03:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2D32xiX012881 for ; Wed, 12 Mar 2008 20:02:59 -0700 (PDT) Received: from sunmail5.uk.sun.com (localhost [127.0.0.1]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2D32wIF019995 for ; Thu, 13 Mar 2008 03:02:58 GMT Received: (from noaccess@localhost) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/Submit) id m2D32wD0019994 for one-pager-not-2b-used-directly; Thu, 13 Mar 2008 03:02:58 GMT 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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2D32i5K019888 for <@sunmail2sca.sfbay.sun.com:one-pager@sun.com>; Thu, 13 Mar 2008 03:02:57 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 <0JXN00F01F4WQX00@brm-avmta-1.central.sun.com> for one-pager@sun.com (ORCPT one-pager@sun.com); Wed, 12 Mar 2008 21:02:56 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXN006RPF4VGD50@brm-avmta-1.central.sun.com> for one-pager@sun.com (ORCPT one-pager@sun.com); Wed, 12 Mar 2008 21:02:55 -0600 (MDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2D32tsX011900; Wed, 12 Mar 2008 20:02:55 -0700 (PDT) Received: (from johnz@localhost) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) id m2D32ss01045; Wed, 12 Mar 2008 20:02:54 -0700 (PDT) Date: Wed, 12 Mar 2008 20:02:54 -0700 (PDT) From: John Zolnowsky x69422/408-404-5064 Subject: [2008/195]Validated Execution: One-Pager To: one-pager@sun.com Cc: valex-discuss@opensolaris.org Message-id: <200803130302.m2D32ss01045@domus.sfbay.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 9928 Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Validated Execution 1.2. Name of Document Author/Supplier: John Zolnowsky 1.3. Date of This Document: 03/07/2008 1.3.1. Date this project was conceived: 05/04/2005 (This project is derived and extended from 2005/509 Signed Execution). 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Kathy.Jenks@Sun.COM 1.4.4. The name of your business unit: Solaris New 1.5. Email Aliases: 1.5.1. Responsible Manager: Craig.Payne@Sun.COM 1.5.2. Responsible Engineer: John.Zolnowsky@Sun.COM 1.5.3. Marketing Manager: Mark.Thacker@Sun.COM 1.5.4. Interest List: valex-discuss@opensolaris.org 2. Project Summary 2.1. Project Description: This project will add the feature of validating signatures associated with objects (kernel modules, executables, libraries, and scripts) before allowing such objects to be executed. The administrative model will address what signatures to accept and what disposition is to be given to objects without associated signatures. The project will address infrastructure issues such as facilities and procedures to associate signatures with both OpenSolaris and independently developed objects. 2.2. Risks and Assumptions: To validate the earliest executing code in the system, we rely on a hardware component called a Trusted Platform Module (TPM). For systems without a TPM, all of the functionality described herein is still available, but the user must implicitly trust that the earliest code has not been compromised. 3. Business Summary 3.1. Problem Area: Validated Execution provides a way to verify the integrity of program and library objects at the time of execution. Such verification provides assurance that the executable has not been altered, either accidentally or deliberately, since it was released by its publisher (which may be Sun, a third-party ISV, or the end customer). There have been other attempts to solve this problem, such as Tripwire or bart, by comparing files against a manifest of known valid files. However, there is no protection against programs that are modified after the comparison but before they are executed. Performing the verification at the time of use avoids the race condition inherent in solutions that periodically compare files against a known reference. This project also provides for the execution of unsigned objects with restricted privileges or preventing the execution of such object altogether. 3.2. Market/Requester: Customers in this space are those seeking to secure their environment against hostile internal and external attacks. It is expected that this technology will grow in importance in the following areas: financial, healthcare, media/entertainment, embedded solutions and government/military. 3.3. Business Justification: It is believed that Solaris was the first general purpose OS to sign essentially all executables. There are other attempts underway to enhance an OS to verify automatically the signature of objects before they're executed. 3.4. Competitive Analysis: This feature should be a competitive advantage for Solaris versus competing operating systems from other vendors. 3.5. Opportunity Window/Exposure: We've made it public that we're working on this problem. We shouldn't allow ourselves to be beaten to the market. 3.6. How will you know when you are done?: When all Sun supplied objects are delivered with signatures When third parties can sign their objects, using tools provided with Solaris When an administrator can define what certificates he trusts and import manifests for additional object signed with these certificates and When Solaris can correctly recognize and allow, restrict, or disallow execution for a given object 4. Technical Description: 4.1. Details: Each executable file object is protected by a digital signature, which is constructed from a one-way hash of the file contents encrypted with a private RSA key known only to the publisher of the software. The corresponding public key can be used to decrypt the hash value and verify that it matches the file contents. Most ELF-format files in Solaris already contain an embedded digital signature; for those that do not and for non-ELF objects such as shell scripts, we provide a separate manifest listing the signatures for each file. This mechanism extends easily to allow third-party software vendors and end customers to create their own manifests of file signatures. The general strategy employed is for entities that cause code to be loaded and executed, such as the kernel and run-time loader, to verify such code before execution. This establishes a chain of trust where each code component is validated by a previously validated component. To validate the earliest executing code in the system and initialize this process, we rely on a hardware component called a Trusted Platform Module (TPM). For systems without a TPM, all of the functionality described herein is still available, but the user must implicitly trust that the earliest code has not been modified. This feature provides some degree of protection even against an attacker who is able to run processes with all privileges. We cannot protect in general against such a process, because it is able to alter any part of the file system or memory. However, the privileged process cannot alter the information stored in the TPM without knowledge of the TPM's owner password. Even if the running system is compromised, any alteration to the file system will be detected the next time the system is booted. Any executable files modified by the attacker will fail to start when the system reboots. Therefore, if an attacker gains privilege by exploiting a vulnerability, he must do so every time the system is booted rather than leaving behind a "back door" that can be used in the future to gain privileged access to the system. 4.2. Bug/RFE Number(s): 5108977 get_progbits() needlessly resets .bss sh_type to SHT_PROGBITS 6309674: Signed Execution 6309676 SHA1 should be part of unix 4.3. In Scope: In addition to validating objects before executing them, this project will provide mechanisms to ensure the integrity of the process image of those objects. The project is investigating preventing modifications of objects (where modification is mediated by the operating system), locking objects in memory (where modification can occur outside the control of the operating system), or snapshots of objects. 4.4. Out of Scope: This project does not propose to restrict privileges based on the signatory. 4.5. Interfaces: New service: svc:/system/signedexec:default New utility: signedexecadm New daemon: signedexecd New format and options on existing utility: bart -a bart vs -p (old-format) bart sign bart verify New directories: /etc/signedexec/manifest /etc/signedexec/revocation New file: /etc/signedexec/initial-manifest /etc/signedexec/certlist 4.6. Doc Impact: New and updated manpages for utilities. New section in Administration Guide, covering both configuration of service and signing of objects. 4.7. Admin/Config Impact: The default installation will not configurate, enable, or be effected by this project. Only if the adminstrator explicitly configures validation via the new interfaces will there be any effect. 4.8. HA Impact: None expected. 4.9. I18N/L10N Impact: Limited to the addition of 10's of messages. 4.10. Packaging & Delivery: The creation of packages will be affected by the harvesting of the hashes of deliverables. The harvested hashes for releases and redeliveries will be incorporated as manifests in packages to be delivered with the releases and updates. 4.11. Security Impact: This project introduces a new security hardening mechanism, extending the range of TPM and BART manifest functionality to provide dynamic validation and integrity. 4.12. Dependencies: PSARC 2007/674 Enabling Early Signature Validation PSARC 2008/xxx libxmlsec PSARC 2004/745 TPM Driver v1.0 5. Reference Documents: Trusted Computing Group, Trusted Platform Module Specification, http://www.trustedcomputinggroup.org/specs/TP Trusted Computing Group, Reference Manifest Schema Specification, http://www.trustedcomputinggroup.org/specs/IWG/\ Reference_Manifest_Schema_Specification_v1.0.pdf 6. Resources and Schedule: 6.1. Projected Availability: Design Review: CY08Q2 Code Complete: CY08Q4 Putback: CY08Q4 6.2. Cost of Effort: 3 Development FTE for two years 1 Project Manager, 20% for two years 1 Documentation FTE for 3 months 1 Test FTE for 3 months 6.3. Cost of Capital Resources: 4 systems with TPM modules 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: // not provided 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: // See dependencies section above. 6.4.7. Target RTI Date/Release: CY08Q4 6.4.8. Target Code Design Review Date: Design Review: CY08Q1 Code Review: CY08Q3 6.4.9. Update approval addition: N/A 6.5. ARC review type: Standard 6.6. ARC Exposure: open 6.6.1. Rationale: Project is being conducted as an OpenSolaris project. 7. Prototype Availability: 7.1. Prototype Availability: CY08Q3 7.2. Prototype Cost: 75%