PSARC Questions Version 1.22 Approved Oct. 2008 (PSARC/2008/625) The 20 questions outline serves several purposes. One is to present to the ARC in a uniform manner pertinent information about any case. Many of the answers to these questions can be direct and specific references to other case materials (although care must be taken to keep the references current). A second purpose is to allow an ARC member to get a concise overview of the case in an efficient manner. Another purpose is that the 20 questions should provoke thought and questions for project teams unfamiliar with the ARC process, by asking questions about aspects of the project that need be considered. Lastly, the 20 questions serves as a vehicle between the case owner and the project team as an indicator of preparedness. The 20 questions, as do other ARC materials, remain as documentation of the case plan of record. 1. What is the proposal being presented for review? * Give an overview of the project and its phase(s). This case introduces architecture that lays the groundwork for the use of datalink management facilities from exclusive stack non-global zones. This architeture was devised for the purpose of IP tunnel link management in PSARC 2009/373, but is designed to be generally extensible for other classes of datalinks. * Describe the exposure (OpenSolaris), scope and type of review desired (overview, full case, etc.) This is a full case with open exposure. * Indicate the release binding requested by the project team. See: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ This case requests Minor release binding. * What are the project's deliverables? Updates to GLDv3 components to allow non-global zones access to unprivileged datalink functions (i.e. dladm show-* subcommands). Updates to GLDv3 component architecture to enable future cases to introduce support for the management of datalinks from within non-global zones (i.e. creation, modification, and deletion of links). * How does this project align with existing or proposed ARC cases? This is a spin-off of PSARC 2009/373. 2009/373 depends on this case. 2009/373 has a requirement that IP tunnel links should be fully manageable from within non-global zones, and defined the architecture necessary to do that. During Inception review for that case, committee members requested that the non-global zones architecture be run as a separate case. That is this case. 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? No new user interfaces are being introduced. The only user-visible change is that unprivileged dladm(1M) functionality (i.e. show-* subcommands) will now work from non-global zones. * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). N/A * Are there any install time changes? No. 3. What are the exported (defined by your project) and imported (defined by another project that your project then references) interfaces or protocols and their respective stability levels? See: http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ * Is there a versioning scheme in place? N/A * Has the team secured interface contracts where necessary? N/A * Use an ARC prescribed interface table format. The architecture defined by this case simply allows existing Public interfaces to function within non-global zones. The only new interfaces to note are the Consolidation Private libdladm functions called by zoneadmd to notify dlmgmtd that a zone is booting or halting, and the Project Private door calls used to implement those functions. +-------------------------------------------------------------------------+ | Interfaces Exported | +---------------------+------------------------+--------------------------+ | Interface Name | Classification | Comment | +---------------------+------------------------+--------------------------+ | dladm_zone_boot() | Consolidation Private | [1] section 5 | | dladm_zone_halt() | Consolidation Private | [1] section 5 | | DLMGMT_CMD_ZONEBOOT | Project Private | [1] section 5 | | DLMGMT_CMD_ZONEHALT | Project Private | [1] section 5 | +---------------------+------------------------+--------------------------+ 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. There are no hardware dependencies. 5. Projects need to be aware of the overall security of the system and how their components affect it. Which parts of this project are critical to the security of the system to avoid such unintended consequences such as unauthorized system entry, unauthorized access to or modification of data, elevation of privilege, denial of service, violation of labeled security, ...? Does this project require elevated privilege? A number of specific policies and practices address various aspects of the security of the system. They are found in appendix 1. Which of these are applicable to this project, and how are they addressed? This case in itself does not deliver functionality that is subject to security policies. Future cases that deliver management of specific link classes using this architecture will be required to define the privileges required to manage such link classes, and those privileges will be available in non-global zones. 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. This project allows the dladm show-* subcommands to work within non-global zones. This is adding observability to objects that were previously not observable from non-global zones. 7. How does the project deal with faults and interruptions? Initialization and restarting? See [1] section 5 and section 9 for details of how the architecture behaves with regards to zones booting and halting. 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, Branded zones, SunCluster, etc.)? It interacts with zones in obvious ways. ;-) 9. Does this project require administration (i.e., configuration or management)? If so, * How is the project administered, and what sort of review process has this user interface undergone? * Is there a means of aggregating management and/or configuration with other related projects? * Does this project deliver its own administration along with the other components, or is this project an administration interface for other projects? * Are there any external (to Solaris) management interfaces to consider, or being consumed? Projects that require or deliver administrative interfaces are often by their nature security components of the system and should likely address the security question (#5 above, with attention to RBAC and Audit). (See also appendix 2). This project doesn't introduce any new administrative interfaces. It simply enables use of existing interfaces in exclusive stack non-global zones. 10. Have you reviewed the Policies and Best Practices? Are there any exceptions this project needs? See http://www.opensolaris.org/os/community/arc/policies/ http://www.opensolaris.org/os/community/arc/bestpractices/ There are no exceptions. Appendix 1. Security references Plugable Authentication Modules http://opensolaris.org/os/community/arc/policies/PAM/ Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ Service Management Facility (SMF) usage http://opensolaris.org/os/community/arc/policies/SMF-policy/ Install-Time Security http://opensolaris.org/os/community/arc/policies/ITS/ Network Install-Time Security http://opensolaris.org/os/community/arc/policies/NITS-policy/ Secure - by - Default http://opensolaris.org/os/community/arc/policies/secure-by-default/ When to use setuid -vs - RBAC roles and profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ Building RBAC Rights Profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ Adding RBAC Authorizations http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/ Reusable Passwords in Command Line Arguments and Environment Variables http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ Storing Reusable Passwords on a FileSystem http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ Administrative and Security Precedents and Policies http://opensolaris.org/os/community/arc/bestpractices/overview-admin-security/ Security Questions http://opensolaris.org/os/community/arc/bestpractices/security-questions/ Labeled Security: http://en.wikipedia.org/wiki/Multilevel_security See also PSARC/2002/762 Layered Trusted Solaris http://arc.opensolaris.org/caselog/PSARC/2002/762 Appendix 2. Administrative access and control RBAC (Role Based Access Control): See PSARC/1997/332 Execution Profiles for Restricted Environments http://arc.opensolaris.org/caselog/PSARC/1997/332 Privilege: See PSARC/2002/188 Least Privilege for Solaris http://arc.opensolaris.org/caselog/PSARC/2002/188 Appendix 3. Policies and Best Practices references http://www.opensolaris.org/os/community/arc/policies/ http://www.opensolaris.org/os/community/arc/bestpractices/