PSARC Questions Version 1.18 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 project aims at implementing RFC 3768 and draft-ietf-vrrp-unified- -spec-02 - Virtual Router Redundancy Protocol Version 2 for IPv4, as well as version 3 for IPv4 and IPv6, with the goal of providing high availability on Solaris. It will have only one phase. * Describe the exposure (OpenSolaris), scope and type of review desired (overview, full case, etc.) It's an OpenSolaris project (http://opensolaris.org/os/project/vrrp/); It needs a full review. * Indicate the release binding requested by the project team. See: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ This project constitutes a "micro" change to Solaris. * What are the project's deliverables? New packages introduced: SUNWvrrpu, SUNWvrrpr Binaries changed through existing package: SUNWckr * How does this project align with existing or proposed ARC cases? None. 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? Will introduce some new interfaces. * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). There are several Linux-based VRRP implementatins, but the interfaces are quite different. * 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/ Exported Interface Classification Comments ================== ============== ======== SUNWvrrpu Committed Package for VRRP utility SUNWvrrpr Committed Package for VRRP configuration LIBVRRP_VERSION Committed VRRP API version /usr/sbin/vrrpadm Committed VRRP administration tool vrrpadm startup Committed sub command vrrpadm shutdown Committed sub command vrrpadm remove Committed sub command vrrpadm create Uncommitted sub command vrrpadm modify Uncommitted sub command vrrpadm show Volatile sub command /usr/sbin/vrrpize Committed Tool to "vrrpize" other SMF services /usr/sbin/vrrpd Project Private VRRP daemon /etc/vrrpd/sthook.* Project Private State transition hooks /etc/vrrpd/vrrp.conf Project Private VRRP Configuration file svc:/network/vrrp:default Uncommitted FMRI for the VRRP service /usr/lib/libvrrp.so Uncommitted VRRP APIs /usr/include/netinet/vrrp.h Uncommitted VRRP protocol /usr/include/libvrrp.h Uncommitted Exported header file /usr/include/libvrrp_impl.h Project Private Unexported header file * Is there a versioning scheme in place? Will provide a LIBVRRP_VERSION macro to indicate the VRRP API version. * Has the team secured interface contracts where necessary? Yes. * Use an ARC prescribed interface table format. See above. 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. None. 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, ...? 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 security concerns of this project are listed below: - Privileges. Most VRRP operations (creation, destroying, modifying, etc) require the PRIV_SYS_NET_CONFIG and PRIV_NET_RAWACCESS privileges. The observability operations ("vrrpadm show" command, vrrp_get_*() and vrrp_lookup_*() APIs) don't require extra priviliges. All VRRP operations are performed by using the vrrpadm command or calling the libvrrp APIs. The vrrpadm command or the APIs don't check privileges; they simply pass the command to the vrrpd daemon. Vrrpd checks the privilege of the process that sends the command in order to determine if the operation will be performed. The vrrpd daemon runs as root; any one can run the vrrpadm command or call the libvrrp APIs. But due to the privilege check performed by vrrpd, not all requested operations will be performed. When VRRP state transition occurs, if an executable with the name /etc/vrrpd/sthook. (where is the VRRP instance/group name that has the state transition) exists, it will be executed by vrrpd. It will run with the same privileges and environment as its caller, vrrpd, except the stdin, stdout and stderr are redirected to /dev/null. This means it will run as root. The security is enforced by having /etc/vrrpd/ owned by the root so only privileged users can put files into this directory. - SMF A new SMF service, svc:/network/vrrp:default, will be introduced by this project. It'll be disabled by default. Since the configuration grammar is complex (have nested structure, similar to gated's), we prefer to use a private configuration file to store the configurations, and have the location of this file as the only property of the SMF service. By default its value is /etc/vrrpd/vrrp.conf. Other guideliens listed in the "SMF usage" reference will also be followed. 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. An end user or a sysadmin can use the "vrrpadm show ..." command, provided by this project, to observe the VRRP status in the system. 7. How does the project deal with faults and interruptions? Initialization and restarting? The daemon (vrrpd) is under SMF control (svc:/network/vrrp:default). Thus, when vrrpd fails for some reason, SMF will restart it automatically; when the system boots, SMF will start it automatically. When vrrpd is (re)started, it recreates all persistent VRRP instances, whose configurations are stored in a configuration file. 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, SunCluster, etc.)? This project uses the VNIC technology to set multiple Virtual Router MAC addresses on an interface; VNICs will be created and destroyed when the vrrpd daemon is running. This requirement prevents it from working in exclusive zones. The service should work well in xVM domains. 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? Two admin tools, vrrpadm and vrrpize, are used for admin purpose. They were reviewed as part of the design review in the networking-discuss alias. * Is there a means of aggregating management and/or configuration with other related projects? No. * Does this project deliver its own administration along with the other components, or is this project an administration interface for other projects? No. * Are there any external (to Solaris) management interfaces to consider, or being consumed? There are several VRRP implementations under Linux, but their management interfaces are quite different from ours. 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/ We reviewed these two documents. We followed all guidelines listed in them. 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/ Appendix 2. Administrative access and control RBAC (Role Based Access Control): See PSARC/1997/332 Execution Profiles for Restricted Environments http://opensolaris.org/os/community/arc/caselog/1997/332 Privilege: See PSARC/2002/188 Least Privilege for Solaris http://opensolaris.org/os/community/arc/caselog/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/