PSARC Questions Version 4.5 1. What specifically is the proposal that we are reviewing? - What is the technical content of the project? This project provides a foundation for building a Trusted Solaris layered product. Primarily it adds sensitivity labels to Solaris which are used to implement Mandatory Access Control. Unlike earlier versions of Trusted Solaris, labels will not be directly associated with traditional objects like files, devices, network interfaces, or processes. Instead, labels will be associated with Solaris zones; the resources within a zone will all share the same label. This project will provide interfaces to set and get the label of a zone, and in turn, the label of objects contained in a zone. See TSOL Evolution Slides. A default label will be applied to the global zone (the normal Solaris instance), and any normal zones. What will distinguish Trusted Solaris from Solaris will be the setting of unique labels for each zone. These label relationships will be used to enforce cross-zone Mandatory Access Control for networking, automounting, device allocation, printing, and X Windows. - 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.eng.sun.com/doc/release.taxonomy)?] This project is a major change to the existing Trusted Solaris 8 product. Major portions of the existing Trusted Solaris architecture are being redesigned to produce a layered product. Although most of the features of Trusted Solaris 8 will have counterparts in the new architecture, the proposed changes are substantial. It is intended for a micro/update release of Solaris. - If your project is an evolution of a previous project, what changed from one version to another? Although the project may be described as an evolution, the use of zones represents a fundamental change. Instead of applying explicit labels to file system objects, processes, network interfaces, etc., this project will rely on zones for containment and virtualization. Furthermore, the interfaces for managing labels will be changed to treat labels as opaque objects. This will allow the project team to change the underlying implementation of labels if necessary. - 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.) Label-based Mandatory Access Control is required by most defense and intelligence agencies. In addition, commercial environments such as banks require hardened environments that rely on Mandatory Access Control. The goal of this project is to provide such controls in a manner which is light-weight enough to be layered over Solaris. This project should be considered an umbrella case which serves as an overview of the entire project. The first step will be adding labels to zones and configuring zones which are consistent with Trusted Solaris requirements. For example, all the zones will comprise a single system image which will be centrally administered via a single name service. Follow-on projects, will provide label-aware services to meet these requirements. When all the follow-on projects are completed, a layered version of Trusted Solaris will provide essentially the same functionality as Trusted Solaris 8. For example, the plan includes support for a multilevel-secure (MLS) desktop for Sun Workstations and SunRay appliances. Trusted Solaris 8 is the dominant (only) player in the market for such systems, so this functionality must be preserved in the replacement product. - What are the expected benefits for Sun? The existing market for Trusted Solaris 8 systems is growing rapidly. At this point, Sun is the only vendor offering a complete implementation of Mandatory Access Control in a general purpose OS. Specific features like multilevel ultra-thin clients are unmatched by the competition and are bringing in significant hardware revenues for Sun. Providing a migration path for Trusted Solaris 8 customers will allow us to continue to dominate in these markets. - By what criteria will you judge its success? In addition to the normal criteria for reliability and performance, there are specific evaluation criteria which this project which must met. The completed project will be submitted for evaluation under the Common Criteria Label Security Protection Profile. We are expecting to be certified at an assurance level of EAL4+. Another important goal is to provide a migration path for existing Trusted Solaris 8 users. Therefore the new system must interoperate with existing Trusted Solaris systems in a multilevel fashion for two specific network protocols. These include the Trusted Solaris X Windows extension and the Trusted Networking extension known as the Commercial IP Security Option (CIPSO). See FIPS 188. 2. Describe how your project changes the user experience, upon installation and during normal operation. Since parts of this project will delivered in the Solaris foundation, and other parts will be unbundled, the user experience will depend on what is installed. Until the layered component is installed and configured, the user experience will be essentially unchanged. Although a few commands will be extended to support labels, they will not display label-related information by default. Man pages for these commands will list label-related options, and inform the user that the use of labels requires installation of the optional layered Trusted Solaris product. Once the layered product is installed and configured, the user experience will be similar to that provided by Trusted Solaris 8. For example, window labeling and trusted cut and paste will function in an identical manner. Most end-users will continue to use the same user interfaces without the need for retraining. However, there will be both subtle and significant differences for those users who are authorized to use administrative roles. The most obvious difference will be the lack of support for extended attributes on individual files. Unlike Trusted Solaris 8, there will no longer be support for assigning forced or allowed privileges to executable files. Nor will it be possible to assign specific file labels. Privilege specifications will be done using RBAC databases. Labels will be assigned to zones and their resources. Various Trusted Solaris administrative interfaces such as the privilege and label GUIs in the File Manager will no longer be included in the product. Commands and utilities dealing with file attributes, including multilevel directories will not be provided. In general, a process running in a zone will be unaware of processes and resources outside of the zone. - What does the user perceive when the system is upgraded from a previous release? The new product will not be upgradeable from any previous version of Trusted Solaris. Instead, it will be layered over an existing system running a recent Solaris release (probably Solaris 10). Although the user can maintain their label definitions from Trusted Solaris 8, most other databases will need to be modified because of architectural differences. Differences in virtualization, privileges, filesystems, and networking may affect how solutions are deployed. Custom applications which were written to make use the specific Trusted Solaris 8 APIs will need to be at least recompiled and possibly redesigned. 3. What is its plan? The current plan is release Trusted Solaris 10 in one or more Solaris 10 updates. Some project components will be bundled and others will be unbundled. - What is its current status? Has a design review been done? Are there multiple delivery phases? The current status is that the development team has been formed, a prototype has been built, and initial development has started. 4. Are there related projects in Sun? - 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? This project has dependencies on a variety of new Solaris 10 projects. The Process Privilege project is a replacement for the Least Privilege functionality in Trusted Solaris 8. The Solaris Virtualization and Containment Project (Zones) is a replacement for most of the MAC policy from Trusted Solaris 8. The Fire Engine project provides a new framework for implementing Trusted Networking. Other smaller projects such as Auditing in Cred, Device Allocation enhancements, and PAM enhancements also provide foundation technology for this project. - 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 will extend all of the projects mentioned above. Contracts may be required with multiple groups. For example, this project will be extending the Zones APIs and data structures. It will also be adding additional privileges to Solaris. At this point the changes to Fire Engine are still be investigated. It is important to recognize that the application of zones in this project is conceptually different from that of the Solaris Virtualization and Namespace Isolation project (PSARC 2002/174). This project does not treat zones as independent Solaris instances. Instead all zones are centrally administered from the global zone, sharing the same name service. Zones are used for label separation, but the collection of all zones on the system can be thought of as a single system image. Users may be cleared to operate in multiple zones, and will be able to view files contained in zones which they dominate. Authorized users may move data from one zone to another via the Trusted CDE Window System, or via administrative utilities. 5. How is the project delivered into the system? Various parts of the project will be delivered into ON, XW, CDE, and Admin consolidations. In addition, there will be a gate for unbundled components. Some features will be implemented as additions and enhancements to the Solaris foundation, and will rely on runtime checks to determine whether the code is executed or bypassed. In other cases, conditional compilation will be used to generate alternate versions of existing programs which will be unbundled. All of the changes to code in existing packages will be delivered as patches in one or more updates. New layered functionality will be delivered via new packages and installed via an unbundled installation tool (WebStart Wizard?) - Identify packages, directories, libraries, databases, etc. A more detailed list will be provided in individual sub-projects. However, the following summary covers the major changes. Among the alternate programs that will be built using conditional compilation include Xsun, dtwm, and dtsession. The project plans to add databases for label definitions, and for remote host and network labeling, It will extend the zone utilities (zonecfg, zoneadm, zparent) and the zone configuration database to support labels and different conventions for zone installation. User and role labels and clearances will added to the user_attr and policy.conf databases. The device allocation database will be modified to support label ranges for allocatable devices. Printer label ranges and framebuffer label ranges will also be specified. One or more new libraries will be added to support label manipulation functions. The ucred structure will be enhanced to support labels. Various CDE databases will be extended to support label specifications. In particular, the databases for saving and restoring user sessions will be reorganized to support multilevel sessions. CDE specific additions will also be made to RBAC databases. For example, idletime and label viewing defaults will be specified in the user_attr and policy.conf databases. CDE action attributes will be added to exec_attr. 6. Describe the project's hardware platform dependencies. - Explain any reasons why it would not work on both SPARC and Intel? The product will support the same SPARC and Intel platforms as normal Solaris. 7. System administration - How will the project's deliverables be installed and (re)configured? - How will the project's deliverables be uninstalled? - Does it use inetd to start itself? - Does it need installation within any global system tables? - Does it use a naming service such as NIS, NIS+ or LDAP? - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? - 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? - 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)? The parts of the project delivered with base Solaris will initially be installed as a part of a Solaris update. It will also require the installation of unbundled packages. However, the unique functionality of Trusted Solaris will not affect use of the system until labeled zones are configured. The differences in administration and operation of the system will first be apparent in the process for configuring, installing, and booting zones. Trusted Solaris will add new resource and property types to the zone configuration process. These will include the zone label, the label range of any multilevel ports within the zone, and the automount specifications for multilevel trigger mounts within zones. Unlike the convention followed by the Zones project, all the zones in Trusted Solaris will be administered from the global zone, and will share the same name server and administrative domain. Each zone will be automatically configured and booted based on a common template. There will be no sysid configuration step since each zone will be completely configured at installation time. LDAP will be the preferred name service, although all current supported Solaris name services will also be supported in Trusted Solaris. 8. Reliability, Availability, Serviceability (RAS) - Does the project make any material improvement to RAS? - 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?) - What are the project's effects on boot time requirements? - How does the project handle dynamic reconfiguration (DR) events? - What mechanisms are provided for continuous availability of service? - Does the project call panic()? Explain why these panics cannot be avoided. - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? - How does the project deal with failure and recovery? - Does it ever require reboot? If so, explain why this situation cannot be avoided. - 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? - Can it save/restore or checkpoint and recover? - Can its files be corrupted by failures? Does it clean up any locks/files after crashes? The project doesn't make any material improvements to RAS However it benefits from improvements in other projects such as Privileges and Zones. 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? - What statistics does the subsystem export, and by what mechanism? - What state information is logged? - In principle, would it be possible for a program to tune the activity of your project? TBD. 10. What are the security implications of this project? - What security issues do you address in your project? - 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? - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? - Please justify the introduction of any (all) new setuid executables. The project will meet the requirements of the Label Security Protection Profile (LSPP). It extends RBAC to include label attributes for users and roles. It also extends audit to included additional events and tokens. It extends device allocation to include support for labels. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? - Environment variables? Exit status? Signals issued? Signals caught? (See signal(3HEAD).) - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? - Does it use any "hidden" (filename begins with ".") or temp files? - Does it use any locking files? - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? - Identify and justify the requirement for any static libraries. - 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)? - 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? - 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? - Is the project internationalized and localized? - Is the project compatible with IPV6 interfaces and addresses? The project will be layered over the current Solaris release. There will be additional shared libraries in ON, XW, and CDE. There will be an additional Java service provider for the SMC. The names are TBD. The product will be I18N and L10N. 12. What is its window/desktop operational environment? - 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? The windowing environment will be an extended version of CDE with additional RBAC and multilevel features. It will also support limited use of GNOME for non-administrative single level operations. 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. "Standard", "Stable", "Evolving", etc.; see the interface taxonomy document in http://sac.eng.sun.com/doc/interface.taxonomy). Use the following format: Interfaces Imported Interface Classification Comments The_referring_standard Standard ANSI Xy.Tz 1999 draft 37 Somebody_else () Contract private Interfaces Exported Interface Classification Comments My_subroutine_name Stable MY_MACRO Project private Etc, etc, etc... - Exported public library APIs and ABIs Protocols (public or private) Drag and Drop ToolTalk Cut/Paste - Other interfaces - What other applications should it interoperate with? How will it do so? - Is it "pipeable"? How does it use stdin, stdout, stderr? - Explain the significant file formats, names, syntax, and semantics. - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? TBD. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? - Protocols (public or private) - Private ToolTalk usage - Files - Other - Are the interfaces re-entrant? Additional X protocol services provided for labeling and other security attributes. Additional network protocols for IP labeling (CIPSO for IPv4, TBD for IPv6). 15. Is the interface extensible? How will the interface evolve? - 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? Some of the previous TSOL-specific interfaces were not ARC'ed. However, the RBAC usage in this project is consistent with the extensible RBAC databases. The X protocol extensions and CIPSO protocol will be backward compatible. Most other TSOL interfaces will be changed in incompatible ways. 16. How do the interfaces adapt to a changing world? - 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)? The labeling interfaces have been changed so that the label data structure is opaque, and can evolve. 17. Interoperability - 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? The CIPSO networking extensions conform to FIPS 188 and were developed via an industry consortium. The use of the protocol is optional since labels can be associated with specific IP addresses or networks. Trusted Solaris implements a new X protocol extension for managing labels. There is no industry standard for multilevel X windows. The TSOL X extension protocol will interoperate with Trusted Solaris 8. Since the TSOL X protocol extension is not used by normal clients, any CDE, Java, or GNOME client can connect to the Trusted Solaris X server. However, they are subject to the security policy enforced by the server. The policy is generally transparent but occassionally restricts what an X client can view or modify. Remote display and XDMCP protocols will interoperate between Trusted Solaris and other UNIX systems. 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? - 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? - 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? - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? - Will it require large files/databases (for example, new fonts)? - 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? In general the performance impact for labeling will depend on how many unique labels are in use. Each label will require instantiation of a unique zone with unique services like inetd, and ToolTalk. Although all zones will share the same name service and window system, there will be additional file system and memory resources for each zone. Compared to Trusted Solaris 8, the system will have a higher overhead for instantiating the resources of each label, but will probably have lower overhead after the labeled zones have been booted. It is a goal to minimize any performance impact on Solaris when Trusted Solaris is not in use. The label translation service will be multithreaded. All public and most private labeling APIs will be MT safe. 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? The introduction of labels into Solaris is being done in a very light-weight fashion. For example, file systems are not being affected. However, even when labeling is not going to be used by the end-user, there will still be interfaces which deal with labels. Therefore we will need to explain what labels are and when they should be used. This is further complicated by the degree to which Trusted Solaris is delivered as an unbundled product. The project team has not yet determined which components will be unbundled. There are similar questions for individual programs that are being modified for Trusted Solaris. For programs which are being heavily modified, like Xsun and dtwm, we plan to use conditional compilation and produce alternate binaries. We plan to deliver the alternate binaries in TSOL-specific packages. Should we put these alternate binaries in the same directories as their standard Solaris version (with a new name) or should we put them in their own TSOL directories with the original name? There may be confusion when refering to zones which are used for server consolidation and zones which are used for label isolation. These two usage scenarios will likely appeal to different sets of customers, but may present a confusing message when common documentation is used. Interactions with other projects, like IP filter, affect the design and implementation. Support for IPv6 may be deferred based on schedule issues. No label support for NCA stack is anticipated. 20. Appendices to include - One-Pager. - Prototype specification. - References to other documents. (Place copies in case directory.)