PSARC Questions Version 1.17 Here is a comprehensive list of questions that ARC members may ask of project presenters. Providing this information in advance of your review will greatly simplify the ARC's process of identifying the critical information relevant to your project. It is expected that many of these issues may be unresolved at the time of an inception review. However, they should be answerable at commitment review, and may be addressed at inception if significant. Please make your answers concise! Most if not all of these questions will be addressed in related documents such as 1-pagers, specs, design documents, etc. There is no reason to duplicate effort, and "see section 3.2 in the design spec" is an excellent answer. Of course, the referenced material must be provided with your submission. Entire sets of questions may be N/A for your project. For example, device drivers rarely have GUIs, and so the entire GUI section can just be deleted. In such cases, PLEASE NOTE N/A FOR THE MAIN QUESTION, AND DELETE THE REST OF THAT QUESTION SET. This questionnaire is meant to provide the ARC with an overview of your project, and it touches on the main areas of architectural interest. This template will be revised based on its users' experiences; your comments and suggestions are welcome. Send them to john.plocher@sun.com. For advice about architectural choices, pointers to various SAC guidelines, and other project considerations including Licensing and Patents, see http://sac.sfbay/arc/ARC-Considerations.html ------------------------------------------------------------------------ 1. What specifically is the proposal that we are reviewing? Validated Execution PSARC/2008/195 This project supersedes PSARC 2005/295 Barr - Signed Execution - What is the technical content of the project? Please provide diagrams that illustrate the project's architecture and interfaces. Be specific about deliverable components and their interfaces. Pay particular attention to describing the scope of the project, especially near the project boundaries. 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. The file inception/Design_Specification.pdf provides technical details. - Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", or "micro" change? See the Release Taxonomy in: http://sac.sfbay/BestPractices/release_taxonomy.html This is a new project. Since we intend to ship in a Solaris 10 Update, the proposed binding is patch. - If your project is an evolution of a previous project, what changed from one version to another? This project was previously presented to the ARC as PSARC 2005/295 Barr - Signed Execution. By comparison, this instantiation simplifies the administrative model, and isolates enforcement to the kernel, still using a daemon for evaluating objects. It extends the set of objects beyond the ELF-only limitation of the earlier project. It modernizes and expands the non-exec time auditing and reporting (originating with LSARC 2001/291) to be able to generate and validate suitable signable manifests. - What is the motivation for it, in general as well as specific terms? (Note that not everyone on the ARC will be an expert in the area.) This project provides a means of checking, at run-time, for corrupted executables and libraries in order to prevent accidental execution of Trojan horses. This project provides some, albeit incomplete, mechanisms to protect process images from changes to objects after validation. - What are the expected benefits for Sun? This provides an extra layer of security for our customers. This will further differentiate Solaris in the market. - By what criteria will you judge its success? The project is successful if it prevents execution of code that has been modified since it was signed, or execution of unsigned code by more privileged processes. 2. Describe how your project changes the user experience, upon installation and during normal operation. This project will have no effect on the normal use of the system. If signature validation has been enabled and an object has been corrupted, use of the object will not be permitted with the user experiencing a command or library failure use may be allowed with the process continuing with limited privileges. - What does the user perceive when the system is upgraded from a previous release? The bart(1M) utility will begin creating manifests to a new xml format specification which will not be comparable on older systems. The bart(1M) notes already caution about comparision of manifests between different systems. Existing bart manifests will be comparable with the new manifests by the updated utility (if content hashes use the same algorithm). 3. What is its plan? By default, there will be no effect. The system administrator can explicitly configure signature validation, which could lead to the effects above. A follow-on project could configure newly-installed systems to enforce signature validation by default. While it would be desireable to have validated execution configured on by default, that will not be possible until there is wide adoption of manifests as part of sofware delivery. - What is its current status? Has a design review been done? Are there multiple delivery phases? A prototype, with enforcement of both ELF signatures and unsigned manifests, has been built. A design review of the current proposal was done before coming for ARC review. We plan a subsequent project to provide a more comprehensive solution to the problem of maintaining process image integrity. 4. Are there related projects in Sun? During the effort to ELFsign Solaris 10 GA, we found one other integrity verification mechanism in use in Solaris: NSS's shlibsign. - If so, what is the proposal's relationship to their work? Which not-yet- delivered Sun (or non-Sun) projects (libraries, hardware, etc.) does this project depend upon? What other projects, if any, depend on this one? The use of manifests allows this project to be downstream of all other software publication mechanisms. This project depends on PSARC 2004/745 TPM Driver v1.0 PSARC 2007/674 Enabling Early Signature Validation and a, as yet unfiled, case to integrate libxmlsec. There are no known dependencies by other projects. - Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose? If not, please explain the areas of disagreement. This project has required changes in the cryptographic framework, which have been largely completed as part of opening the elfsign functionality. 5. How is the project delivered into the system? - Identify packages, directories, libraries, databases, etc. This project will deliver new packages holding manifests for validatable objects. Please see the functional specification for a complete list of deliverables. 6. Describe the project's hardware platform dependencies. Generally, the project has no specific hardware dependencies. The strongest validation requires a Trusted Platform Module (TPM) to validate all software elements. Without a TPM, validation can still be performed but the system must assume a valid boot sequence. - Explain any reasons why it would not work on both SPARC and Intel? None, although SPARC hardware support for TPM is generally lacking. 7. System administration - How will the project's deliverables be installed and (re)configured? The project will be packaged along with other core Solaris components. Actual deployment will be through administering the signed execution SMF-based service. - How will the project's deliverables be uninstalled? N/A - Does it use inetd to start itself? No. - Does it need installation within any global system tables? It will deliver an SMF manifest. - Does it use a naming service such as NIS, NIS+ or LDAP? No. - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? There are no regular maintainence activities required. During upgrade, additional manifests will be installed covering the updated and new objects themselves; this will be part of the upgrade process rather than an explicit separate step. - How does this project's administrative mechanisms fit into Sun's system administration strategies? E.g., how does it fit under the Solaris Management Console (SMC) and Web-Based Enterprise Management (WBEM), how does it make use of roles, authorizations and rights profiles? Additionally, how does it provide for administrative audit in support of the Solaris BSM configuration? SMF administration follows the authorization model for configuration and management. The administration model for certificates, manifests, and revocation has assumed that informal mechanisms would suffice (placement of files into well-known directories). - What tunable parameters are exported? Can they be changed without rebooting the system? Examples include, but are not limited to, entries in /etc/system and ndd(8) parameters. What ranges are appropriate for each tunable? What are the commitment levels associated with each tunable (these are interfaces)? All configuration parameters of validated execution can be modified at any time, and become effective through svcadm enable/disable/refresh: SMF-based: general/enabled use_global_settings unvalidated_privilege_cap File-based: /etc/signedexec/manifest /etc/signedexec/revocation /etc/signedexec/certlist 8. Reliability, Availability, Serviceability (RAS) - Does the project make any material improvement to RAS? No. - How can users/administrators diagnose failures or determine operational state? (For example, how could a user tell the difference between a failure and very slow performance?) Status can be checked via the svcs utility. Details of the configuration (unsigned_privilege_cap) can be displayed by signedexecadm utility. - What are the project's effects on boot time requirements? When validated execution is not configured: None. When validated execution is configured: extra time to validate objects, and a requirement for a properly-prepared initial manifest. - How does the project handle dynamic reconfiguration (DR) events? N/A - What mechanisms are provided for continuous availability of service? The validation daemon is a restartable service. While the validation daemon is not available, validations can fall back to the initial manifest. - Does the project call panic()? Explain why these panics cannot be avoided. No. - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? System messages. - How does the project deal with failure and recovery? It utilizes the SMF recovery facility. - Does it ever require reboot? If so, explain why this situation cannot be avoided. While normal configuration and operation won't require reboot, recovery from detection of an object corruption would typically require a reboot to ensure a "safe" state. - How does your project deal with network failures (including partition and re- integration)? How do you handle the failure of hardware that your project depends on? This project has no dependency on the network or network services. At this time, our understanding of TPM failure modes and the robustness of the project in the face of such failures is incomplete. - Can it save/restore or checkpoint and recover? N/A - Can its files be corrupted by failures? Does it clean up any locks/files after crashes? While corruption of the initial manifest is a possibility, recovery is expected to be addressed by the same mechanism as recovery from a corrupted or stale boot archive. 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? Via SMF interfaces signedexecadm The bart validate subcommand can be used to find binaries that can not currently be validated and create a manifests them. - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? If the subsystem is being overly restrictive, distinctive program failures will occur, requiring the administrator to configure more manifest and/or certificates, or to relax the unvalidated_privilege_cap or to undo some revocations. If the subsystem has been configured to be overly lenient, there will be no overt behavior to distinguish this from the actual desired behavior. - What statistics does the subsystem export, and by what mechanism? Some counters: kstat -n signedexec - What state information is logged? None - In principle, would it be possible for a program to tune the activity of your project? N/A 10. What are the security implications of this project? - What security issues do you address in your project? Verification that objects to be executed have not been corrupted. - The Solaris BSM configuration carries a Common Criteria (CC) Controlled Access Protection Profile (CAPP) -- Orange Book C2 -- and a Role Based Access Control Protection Profile (RBAC) -- rating, does the addition of your project effect this rating? E.g., does it introduce interfaces that make access or privilege decisions that are not audited, does it introduce removable media support that is not managed by the allocate subsystem, does it provide administration mechanisms that are not audited? The team has not yet developed a complete model of what decisions and events should be audited. For instance, it would seem appropriate that validation failures due to exceeding the unvalidated_privilege_cap be audited. - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? When validated execution has been configured, if the new files and directories are corrupt or missing, the extra security that validated execution would be capable of cannot be provided and will likely render the system unusable. However, all other security enforcement will be unaffected. - Please justify the introduction of any (all) new setuid executables. None. - Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.sfbay/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. When possible, validated execution roots its trust in a Trusted Platform Module (TPM). Otherwise, it depends on the system to maintain file integrity of a limited number of configuration files, and propogates that trust through through signature validation to cover the runtime checking of object integrity. The volatile mount option causes validated execution to revalidate objects from the filesystem before each invocation, such as might be appropriate for remote filesystems. We intend to use such mechanisms as memory-locking to prevent remote modifications from affecting process images while running. This project makes use of SignedXML (XML-DSig) as xml/xml-DSig is defined in related standards in extending bart to provide for signing of manifests. XML-DSig has been the subject of security/compatibility criticisms related to canonicalization complexity, signing data with outside references and signing partial contents. We believe this can be mitigated by restricting our signedexec manifests to specific subsets of valid XML manifests with regards to signing and transforms and meaningful outside references. Projects must highlight information for the following important areas: - What features are newly visible on the network and how are they protected from exploitation (e.g. unauthorized access, eavesdropping) None. - If the project makes decisions about which users, hosts, services, ... are allowed to access resources it manages, how is the requestor's identity determined and what data is used to determine if the access granted. Also how this data is protected from tampering. Security-sensitive operations require privilege. - What privileges beyond what a common user (e.g. 'noaccess') can perform does this project require and why those are necessary. Registration of the validation daemon door with the kernel. Modifying the value of the unvalidated_privilege_cap. Operations like signing of manifests, installing or updating the initial manifest, and sealing keys in the TPM will require knowledge of administrative keys. - What parts of the project are active upon default install and how it can be turned off. None. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? Solaris 10 Update and later - Environment variables? Exit status? Signals issued? Signals caught? (See signal(3HEAD).) As an internal implementation detail, the daemon accepts a signal to indicate that it should refresh. - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? /dev/tpm* when available. - Does it use any "hidden" (filename begins with ".") or temp files? None - Does it use any locking files? None - Command line or calling syntax: What options are supported? (please include man pages if available) bart validate [-i attribute] [-p] [-R root directory] [-r rules] [-s server] [-a alg] [-o outfile] bart sign [-c cert_data] [-k key_data] [-o outfile] manifest bart verify [-c cert_data] manifest Does it conform to getopt() parsing requirements? Yes. - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? N/A. - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? /lib/libc.so.1 /platform/sun4u/lib/libc_psr.so.1 /usr/lib/libelfsign.so.1 /usr/lib/libkmf.so.1 /lib/libnsl.so.1 /lib/libsocket.so.1 /usr/lib/libxml2.so.2 /lib/libpthread.so.1 /usr/lib/libz.so.1 /lib/libm.so.2 /usr/lib/libcryptoutil.so.1 /lib/libelf.so.1 /usr/lib/security/kmf_openssl.so.1 /usr/lib/libkmfberder.so.1 /usr/sfw/lib/libcrypto.so.0.9.8 /lib/libmd.so.1 /platform/sun4u/lib/libmd_psr.so.1 /lib/libscf.so.1 /lib/libuutil.so.1 (NOTE: /usr/lib items are being relocated by PSARC 2007/674 Enabling Early Signature Validation) XML-DSig support will be through a separate SFW ARC case, importing a xmlsec1.so.1 and some attendant plugins. - Identify and justify the requirement for any static libraries. None. - Does it depend on kernel features not provided in your packages and not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional kernel loadable modules)? No. - Is your project 64-bit clean/ready? If not, are there any architectural reasons why it would not work in a 64-bit environment? Does it interoperate with 64-bit versions? Yes. - Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a private copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? No. - Is the project internationalized and localized? Yes. - Is the project compatible with IPV6 interfaces and addresses? N/A. 12. What is its window/desktop operational environment? None. - Is it ICCCM compliant (ICCCM is the standard protocol for interacting with window managers)? - X properties: Which ones does it depend on? Which ones does it export, and what are their types? - Describe your project's support for User Interface facilities including Help, Undo, Cut/Paste, Drag and Drop, Props, Find, Stop? - How do you respond to property change notification and ICCCM client messages (e.g. Do you respond to "save workspace")? - Which window-system toolkit/desktop does your project depend on? - Can it execute remotely? Is the user aware that the tool is executing remotely? Does it matter? - Which X extensions does it use (e.g. SHM, DGA, Multi-Buffering? (Hint: use "xdpyinfo") - How does it use colormap entries? Can you share them? - Does it handle 24-bit operation? 13. What interfaces does your project import and export? - Please provide a table of imported and exported interfaces, including stability levels. Pay close attention to the classification of these interfaces in the Interface Taxonomy -- e.g., "Committed," "Uncommitted," and "*Private;" see: http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp Use the following format: Interfaces Imported Interface Classification Comments The_referring_standard Committed ANSI Xy.Tz 1999 draft 37 Somebody_else () Consolidation Private Interfaces Exported Interface Classification Comments My_subroutine_name Committed MY_MACRO Project Private Etc, etc, etc... ------------------------------------------------------------------------- Interfaces Exported Interface Classification Comments svc:/system/signedexec:default Committed FMRI unvalidated_privilege_cap Committed SMF property use_global_settings Committed SMF property /usr/sbin/signedexecadm Committed /etc/signedexec/manifest/ Committed Name, Volatile Contents /etc/signedexec/revocation/ Committed Name, Volatile Contents /etc/signedexec/certlist Committed Name, Volatile Contents - Exported public library APIs and ABIs Protocols (public or private) Support for validation via the SignaCert server is intended but will require SOAP over HTTPS and understanding of an alternative XML format. It is likely to be part a follow up ARC case. Drag and Drop ToolTalk Cut/Paste None. - Other interfaces - What other applications should it interoperate with? How will it do so? The bootadm update-archive command will require an update-to-date initial manifest and will automatically cause one to be generated. - Is it "pipeable"? How does it use stdin, stdout, stderr? N/A. - Explain the significant file formats, names, syntax, and semantics. The manifest schema is derived from the "Trusted Computing Group, Reference Manifest Schema Specification" (see materials). The format and location of the initial manifest is Project Private. The format of /etc/signedexec/certlist will be Committed. - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? It has been our intention that vendors be able to install directly into the /etc/signedexec/manifest/ and /etc/signedexec/revocation/ directories, including any "vendor-owned" subdirectories. Namespace allocation might be based on some convention, such as that for /opt. - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? Yes. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? N/A. - Protocols (public or private) - Private ToolTalk usage - Files - Other - Are the interfaces re-entrant? 15. Is the interface extensible? How will the interface evolve? It is believed that we've allowed for extensions in a number of directions: SMF properties, administrative subcommands, and adding new files and subdirectories to /etc/signedexec. - How is versioning handled? - What was the commitment level of the previous version? - Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? - What are the clients over which a change should be managed? - How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? 16. How do the interfaces adapt to a changing world? N/A. - What is its relationship with (or difficulties with) multimedia? 3D desktops? Nomadic computers? Storage-less clients? A networked file system model (i.e., a network-wide file manager)? 17. Interoperability We've built in interoperability between BART and the the remainder of Validated Execution, adopting common file formats. Bart verification aims for compatibility with the fingerprint databases of external vendors. - If applicable, explain your project's interoperability with the other major implementations in the industry. In particular, does it interoperate with Microsoft's implementation, if one exists? - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? - Does your project assume that a Solaris-based system must be in control of the primary administrative node? 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? There is no expectation of a positive increment in perceived performance. The use of caching of validation results is expected to lower the performance impact below observable. - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? No measurable effect when disabled. Minimal effect when enabled. - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? No, No. - What is your project's MT model? How does it use threads internally? How does it expect its client to use threads? If it uses callbacks, can the called entity create a thread and recursively call back? While the daemon is implemented as a door server, there are no exported APIs, thus no MT effects on external applications. - What is the impact on overall system performance? What is the average working set of this component? How much of this is shared/sharable by other apps? Minimal impact when validation is enabled for all executables, as measured via PerfPIT. - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? No. - Will it require large files/databases (for example, new fonts)? The manifests required are relatively modest in size. - Do files, databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? No. 19. Please identify any issues that you would like the ARC to address. - Interface classification, deviations from standards, architectural conflicts, release constraints... - Are there issues or related projects that the ARC should advise the appropriate steering committees? 20. Appendices to include - One-Pager. http://opensolaris.org/os/community/arc/caselog/2008/195/onepager/ - Prototype specification. inception/Design.pdf - References to other documents. (Place copies in case directory.)