@(#) LSARC Questions Version 2.0t __________________________________________________________________ Copyright (c) 1997-1999 Sun Microsystems, Inc. __________________________________________________________________ Commitment Review Name: Execution Profiles for Restricted Environments Case: PSARC 1997/332 Author: Glenn Faden 1. What specifically is the proposal that we are reviewing? 1.1 The case owner will need to put a 1 to 4 paragraph description at the top of the Opinion document. Suggest text for it. Please be specific about deliverable components and their interfaces. 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 assigning security-relevant attributes to users and roles. These attributes include lists of roles, authorizations and execution profiles. a database for defining execution profiles a database for enumerating the executables in each profile a database for defining authorizations a set of library functions for getting entries in these databases a set of restricted shells which use these functions to apply security attributes to processes when they are executed a set of predefined authorizations, and profiles which can be used to construct roles a set of commands for setting and listing user attributes a small set of traditional UNIX commands in which the superuser check has been replaced by an authorization check. nameservice extensions to support theses databases in NIS and NIS+. nameservice support for specifying the audit attributes of users and roles. additional caching in the name service cache daemon. The GUIs to manage the new databases are not part of this case. Currently, the user attributes database, user_attr, can be edited by hand, or by a commandline interfaces. New GUIs will be implemented by extending the Seabreeze (AdminSuite 3.0) product which is currently part of SEAS 3.0. This project team provided to the Seabreeze project a set of Java methods to manage the first two databases. As a result, Seabreeze currently provides a GUI for managing the authorizations defined in this project. Along with the Viper (Solaris Management Console 2) project, a framework is being built to provide GUIs for Role Based Access Control, including role assignment, role assumption, profile management, and delegation of authorization. This framework is planned for SEAS 4.0. 1.2 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 and why? (See the document in /shared/sac/doc/release.taxonomy.) This is a change to an existing product, Solaris Foundation. This should be considered a minor release. 2. What is the motivation for it? What are the expected benefits for Sun? By what criteria will you judge its success? Many customers want a system in which certain administrative tasks can be performed by users and junior administrators without granting them full superuser privilege. The ability to create to manage the capabilities of individual users and administrators is known a Role Based Access Control (RBAC). This project provides the framework for RBAC. It removes some of the dependency on the root (superuser), and allows 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. The plan: The plan is to put these features into Solaris 8. 3.1 Who (what groups in what business units) are working on it? As part of Sun Fed, we are working with Trusted Solaris development, and Government Systems marketing. We are also working with the Seabreeze(AdminSuite 3) and Viper (SMC 2) development groups which are part of the Solaris Easy Access Server consolidation. 3.2 What is the current status? Trusted Solaris, which implements RBAC, has provided a prototype for this technology. Trusted Solaris 2.5, FCS'd in July, 1997, and Trusted Solaris 2.5.1 FCS'd in August 1998. It received an FB1-E3 rating from the the ITSEC (Information Technology Security Evaluation Criteria). The PSARC inception review took place in February 1998. Since then, the databases and interfaces have been reimplemented to provide for greater extensibility. The new databases can be shared between Solaris and Trusted Solaris, and provide greater flexibility and an open-ended design for adding new attributes. The development of the databases and interfaces is complete, and are ready to be put back to Solaris 8. Man pages and test cases are available. 3.3 Has a design review been done? The design has been documented and formally reviewed by the Trusted Solaris development team. It has also been reviewed by the Seabreeze project. An engineering review senior Sun SOft engineers has also been done. 3.4 What Steering Committee do you expect to approve this project? Our first steering committee presentation took place on Friday, 11/6/98. This was a presentation to the System Software Steering Committee (SSSC), We have submitted a project plan to the Solaris Operating Environment Steering Committee (SOESC). 4. Related Projects: 4.1 What not-yet-delivered Sun projects (libraries, hardware, etc.) does this project depend upon (i.e., need to be successful)? This project is related to two one-pagers that we have submitted, each of which deals with foundation technology for an extended security policy. These projects are: PSARC 1997/331 Process Privilege Mechanism PSARC 1997/334 Security Policy Hook Architecture 4.2 What non-Sun projects does this project depend upon? None. 4.3 What other projects depend on this one? While this project is not dependent on these projects, it provides database support for new security attributes (e.g. privileges and labels) that may be plugged into the kernel. Additionally, the previously mentioned Seabreeze project depends on this case. LSARC 1998/476 Seabreeze System Management Viper plans to use the authorization and to provide the role assumption GUI. 4.4 What other active projects at Sun are related to your project, and how are they related? Trusted Solaris 8 will use these interfaces. Seabreeze currently uses the authorization framework provided by this case. Viper will be using the authorization framework and will be providing a role assumption GUI. 4.5 What future projects should be started or avoided to help your project succeed, and why? Most of the existing superuser tests in commands should be replaced with authorization checks. To provide an alternative to root-based administration, we should not be hardcoding it. Most administrative interfaces should be made authorization aware. GUIs to administer the new databases are required. They are being worked on by the Trusted Solaris, Viper, and Seabreeze teams. We have implemented a CDE-based GUI for device allocation based on authorizations that could be incorporated into BSM. 5. What technical approach has been selected by the project? The design of this project was based on the goal of providing a single set of databases and APIs that could be used by Solaris, Trusted Solaris, and other security relevant products. This project is a more flexible implementation of the RBAC system that is currently shipping with Trusted Solaris. The databases were made extensible, and the record lengths were shortened so that the data could be supported by any name service. The previous version only supported NIS+. 6. How is the project delivered into the system? Is it bundled or unbundled? Identify package abbreviations, directory names, library names, databases, etc. The plan is to deliver source code into the Solaris foundation that will become part of the standard product. Trusted Solaris will use this foundation technology to produce a security policy with more attributes than may be applicable to Solaris, by default. The package manifest is listed in pkg.manifest.txt. 7. Hardware Platform Dependencies: 7.1 What are the project's hardware platform dependencies, including Sun or third-party add-on hardware that is explicitly supported. There are no hardware platform dependencies for these project cases. It should work on all Solaris platforms. 7.2 Are Solaris components expected to work on SPARC and Intel? If not, why? What will be affected in porting? Any problems if porting to another architecture were desirable? Both SPARC and Intel are supported. 7.3 Are there issues with "binary" interfaces, which would be incompatible on various instruction set architectures? No. 8. Compatibility and Interoperability (Consider a compatibility matrix, if the information is nontrivial.) 8.1 OS compatibility: 8.1.1 For Solaris components, what Solaris release(s) does it run on or work with? This functionality has been tested on Solaris 7, but will only be delivered in Solaris 8. 8.1.2 Might the project need any extra adaptation to work successfully with future (i.e., later) releases? patches? This project does not currently support LDAP. A future LDAP backend will be needed. 8.2S Do Solaris components depend on kernel features not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional loadable kernel modules)? What packages must be installed first (if the "end user" set of packages is insufficient)? Do the packages express those dependencies explicitly? No and none. 8.3 Do Solaris components use any system interfaces, commands, or features not in X/Open CAE, Issue 4, Version 2 (ISBN 1-85912-034-2, 1-85912-036-9, 1-85912-037-7, and 1-85912-049-0, informally known as "Spec 1170" and XPG4.2)? No. 8.4 With what releases of what other projects or products does this project interoperate? Using what interfaces? (Provide reference to ARC case approving these interfaces or a specification and proposed stability classification for the interfaces.) This project currently interoperates with Seabreeze (AdminSuite 3). It shares common databases and semantics with respect to authorization. It will also interoperate with Trusted Solaris 8, which will depend on the API and databases. 8.5 What internationalization (I18n) issues are involved? What I18n levels will the project adhere to? If strings are used, how are they accessed -- Solaris-mostly gettext() or X/Open catgets()? What items are (or are not) being internationalized? The library functions are internationalized to level 4. The names of profiles are defined by an administrative role, and are not localized by Sun. Both profiles and authorizations provide help files for use in GUIs. Alternative help files are needed for the various localizations. 8.6 Are there any existing or proposed standards it conforms to or deviates from? Examples: SPARC/Intel ABI, OMG/CORBA, POSIX, SVID, XPG (X/Open Portability Guide), RFCs, national or international standards. Include version numbers. The entire project conforms to the Common Criteria Protection Profile for Role Based Access Control. This implementation will not break existing UNIX conformance tests because root will be given all authorizations. However, the system can be configured so that the root user may not be authorized to run programs that might be part of a conformance test. 8.7 Can this version co-exist or interoperate with earlier and later versions? with alternative implementations (perhaps by other vendors)? Is switching between installed versions or implementations possible? What is involved? The only earlier version is Trusted Solaris, which will provide a conversion utility. 8.8 Does the project move, disable, delete, circumvent or change any files, components, or services outside the project? The changed files are listed in pkg.manifest.txt. 8.9 Does it use any interfaces (for example, a driver using kernel structures) that are private to another consolidation? read or write /dev/kmem? trap directly into the kernel, instead of via libc functions? No. 8.10 What components (e.g., libraries or packages) are shared with other projects or products? The libraries are listed in pkg.manifest.txt. 8.11 Can customization (e.g., OEM relabeling) be accomplished via resource files that are separable from the source code? Yes. The database attributes can be extended. 8.12 Device Drivers: 8.12.1 Does this project deliver any device drivers? No. 9. Technical Content 9.1 Architecture Diagram: Include in case materials an Architecture Diagram, showing the major components, major interfaces, and all customer-visible interfaces and inter-project interfaces. Give each a number or brief name for use in the Interface Table below. The slide 332.Diagram.ps shows the relationship of the four attribute databases to each other. 9.2 Interface Table: Include in case materials an Interface Table showing all customer-visible interfaces and inter-project interfaces and significant internal interfaces (inter-subsystem and inter-invocation). The following sections ask for more detail and help "brainstorm" additional interfaces. EXPORTED INTERFACES: Proposed Specified Former Stability Interface Stability in what Classification Name Classification document? or Other Comments ------------------ ------------- -------------- -------------------- auths(1) evolving auths(1) profiles(1) evolving profiles(1) roles(1) evolving roles(1) pfsh(1) evolving pfsh(1) pfksh(1) evolving pfsh(1) pfcsh(1) evolving pfsh(1) useradd(1M) evloving useradd(1M) evolving roleadd(1M) evloving useradd(1M) evolving usermod(1M) evloving usermod(1M) evolving rolemod(1M) evloving usermod(1M) evolving userdel(1M) evloving userdel(1M) evolving roledel(1M) evloving userdel(1M) evolving auth_attr(4) evolving auth_attr(4) exec_attr(4) evolving exec_attr(4) prof_attr(4) evolving prof_attr(4) user_attr(4) evolving user_attr(4) policy.conf(4) evolving policy.conf(4) NOTE: The above databases can be extended without breaking backward compatility. kva_match(3) stable kva_match(3) getauthnam(3) stable getauthattr(3) getauthattr(3) stable getauthattr(3) setauthattr(3) stable getauthattr(3) endauthattr(3) stable getauthattr(3) free_authattr(3) stable getauthattr(3) chkauthattr(3) stable getauthattr(3) getexecattr(3) stable getexecattr(3) getexecuser(3) stable getexecattr(3) getexecprof(3) stable getexecattr(3) setexecattr(3) stable getexecattr(3) endexecattr(3) stable getexecattr(3) match_execattr(3) stable getexecattr(3) getprofnam(3) stable getprofattr(3) getprofattr(3) stable getprofattr(3) setprofattr(3) stable getprofattr(3) endprofattr(3) stable getprofattr(3) free_profattr(3) stable getprofattr(3) getusernam(3) stable getuserattr(3) getuserid(3) stable getuserattr(3) getuserattr(3) stable getuserattr(3) setuserattr(3) stable getuserattr(3) enduserattr(3) stable getuserattr(3) free_userattr(3) stable getuserattr(3) getauusernam(3) stable getauusernam(3) stable getauusernam_r(3) stable getauusernam(3) stable pam_role_auth.so.1 evolving pam_role_auths.(5) libsecdb.so.1 stable kva_match(3) IMPORTED INTERFACES: Proposed Specified in Former Stability, Interface New Stability what case no. Contract Number, Name Classification &/or document? or Other Comments ------------------ -------------- -------------- -------------------- AdminSuite 3.0 evolving LSARC 1998/476 _nss_XbyY_fgets consolidation private libc private to libc 9.3 Identify names and contents of packages, directories, libraries, databases, etc. Identify package abbreviations (SUNWxxx) and contents figuratively ("configuration command line utilities"). The package manifest is listed in pkg.manifest.txt. 9.4 Package manifest: The package manifest is listed in pkg.manifest.txt. 10. The operational environment: (Each of the following questions should be answered for every component of the project to which it applies. For example, a project with multiple Solaris applications would specify the exit status of them all. Manpages commonly present some of this information, but be sure the remaining questions are answered for those components.) 10.1 Command line or calling syntax: What options/operands are supported? There are three attribute viewing commands: auths(1), profiles(1), and roles(1). They display the attributes assigned to users. All three provide an optional list of users. profiles(1) also supports a -l option to show the contents of each profile. The existing commands: useradd(1M), usermod(1M), and userdel(1M) have been extended to support setting and removing extended attributes. In addition, three hard links have been created: roleadd(1M), rolemod(1M), and roledel(1M) which are used to maintain role attributes. See the above referenced man pages for details. There are three new shells, pfsh(1), pfcsh(1), pfksh(1). These have the same options as sh(1), csh(1), and ksh(1). The only difference is that command execution is based on attributes defined in profiles. See the pfsh(1) man page for details. 10.1.1 Is there support for standard forms, e.g. X11(7) manpage's "-display", etc.? If not, why not? The attribute commands are similar to the existing groups(1) command. The three profile shells have the same options as the base shells. 10.1.2 Are these options propagated to sub-environments? Process attributes specified in profiles are applied to processes executed by the profile shells. These attributes are passed to descendents of these processes. 10.2 Can it be included in a shell pipeline? How does it use standard input, output and error? Yes. 10.3 Environment Variables: 10.3.1 What environment variables are used? Describe values and semantics. None. 10.3.2 What is the default behavior if the environment variable is not set? None 10.3.3 What environment variables are set? None 10.4 For Solaris programs, what are their exit status values? What nonzero status values have what meanings? The attribute commands exit(1) if the username is not found in passwd(4). 10.5S Signals issued? Signals caught? (See "man(5) signal".) What are their semantics? No special signal catching routines. 10.6 Device drivers directly used (e.g. /dev/audio)? None. 10.8 Does it use any "hidden" files (filename begins with "."), system files, or temporary files? None. 10.9 Does it use any locking files? Does it use Solaris locking facilities? Yes, the extensions to cache the new databases are compatible with the existing file locking in nscd. 10.10 Can it execute remotely? In a distributed fashion? Is the user aware that the tool is executing remotely? The tools rely on the nameservice which supports remote execution. This is transparent to the user. 10.11S Solaris Libraries If you have code, include output from both "dump -Lv" and "ldd"; but note that the ARC wants to know what the project will deliver, regardless of what developers currently have. rafael:122% ldd roles libsecdb.so.1 => /usr/lib/libsecdb.so.1 libc.so.1 => /usr/lib/libc.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libcmd.so.1 => /usr/lib/libcmd.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 rafael:123% dump -Lv /usr/bin/roles /usr/bin/roles: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libsecdb.so.1 [2] NEEDED libc.so.1 [3] INIT 0x11118 [4] FINI 0x11168 [5] VERNEED 0x109d0 [6] VERNEEDNUM 0x1 [7] HASH 0x100e8 [8] STRTAB 0x106c4 [9] STRSZ 0x309 [10] SYMTAB 0x102c4 [11] SYMENT 0x10 [12] DEBUG 0 [13] FEATURE_1 PARINIT [14] PLTGOT 0x21228 [15] PLTSZ 0x84 [16] PLTREL 0x7 [17] JMPREL 0x10a2c [18] RELA 0x109f0 [19] RELASZ 0xc0 [20] RELAENT 0xc 10.11.1 What dynamic (aka "shared") libraries does it use directly or indirectly, including via dlopen/dlsym(3x)? None. However the profile shells can optionally be linked with the dynamic policy library delivered in case PSARC 1997/334 if that case is approved. 10.11.2 With what -R options will executables be built? 10.11.3 Does it use any static libraries? No. 10.11.4 What libraries does your project export? /usr/lib/secdb.so.1 11. System Administration Interfaces: 11.1 How will the project's deliverables be installed? They will be part of existing packages. 11.2 How will the project's deliverables be uninstalled? The packages are required. 11.3 How will the project's deliverables be configured and reconfigured? The databases will be edited using existing tools, e.g. vi, ypmake, nistbladm. etc. Commandline interfaces are provided for setting extended user attributes in the local user_attr file. In the future, GUIs will be provided. Seabreeze will be the foundation for the GUI based administration. 11.4 Does it need installation within any global system tables? Does your package edit existing files in a common directory /etc/pam.conf is modified. This will be in the foundation. /etc/nsswitch.conf is modified according to existing conventions. 11.5 Does your package use components of other unbundled packages? If so, how do you find those packages? No. 11.6 Can your product be installed to a client filesystem (using "pkgadd -R")? Yes. 11.7 Can your product be installed anywhere on the target system and still function (is it relocatable)? No. 11.8 Even relocatable packages may have one or two elements that *must* go in a certain place (/etc files for example). Are these "absolute" elements in the pkgmap or are they being installed with a postinstall script? If installed with a postinstall, how does the administrator check their integrity (how does pkgchk know about them)? The elements are not relocatable. 11.9 How does a new version of your package upgrade a prior version? Standard packaging is followed. 11.10 Does your package replace a filesystem object delivered by a prior package? If so, how do you inform the other package that it doesn't own this file anymore? How do you return the original package to its original state if your package is pkgrm'd? No. 11.11 Have you grouped generic functionalities that may be used by other projects into their own packages (KLG widgets, a third-party set of device drivers)? If not how do other projects know this generic functionality is installed? Are you using existing classes and libraries as far as possible? Yes. 11.12 How is it started? For a daemon: does it use inetd? If not, why not? No new daemons. 11.13 Does it use a naming service such as NIS or NIS+? Yes, NIS and NIS+ are supported. Not LDAP. 11.14 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 security attributes could be specified. This is an optional step that is only necessary for users who will be using roles and authorizations. As administrative tasks evolve, the existing profiles will need to be updated, or new profiles may be needed. New authorizations will be needed over time. The ARC will need to maintain a registry of authorizations. 11.15 Can administration be done from a remote machine? How? Editing of ASCII databases can be done remotely. No X11 GUIs. New GUIs will be Java based. 11.16 Can all GUI administration also be performed without the GUI? How? Yes, the databases are all in plain ASCII. 11.17 What command or scripting language is used? None. 11.18 Does the project include runtime licensing? How is it accomplished? No. 11.19 Are there any restrictions or other architectural effects from contractual obligations, copyright restrictions, or technology royalty structure? No. 12. The Window System/Desktop Operational Environment: 12.0 Does the project include a GUI (Graphical User Interface)? If not, say "NONE" and remove all this section's subsections. NONE. 13. Brainstorming Interfaces (exported and imported): Include in your Interface Table any of the following that apply. You may comment on them here, if you wish. 13.1 Exported Library APIs and ABIs exposed to customers These are listed in the imported interface list for question 9. 13.1.1 The name of the library libsecdb 13.1.2 The installation location for the library /usr/lib/libsecdb.so.1 13.1.3 The prefix(es) reserved for use by the library and its header files. None, but the suffix *attr is generally used. 13.1.4 The syntax and semantics of every symbol exported by the library. The man pages are referenced in question 9. 13.1.5 Compile time symbols (#defines or #ifdefs) defined by the project? None. 13.1.6 Are there any library or headerfile symbols that don't start with one of those prefixes? Yes. 13.2 Protocols (public or private, including RPCs) None. 13.3 Drag and Drop: what objects and what are the semantics? None. 13.4 ToolTalk messages None. 13.5 Files used as an interface, e.g. Resources, config files, etc.) In addition to the four databases listed in 9, there are changes to nsswitch.conf, and pam.conf. Examples are provided in the case directory. 13.6 Significant file formats, names, syntax, and semantics? None. 13.7 Interfaces to applications it interoperates or communicates with? (Perhaps pipes, shared memory.) None. 13.8 Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? Yes. New authorization names and descriptions can be added to the auth_attr file. The naming convention is similar to the Java class name registry, and should be maintained by Sun in a similar way. New key-value pairs can be specified by third parties. A registry of interpreted keywords should be maintained by Sun. In addition, new profile names and role names will typically be created by customers and/or integrators. 13.9 Other External Interfaces? 13.10 Brainstorming Significant Internal Interfaces The database lookup functions exposed in libsecdb are actually references to corresponding internal interfaces in libnsl. The internal interfaces are used for nameservice dependent implementation details. 13.14 Do any internal interfaces save state across invocations? Yes, there are enumeration interfaces to get the next matching entries of user, exec, prof, and auth attributes, and interfaces to rewind to the beginning of an enumeration. 13.15 Other Internal Interfaces? None. 14. Questions for Every Interface: 14.1 Propose the stability/commitment classification of the interface Because the databases and APIs are designed to support arbitrary lists of key-values pairs, there is no need to change either the APIs or the database formats in the future. Just in case, each database has two unused columns if we ever need them. But the preferred way to extend the attributes in each database are with new key-value pairs. 14.2 Who controls the interface (i.e., could make changes to it)? Point out any interfaces not solely controlled by Sun. Everything is owned by Sun. 14.3 Interface Specification: 14.3.1 Where is the interface specified (documented)? In addition to the man pages, there is an interface specification at http:/leahi.ebay/grp/projects/borg/ts2_458.dir/specBOOK.ps 14.3.2 Is the specification complete enough for a re-implementation? Probably. 14.3.3 Will the project deliver to customers documentation for the interface? The details of the implementation are not provided, just the public APIs and databases. However, the header files cover most of the implementation details. 14.3.4 Are the interfaces documented clearly enough for a non-Sun client to use them successfully? Yes. 14.4 Interface Versioning and Projected Evolution 14.4.1 Present Change: if any interface is an update to or replacement for a previous one, what was the stability classification of the previous version? Is this backwards-compatible? Describe any migration story to mitigate the conversion. These are new interfaces in Solaris. Trusted Solaris has an earlier design and will need conversion utilities for customers to upgrade to new Trusted Solaris systems that use these interfaces. 14.4.2 Future Evolution: Even if an interface is new, it should be prepared for evolution. How will a transition to a new version to be accomplished? What are the expected consequences to ISVs and users and administrators? What provisions are made now to minimize or manage the pain (to clients) of future evolution? This is the first version of these databases. To get the greatest value from this project, additional projects should start using authorization checks instead of superuser checks in the privileged applications. Using roles and authorizations is a new paradigm which will require some training for customers and ISVs. Until the planned GUIs are provided, there will be some ease of user issues. The interfaces and databases are stable. However, they are designed to evolve as new attributes are provided. Each database also provides a column which is in the format of a list of key-value pairs. Although a set of keynames is currently reserved, the interface provides for an arbitrary set of key-value pairs. It is up to the applications which determine which keys are significant. Applications that modify the databases, such as Seabreeze, should preserve any key-values that are not interpreted by the application. 15. Performance and Scalability: 15.1 What are the performance goals of the project? How were they evaluated (or how will they be)? On what type of test platform? How will performance regressions be identified? As these are new interfaces, the goals are soft. To get the optimal performance, the nameservice cache daemon has been modified to cache the new databases. 15.2 Are there any limits to scalability, such as a fixed-size array forcing a maximum number of clients, users, simultaneous connections, etc.? Are any data structures (e.g., kernel structures) so huge that large numbers of them are impractical? Generally there are no limits. There is a record length limitation in NIS of 1024 bytes. If the customers data exceeds this limit, ther information can be distributed into one or more execution profiles. 15.3 Resource Consumption: 15.3.1 Attempt to describe resource consumption scaling, even crudely. The only possible consumption that might be noticed is if the list of executables in the exec_attr gets very large. This is not anticipated because only privileged commands will be listed. 15.3.2 Which resources are likely to be bottlenecks? None anticipated. Network failures will affect nameservice lookups. 15.4 Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? No. 15.5 Multi-threading: What is your project's MT model? What must an MT client do to use your interface(s) safely? How does your project use threads internally? How does it expect its client to use threads? If it uses call-backs, can the called entity create a thread and recursively call back? The get*attr() functions are MT_SAFE like the similar gethostent_r(3) interface. The set*attr(3) and end*attr(3) interfaces use the same mutex locking functions as the similar interfaces sethostent(3) and endhostent(3). 15.6 What is the impact on system performance (positive or negative)? Impact may be slightly negative, but generally this is confined to new interfaces. 15.6.1 What is the average memory usage or working set of this component? Unknown. 15.6.2S How much of this is shared/sharable by other apps? The daemons nscd and nisd are shared by all clients and provide a cache of the databases. 15.7 Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? No. 15.8 Will it require large files/databases (for example, new fonts)? No. 15.9 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? No. 15.10 What are the project's effects on boot time requirements? None. However, the root role may optionally be specified as a role. If so, direct login as root is not allowed (except in single user mode). Authorized users may su(1m) to root. 16. Security (see also A.4): 16.1 What security issues do you address in your project? This project provides a set of mechanisms that offer an alternative to relying on the superuser for normal administration of the system. Therefore they provide increased security by minimizing the damage that can be done by administrators. This project provides for a distributed definition of the per-user auditing mask. The auditing mask is security relevant and cannot be read or written by normal users. In NIS it is a secure map. In NIS+ the table columns are read and write protected. The authorization mechanism is a replacement for the superuser checks in applications. The profile database and shells provide the ability to associate execution attributes, e.g. setuid and setgid with specific users. 16.2 What security concerns might customers or reviewers have? This case does not completely address the principle of least privilege. The root account is still all powerful with respect to kernel policy. 16.3 Are any components (e.g., encryption) subject to export restrictions? Why or why not? No. 17. Failure and Recovery: 17.1 How will it respond to failures? (Does it ever require reboot? No special failures are anticipated.. 17.2 How does your project deal with network failures (including partition and re-integration)? No special handling of failures. However, the nsswitch.conf setting specifies that critical accounts, like root are looked up locally, rather than relying on the network. 17.3 Can it save and restore state? No. 17.4 Can it checkpoint and recover? Can its files be corrupted by failures? Does it clean up any locks/files after crashes? Database corruption issues are the same as for any database in name switch. 18. Adaptability to a Changing World: 18.0 Are all dates "Year 2000" compliant? What, if anything, did you do to deal with Y2000 issues? No issues. 18.1 Any plans for supporting other operating systems (perhaps HP/UX, Microsoft Windows, AIX, etc.)? No. 18.2 How will it deal with issues in the 64-bit world, including 64-bit address spaces, 64-bit integers, and 64-bit files? 64 bit libraries are provided. 18.3 What is the project's relationship to CORBA/IIOP? None. 18.4 What is its relationship (or difficulties) with . . . No special difficulties. 19. Issues? Please identify the issues for which you would like ARC guidance. (e.g. Interface classification, deviations from standards, architectural conflicts, release constraints...) The GUIs for supporting these databases are not bundled with the OS. A registry of authorization names will be needed which should be maintained by the ARC. The exposure of authorization names on the man pages is a new concept for users. A convention that programmer not use superuser checks in administrative applications should be enforced by the ARC. 20. Appendices, such as: 20.1 List of exported (to customers or to other projects) and critical imported interfaces with their prior and proposed classifications. 20.2 List references to other documents (one-pager, design papers, interface contracts, etc.). Copies are to be placed in the case directory. 20.3 Comments For Us? 20.3.1 How many engineer hours went into preparation of case materials, including answering this questionnaire (that would not otherwise have been needed for other purposes)? 40 hours. 20.3.2 Do you think it was time well spent? Mostly. 20.3.3 How many engineer hours went into answering this questionnaire alone? 8 hours.