Changed three things from inception review materials: 1. Question 2 Replaced: o the text installer requests a separate root password, as it is targeted at server users who will expect that capability. The root password will not be installed as expired. with o the handling of the root and user passwords will be in alignment with PSARC/2010/067: (and all the bullets below that) 2. Table 1 Changed /usr/bin/text-install to /usr/lib/text-install and changed to Uncommitted. 3. Question 5 Replaced: The creation of a user account is optional. If a user account is created, root is a role (not allowed to login). If the user account is not created, then a root login is allowed. The root password and the user account password are not required. However, if not provided, the user must respond to a confirmation dialog warning that the system is unsecured. with: See #2 for handling of initial user/root configuration. 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). The Text Installer is a mouseless, screen-oriented installer designed for use on SPARC and x86 systems that may not have graphics support such as many server-class machines. The Text Installer has been delivered by the Caiman project to OpenSolaris since March 2010 (b136). * Describe the exposure (OpenSolaris), scope and type of review desired (overview, full case, etc.) The Text Installer is part of OpenSolaris. The project has been developed in the open since inception. We are requesting an open full case review. * Indicate the release binding requested by the project team. See: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ Minor * What are the project's deliverables? The project will deliver a new package, system/install/text-install, which includes the following: * python files that comprise text installer * online Help files displayed by the text installer * a new SMF service that, upon booting the media, displays a menu of choices that allow the user to start the text installer, drop to the shell, set the terminal type, or reboot. In addition, new files will be added to the Distribution Constructor package (install/distribution-constructor): o manifests that build the default Text Installer media SPARC and x86 images o services needed to boot the Text Installer media to an appropriate environment o For x86, the Grub menu, hidden by default so user experience is similar on sparc and x86 Libraries added or modified by this project are delivered in the system/install package. * How does this project align with existing or proposed ARC cases? The Text Installer project is a subproject under the new Solaris installation umbrella: PSARC/2007/039 - Caiman: New Solaris Installation Experience and is similar in nature to the Live CD's GUI installer: PSARC/2007/284 - Dwarf Caiman, New Solaris Install GUI It uses the OpenSolaris Distribution Constructor to build install images. PSARC/2009/471 - OpenSolaris Distribution Constructor 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? Yes. This project will provide a text-based installer for OpenSolaris. The install is cpio based**, similar to the GUI installer on the Live CD, but the contents of the installed image are geared towards a basic headless server environment and do not contain the Gnome Desktop. **It is a requirement that the install be possible without a network connection and installing from a repo that resides on a DVD is not recommended (per the IPS team) for streaming installs. Experiments confirmed that installs from an on-disk IPS repo were unacceptably slow (hours). * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). The screens presented to the user are very similar to those in the GUI installer on the Live CD. Differences are: o the text installer provides the ability to preserve slices o root pool name not hard-coded to "rpool" to allow for co-existence with existing zpools named "rpool" on the same disk. o the handling of the root and user passwords will be in alignment with PSARC/2010/067: 1) No root password prompt 2) require an initial user login name and password 3) set the root password to the initial user password 4) the root is type=role 5) the initial user is granted the root role (type=normal;roles=root) 6) the initial user is put in /etc/sudoers -- presumable with all commands 7) the initial user is no longer granted the Primary Administrator Rights Profile 8) the password hash algorithm is sha256 9) the root account password is installed as expired (passwd -f). sp_lstchg == 0 username:password:lastchg:min:max:warn:inactive:expire:flag sp_namp:sp_pwdp:sp_lstchg:sp_min:sp_max:sp_inact:ex_expire:sp_flag * Are there any install time changes? This project provides a text-based install time experience for OpenSolaris. 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? Standard Package versioning * Has the team secured interface contracts where necessary? Preexisting contracts, see table below. * Use an ARC prescribed interface table format. The Text Installer will introduce the following interfaces: Table 1 Interfaces Exported ____________________________________________________________________________ | Interface |Commitment |Comments | |_____________________________|______________________|_______________________| |/usr/lib/text-install |Uncommitted | | |system/install/text-install |Committed | package | |/usr/lib/python2.6/vendor-packages/osol_install/tgt.so |Consolidation Private | Python to C bridge | |/usr/lib/python2.6/vendor-packages/osol_install/libzoneinfo.so |Consolidation Private | Python to C bridge | |system/install-setup:default |Uncommitted | SMF service | |_____________________________|______________________|_______________________| The Text Installer will import the following interfaces: Table 2 Interfaces Imported by Text Installer _____________________________________________________________________________ |Interface | Classification | Comments | |_______________________|_______________________|____________________________| |libzoneinfo.so.1 |Contract Private | [1] | |/usr/bin/python2.6 |Uncommitted | [2] | |libdiskmgt.so.1 |Consolidation Private | [3] | |Distribution Constructor |Committed | [4] | |libncurses.so |Contracted Volatile | [5] | |menu.lst (grub) |Evolving | [6] | |_______________________|_______________________|____________________________| [1] LSARC/2001/015 (contract in case materials) and LSARC/2002/402 [2] PSARC/2009/043 [3] LSARC/2004/743 (contract in case materials) [4] PSARC/2009/471 [5] LSARC/2008/524 [6] PSARC/2004/454 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. 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? The text installer is run as root in the install environment. Remote access to the install environment is disabled. See #2 for handling of initial user/root configuration. 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. The text installer presents a sequence of screens to the user for the purpose of recording user preferences relevant to the install. Once the installation begins, a progress bar is displayed to monitor the status. In addition, information relevant to the install is recorded in an installation log which can be accessed from an installer screen once the installation is complete. The log is copied onto the installed system in the event of a successful installation. It is possible to drop to the shell and run the installer in debug mode, which captures much more information to aid in troubleshooting. 7. How does the project deal with faults and interruptions? Initialization and restarting? It is possible to exit the installer UI and then restart the installer. After exiting the installer, one returns to the menu of choices (see project deliverables in section 1) and from there, it is possible to restart the installer from the menu or by dropping down to the shell and starting it manually from the command line. The installer is not currently able to clean up a failed install. This is tracked by bugzilla bug 13180, which is dependent on a fix for bugster bug 6910925 before being able to implement a change. The workaround is to reboot and restart the install. 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, Branded zones, SunCluster, etc.)? The installation is done into the global zone BE. Non-global zones can be set up following installation. The text installer has been used successfully with LDOMs, xVM, and vbox. 9. Does this project require administration (i.e., configuration or management)? If so, No. This project does not require administration. * 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). 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/ Reviewed the Policies and Best Practices links. This project does not need any 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/