1. What specifically is the proposal that we are reviewing? Please be quite specific about deliverable components and their interfaces. 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 document in /shared/sac/doc/release.taxonomy)? This project provides a framework for breaking apart the power of the superuser into a set of building blocks called execution profiles. The profiles can, in turn, be used to implement Role Based Access Control (RBAC), and turnkey environments. The deliverables include: a database for defining profiles a database for assigning profiles to users and roles a set of library functions for getting and setting entries in these databases a set of restricted shells which use these functions to apply security attributes to processes when they are executed a GUI for constructing and maintaining profiles a GUI for assigning profiles to users and roles a set of predefined profiles and roles which replace the superuser The GUIs and the CDE library changes related to execution profiles will be presented in a separate case, probably to a different ARC. This should be considered a minor release. 2. What is the motivation for it? (In general as well as specific terms; not everyone on the ARC may be an expert in the area) What are the expected benefits for Sun? By what criteria will you judge its success? Many customers want to replace the superuser with Role Based Access Control. This project provides the framework for RBAC. It removes most of the dependency on the root (uid 0), and allows most administration to be performed by customizable roles. This reduces the level of risk that is associated with giving someone administrative responsibility. This project would be considered to be successful if it satisfied the customers' requirements for role based administration. A lesser degree of success would be that it provided the framework upon which future role based interfaces were built. 3. What is its plan? - What is its current status? - Has a design review been done? The plan is to provide these changes into Solaris next (2.8?) as soon as reasonable from an engineering and management perspective. The prototype, Trusted Solaris 2.5, FCS'd in July, 1997. The next release, Trusted Solaris 2.5.1 will FCS in summer 1998. Design documents are written -- though they include more information than is applicable to these cases (one of the case teams problems is to get the appropriate to the ARC). These documents are ``formally'' reviewed by the Trusted Solaris development team and design review meeting are held to resolve issues and coordinate interfaces (sort of like SAC). Furthermore ITSEC evaluators are reviewing all security relevant changes. The ITSEC (Information Technology Security Evaluation Criteria) evaluators are under contract to Sun Fed to help us achieve an FB1-E3 rating. 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 depend on this one? This project is related to three one-pagers that we have submitted, each of which deals with foundation technology for an extended security policy. These projects are: 1997/331 Process Privilege Mechanism 1997/333 File Privileges Sets: Storage and Retrieval 1997/334 Security Policy Hook Architecture It is dependent on these projects to provide lower level functionality. 5. What is the technical content of the project? Please provide diagrams that make the project's interfaces clear. The slide onepagefig.ps shows the relationship of profiles to roles and privileges. See the Readme file for a summary of the included files. 6. How is the project delivered into the system? Identify packages, directories, libraries, databases, ...? The plan is to deliver source code into the Solaris source base that will become an optional part of the standard product. Trusted Solaris should be viewed as the prototype for an extended security policy with more attributes than may be applicable to Solaris in general. 7. What are the project's hardware platform dependencies? Is it expected to work on SPARC and Intel (and PowerPC)? What will be affected in porting? There are no hardware platform dependencies for these project cases. Currently Trusted Solaris (the prototype) is only delivered on SPARC. However, it should work on Intel. Intel testing would be part of the integration cycle. 8. System administration: - How will the project's deliverables be installed and (re)configured? The package will be installed via pkgadd. A sample set of roles and profiles will be provided. - How will the project's deliverables be uninstalled? The project will be part of a new package. - Does it use inetd to start itself? N/A - Does it need installation within any global system tables? The profiles definitions and their assignment to users and roles are stored in two new databases. - Does it use a naming service such as NIS or NIS+? Yes. The prototype supports NIS+. NIS support will also be provided. NOTE TO PSARC: Are there other naming services services that should be supported? - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? When new users are added to the system, their set of profiles should be enumerated. As adminstrative tasks evolve, the existing profiles will need to be updated, or new profiles may be needed. 9. What is its UNIX operational environment: - Environment variables? - Exit status? Signals issued? Signals caught? (See "man(5) signal".) - Device drivers directly used (e.g. /dev/audio)? - .rc/defaults or other resource/configuration files or databases? - Does it use any "hidden" files (filename begins with ".") or temporary files? Does it use any locking files? Does it use Solaris locking facilities? - Command line or calling syntax: o What options are supported? o Does it conform to getopt() parsing requirements? o 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")? Static libraries? A new library to support profiles will be introduced. The prototype introduces libtsoldb. - Which Solaris release does it run on? - Does it depend on kernel features not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional kernel loadable modules)? This project depends on new process attributes such as privileges. 10. What is its window/desktop operational environment? This project requires a CDE desktop. 11. What are your project's other external interfaces (exported and imported)? See the man pages for getting and setting profile entries. 12. What are its other significant internal interfaces (inter-subsystem and inter-invocation)? N/A 13. How do the interfaces deal with applicable standards? N/A 14. Is the interface extensible? How is the interface expected to 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? This is the first version of the profile database. There are reserved fields to accommodate future enhancements, but like other NIS+ tables, the format is essentially fixed. 15. How do the interfaces adapt to a changing world? - Will it migrate to DOE? What will need to be added (e.g., distributed operation)? What will need to be discarded? How easy will it be to encapsulate this application (e.g., access the data via DOE interface)? - What is its relationship with (or difficulties with) multimedia? 3D desktops? Nomadic computers? A networked filesystem model (i.e., a network-wide file manager)? - What are its COSE plans? - What security issues do you address in your project? The part of the profile database which implements CDE action support is dependent on the current interface for invoking actions. 16. What internationalization issues are involved? (if strings are used, how are they accessed? The library functions are internationalized. The prototype is currently being localized for Japan. The names of profiles are defined by an adminstrative role, and not localized by Sun. 17. 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? On what type of test platform? - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? - MT is standard with Solaris 2.2. What is your project's MT model? For example, is it MT Safe? 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? - What are the project's effects on boot time requirements? Adequate benchmarks against the prototype to isolate the individual effects of the proposed cases have not been performed. 18. How does the project deal with failure and recovery? - How will it respond to failures? (Does it ever require reboot? Use of stop key? Can it lock up?) - How does your project deal with network failures (including partition and re-integration)? - Can it save/restore? Include? - Can it checkpoint and recover? Can its files be corrupted by failures? Does it clean up any locks/files after crashes? Profiles are not required in single user mode. 19. Issues? Please identify the issues which you would like the ARC to address. - Interface classification, deviations from standards, architectural conflicts, release constraints... This and the related cases would like to establish a roadmap whereby the applicable features of Trusted Solaris can be put back into standard Solaris over time. And as stated in question 2 -- architectural conflicts that would lead to an uncoordinate, incompatible way that projects a non-uniform view of Solaris to programmers, users and administrators should be addressed by the ARC. 20. Appendices: - List of exported and critical imported interfaces with their prior and proposed classifications. - One-Pager. - Prototype specification. - References to other documents. (Place copies in case directory.)