From Gary.Winiger@Ebay Tue Feb 10 16:11:58 1998 Date: Tue, 10 Feb 1998 16:13:59 -0800 From: Gary.Winiger@Ebay (Gary Winiger) To: psarc-members@sac.eng.sun.com Subject: case 1997/332 materials Cc: jeanb@Eng, gfaden@Ebay, gww@Ebay, johnz@Ebay Content-Length: 162 The inception materials for case 1997/332 are in the incept.materials subdirectory. Please see the ReadMe file for a description of the files present. Gary.. From Gary.Winiger@Ebay Fri Feb 12 14:34:51 1999 Date: Fri, 12 Feb 1999 14:32:15 -0800 From: Gary.Winiger@Ebay (Gary Winiger) To: psarc-members@sac.eng.sun.com, brian.wong@Eng Subject: PSARC/1997/332 -- Profiles and Roles Cc: Gary.Winiger@Ebay, glenn@marduk.Ebay.Sun.COM, jerry@marduk.Ebay.Sun.COM, jz@marduk.Ebay.Sun.COM, scott@marduk.Ebay.Sun.COM Content-Length: 476 The 1997/{331,332,334} project team believe we will have commitment materials ready for review by mid to late March 1999. We wish to request scheduling of commitment review at the ARC's earliest convenience after that date. If it's necessary to hear the cases on different days, we'd request that 1997/334 be heard last. Brian, we would further request some time with the you as the case owner before hand. Gary.. P.S. I'll be on vacation till 25 Feb. From Gary.Winiger@Ebay.Sun.COM Thu Apr 1 16:59:28 1999 Date: Thu, 1 Apr 1999 16:59:19 -0800 From: Gary.Winiger@Ebay.Sun.COM (Gary Winiger) To: psarc@sac.eng.sun.com Subject: PSARC 1997/332 Cc: brian.wong@eng.sun.com Content-Type: X-sun-attachment Content-Length: 49566 ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 12 Please find attached answers to the issues from the 1997/332 commitment review of 31 Mar. 1999. In addition man pages for CLI administration are attached. The project team is presently committing resources to make the changes to user*(1M) and implement the role*(1M) interfaces and asks for feedback at the earliest convenience both on the completeness of the issues answers and the CLIs. Thanks in advance for your consideration and help, Gary.. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: issuesAnswered X-Sun-Charset: us-ascii X-Sun-Content-Lines: 261 1997/332: Execution Profiles (From whiteboard...) 1. No CLI, admin unbundled? We have amended the design to include a CLI by extending the existing useradd(1m) set of commands. 2. Securing Databases The issue is that nis can be spoofed. This is no worse than the current nis support for passwd(4). However, we will modify the user_attr(4) man page to point out that NIS+ provides better security than NIS. 3. LDAP when integrated We are working with the LDAP project, and will assist them with their putback. We expect to putback before them. 4. Common Shell The modified shells use a common backend to provide support for profiles. Otherwise, they use the same source files as the standard shells from which they are derived. See also sz-1 below. Issues for 03/31/99 Commitment Review Note: "*" after "sz-N" indicates more important, "-" indicates trivia sz-1. 20q4.1: Does this project *depend on* 1997/331 and 1997/334? It says "related to", and 20q10.11.1 suggests at least one of them may be optional. This project can be putback without 1997/331 OR 1997/334. However, if 1997/334 is approved, the profile related changes to the shells will employ the dynamic hook mechanism from 1997/334. When process attributes (1997/331) are available, they will be specified using these databases. sz-2.* 20q8.1.2/20q11.13: Should LDAP support be a TCR? See question 3 above. sz-3.* 20q8.5: I18N for help files? Alternate (localized) help files are looked up by the administrative tools (e.g., Seabreeze), by creating a pathname which includes the locale as a directory component. sz-4.* 20q13.8/20q19: Registry of interpreted keywords/authorization names Are these the same things (I think not). Better to use unique prefix (stock symbol, domain name), except for those defined by Sun. Authorizations and keywords are different. authorizations will be made unique by prepending them with the reverse order domain name of the provider. therefore sun does not need to maintain a registry of 3rd party authorizations. However, the wildcard matching rules should be considered when naming authorizations. Keywords created outside of Sun should have a unique prefix. The project team will act as a registry agent for Sun (unless someone else want to do so ;-). sz-5.- 20q14.4.2: "... requires some training for customers and ISVs" AND Sun's own developers. Agreed. sz-6. 20q19: GUIs not bundled with the OS: Is this acceptable? We would prefer a bundled GUI. sz-7. exec_attr(4): Numeric ids only? The gui will only store numeric ids, but user and group names will also be allowed. sz-8. {gatauthnam(3), getexecattr(3), getusernam(3)} vs. getauusernam(3) Why does getauusernam require special MT-save variants (*_r()), when the others don't? The new functions are all MT-Safe, so they don't need *_r to distinguish them from old forms. sz-9. makedbm(1M): "rest of the line is the data" 1. Including the delimiter? Should be able to skip all delimiters. 2. TAB or SPACE as default delimiter: should be generic "whitespace". 3. Is YP_INTERDOMAIN a special *key* (with no value)? 4. What is the format of the date in yp_last_modified? We apologize for not change baring the man page. Only the options -S, -E, and -D are new. The above questions refer to existing functionality. sz-10.* Names of commands too generic? profiles(1), roles(1) These names were chosen because they match the keywords. sz-11. device_allocate(4): "*" is counter-intuitive "*" should mean no explicit auth is needed. Also, "leading and trailing blanks" should be "whitespace" Agreed. But this is the way BSM already works. sz-12.- AdminAuths.properties "Management application authorization attribute definitions" Five nouns (or nouns used as adjectives) in a row! Imparsible :-) This text comes from the seabreeze project :-) ar-0: A word of intro would help: what is the difference between giving someone permission to run the "date" command as root and giving them the com.sun.system.date authorization? Maybe the authorization should be com.sun.system. in general? How does a sys admin decide which way to go when setting up a system? The choice of using authorizations or not, isn't up to the administrator. It is based on whether the source code is modified to check authorizations. If so, then the man page will say so, and the admin will know what to do. For unmodified commands, which are not currently setuid, the required uids should be specified in a profile entry. ar-1: auth_attr man page: your "convention" on the name field has some magic to it (i.e. the word "grant"). I think you should either word the man page more strongly or implement the "grant" feature differently. The wording on the man page will be improved. ar-2: Where does file.html live when you list "help=file.html"? See sz-3 above. ar-3: exec_attr man page: the "id field" identifies a command -- does that mean a path to a binary, or a binary with arguments, or...? The former (we will clarify the man page). However, the arguments could be specified in a shellscript and then the shellscript could be specified as the id. ar-4: From my sys admin days: the most common problem we had is we wanted an admin to be able to run "edquota" but not be able to run root commands by typing ":!" inside vi. How do you address this? We addressed this in Trusted Solaris by providing modified versions of vi and dtpad. These changes are not part of this case. ar-5: kva_match man page: generic mechanism, neh? Should it be in libsecdb? This function is specific to the kva_t structure, and is not generic. ar-6: makedbm man page: what changed from existing makedbm man page? See sz-9 above. ar-nit: prof_attr man page: example is missing a colon before "help=". Will fix. 25. Admin experience: out of the box without Seabreeze... By default, the behavior will be identical to previous versions of Solaris. Root will be all powerful, and no roles will be assigned. 26. Profile Shell without the Filesystem Project. Currently there is no dependency. In the future, when privileges are provided in the file system and for processes, a version of these shells will have forced privileges stored as file attributes. 27. NIS Spoofing See (2) above. 28. Names of authorizations: Solaris, sol, sunw, etc. See sz-4 above. However, if for OEM purposes Solaris or sol should be picked, please make this a TCR and coordinate with LSARC 1998/476 Seabreaze. 29. /etc/security and other uses of auth_attr We believe you meant user_attr. The file user_attr will be moved from /etc/security to /etc. The other 3 databases will stay in /etc/security. 30. help files in distributed environment (cross consolidations)? We have filed bugs against seabreeze to support both local (file://) and remote (http://) forms of URLs, and to provide a helppath for specifying multiple directories. See bug 4217816. 31. Actual goal of this project vs. possible relation to other cases. This project provides rudimentary role-based access control. When the other referenced projects are approved, we will provide better support for the principle of least privilege. 32. Relation to other OS Vendor efforts. The X/Open Single Sign-on Service (XSSO) refers to account management services in Appendix D1. This case provides conformance. The Common Criteria Protection Profile for Role_Based Access Control (RBAC) provides additional requirements to which this case conforms. 33. Key-value database owner. See sz-4 above. 34. RESERVED FIELD In the final version of the databases the reserved fields will be empty. 35. /etc/default/policy We have renamed this database to /etc/security/policy.conf. The 1997/334 case is sharing this file and will provide a man page describing their additional use of the file. 36. Non-reentrant routines See sz-8 above. 37. kva -> keyval in kva_match(3). If the arc requires this change, we will make it. 38. Interop for role entries in password Roles and user accounts are interoperable. A user account can be turned into a role creating a user_attr entry and setting its type to role (or by changing an existing user_attr entry). For example, root can be specified as a role. 39. A Roles section in man pages. Since roles are not hard coded we won't be identifying them by name in man pages. However, when functionality is different for roles, such as in logging in, we will point out the difference. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: useradd.1M X-Sun-Charset: us-ascii X-Sun-Content-Lines: 199 Maintenance Commands useradd(1M) NAME useradd - administer a new user login on the system SYNOPSIS useradd [ -c comment ] [ -d dir ] [ -e expire ] [ -f inactive ] [ -g group ] [ -G group [, group...]] [ -m [ -k skel_dir ]] [ -u uid [ -o]] [ -s shell ] [ -A authorization [, authorization ...]] | [ -P profile [, profile ...]] | [ -R role [, role ...]] login | useradd -D [ -b base_dir ] [ -e expire ] [ -f inactive ] [ -g group ] [ -A authorization [, authorization ...]] | [ -P profile [, profile ...]] | [ -R role [, role ...]] | DESCRIPTION useradd adds a new user entry to the /etc/passwd and /etc/shadow files. If -A, -P, or -R is specified, an entry for the user | is added to the /etc/user_attr file. | It also creates supplementary group memberships for the user (-G option) and creates the home directory (-m option) for the user if requested. The new login remains locked until the passwd(1) command is exe- cuted. Specifying useradd -D with the -g, -b, -f, -e, -A, -P, or | -R options (or | any combination of these) sets the default values for the respective fields. See the -D option below. Subsequent useradd commands without the -D option use these arguments. The system file entries created with this command have a limit of 512 characters per line. Specifying long arguments to several options may exceed this limit. The login field (login) is a string no more than eight bytes consisting of characters from the set of alphabetic charac- ters, numeric characters, period (.), underscore (_), and hypen (-). The first character should be alphabetic and the field should contain at least one lower case alphabetic character. A warning message will be written if these res- trictions are not met. A future Solaris release may refuse to accept login fields that do not meet these requirements. The login field must contain at least one character and must not contain a colon (:) or a newline (\n). OPTIONS -c comment Any text string. It is generally a short description of the login, and is currently used as the field for the user's full name. This information is stored in the user's /etc/passwd entry. -d dir The home directory of the new user. It defaults to base_dir/login, where base_dir is the base directory for new login home directories and login is the new login name. -e expire Specify the expiration date for a login. After this date, no user will be able to access this login. expire is a date entered in any format you like (except a Julian date). If the date format that you choose includes spaces, it must be quoted. For example, you may enter 10/6/90 or "October 6, 1990". A null value (" ") defeats the status of the expired date. This option is useful for creating temporary logins. -f inactive The maximum number of days allowed between uses of a login ID before that login ID is declared invalid. Normal values are positive integers. A value of 0 defeats the status. -g group An existing group's integer ID or character- string name. Without the -D option, it defines the new user's primary group membership and defaults to the default group. You can reset this default value by invoking useradd -D -g group. -G group An existing group's integer ID or character- string name. It defines the new user's supple- mentary group membership. Duplicates between group with the -g and -G options are ignored. No more than NGROUPS_MAX groups may be speci- fied. -A authorization One or more comma separated authorizations | defined in auth_attr(4). Only a user who has | "grant" rights to the "authorization" may assign | it to a user. | -P profile One or more comma-separated execution profiles | defined in prof_attr(4). | -R role One or more comma-separated role names defined in | user_attr(4). | -k skel_dir A directory that contains skeleton information (such as .profile) that can be copied into a new user's home directory. This directory must already exist. The system provides the /etc/skel directory that can be used for this purpose. -m Create the new user's home directory if it does not already exist. If the directory already exists, it must have read, write, and execute permissions by group, where group is the user's primary group. -s shell Full pathname of the program used as the user's shell on login. It defaults to an empty field causing the system to use /bin/sh as the default. The value of shell must be a valid executable file. -u uid The UID of the new user. This UID must be a non-negative decimal integer below MAXUID as defined in . The UID defaults to the next available (unique) number above the highest number currently assigned. For example, if UIDs 100, 105, and 200 are assigned, the next default UID number will be 201. (UIDs from 0-99 are reserved by SunOS for future applications.) -o This option allows a UID to be duplicated (non- unique). -D Display the default values for group, base_dir, skel_dir, shell, inactive, and expire. When used with the -g, -b, -f, -e, -A, -P, or -R | options, the -D option sets the default values for the specified fields. The default values are: group other (GID of 1) base_dir /home skel_dir /etc/skel shell /bin/sh inactive 0 expire Null (unset). authorizations Null | profiles All | roles Null | -b base_dir The default base directory for the system if -d dir is not specified. base_dir is concatenated with the user's login to define the home direc- tory. If the -m option is not used, base_dir must exist. FILES /etc/passwd system password file /etc/shadow system file containing role's encrypted passwords and related information /etc/group system file containing group definitions /etc/user_attr system file containing additional user attributes. | /etc/datemsk system file of date formats /etc/skel /usr/include/limits.h ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: __________________________________ | ATTRIBUTE TYPE| ATTRIBUTE VALUE| |__________________________________ | Availability | SUNWcsu | |_______________|_________________| SEE ALSO passwd(1), users(1B), groupadd(1M), groupdel(1M), groupmod(1M), grpck(1M), logins(1M), pwck(1M), userdel(1M), usermod(1M), passwd(4), attributes(5) roles(1), profiles(1), auths(1), auth_attr(4), user_attr(4), | prof_attr(4) | DIAGNOSTICS In case of an error, useradd prints an error message and exits with a non-zero status. NOTES The useradd utility add definitions only in the local /etc/group, /etc/passwd, /etc/shadow and /etc/user_attr files. If a network | nameservice such as NIS or NIS+ is being used to supplement the local files with additional entries, useradd cannot change information supplied by the network nameservice. However useradd will verify the uniqueness of user name and user ID against the external nameservice. The useradd utility uses the /etc/datemsk file, available with SUNWaccr, for date formatting. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: userdel.1M X-Sun-Charset: us-ascii X-Sun-Content-Lines: 75 Maintenance Commands userdel(1M) NAME userdel - delete a user's login from the system SYNOPSIS userdel [ -r ] login DESCRIPTION The userdel utility deletes a user's login from the system and makes the appropriate login-related changes to the sys- tem file and file system. OPTIONS The following options are supported: -r Remove the user's home directory from the system. This directory must exist. The files and directories under the home directory will no longer be accessible follow- ing successful execution of the command. OPERANDS The following operands are supported: login An existing login name to be deleted. EXIT STATUS The following exit values are returned: 0 Success. 2 Invalid command syntax. A usage message for the user- del command is displayed. 6 The login to be removed does not exist. 8 The login to be removed is in use. 10 Cannot update the /etc/group or /etc/user_attr file but the | login is removed from the /etc/passwd file. 12 Cannot remove or otherwise modify the home directory. FILES /etc/passwd system password file /etc/shadow system file contain users' encrypted passwords and related information /etc/group system file containing group definitions /etc/user_attr system file containing additional user attributes | ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: __________________________________ | ATTRIBUTE TYPE| ATTRIBUTE VALUE| |__________________________________ | Availability | SUNWcsu | |_______________|_________________| SEE ALSO passwd(1), users(1B), groupadd(1M), groupdel(1M), groupmod(1M), logins(1M), useradd(1M), usermod(1M), passwd(4), attributes(5) roles(1), profiles(1), auths(1), user_attr(4), prof_attr(4) | NOTES The userdel utility only deletes a user definition that is in the local /etc/group, /etc/passwd, /etc/shadow, and /etc/user_attr file. If a network name service | such as NIS or NIS+ is being used to supplement the local /etc/passwd file with additional entries, userdel cannot change information supplied by the network name service. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: usermod.1M X-Sun-Charset: us-ascii X-Sun-Content-Lines: 194 Maintenance Commands usermod(1M) NAME usermod - modify a user's login information on the system SYNOPSIS usermod [ -u uid [ -o ] ] [ -g group ] [ -G group [ , group ... ] ] [ -d dir [ -m ] ] [ -s shell ] [ -c comment ] [ -l new_logname ] [ -f inactive ] [ -e expire ] [ -A authorization [, authorization ...]] | [ -P profile [, profile ...]] | [ -R role [, role ...]] login | DESCRIPTION The usermod utility modifies a user's login definition on the system. It changes the definition of the specified login and makes the appropriate login-related system file and file system changes. The system file entries created with this command have a limit of 512 characters per line. Specifying long arguments to several options may exceed this limit. OPTIONS The following options are supported: -u uid Specify a new UID for the user. It must be a non-negative decimal integer less than MAXUID as defined in . Note that the UID associated with the user's home directory is not modified with this option; a user will not have access to their home directory until the UID is manually reassigned using chown(1M). -o This option allows the specified UID to be duplicated (non-unique). -g group Specify an existing group's integer ID or character-string name. It redefines the user's primary group membership. -G group Specify an existing group's integer "ID" "," or character string name. It redefines the user's supplementary group membership. Duplicates between group with the -g and -G options are ignored. No more than NGROUPS_UMAX groups may be specified as defined in . -A authorization One or more comma separated authorizations | defined in auth_attr(4). Only a user who has | "grant" rights to the "authorization" may assign | it to a user. This replaces any existing | authorization setting. | -P profile One or more comma-separated execution profiles | defined in prof_attr(4). This replaces any existing | profile setting. | -R role One or more comma-separated role names defined in | user_attr(4). This replaces any existing role setting. | -d dir Specify the new home directory of the user. It defaults to base_dir/login, where base_dir is the base directory for new login home directories, and login is the new login. -m Move the user's home directory to the new directory specified with the -d option. If the directory already exists, it must have permissions read/write/execute by group, where group is the user's primary group. -s shell Specify the full pathname of the program that is used as the user's shell on login. The value of shell must be a valid executable file. -c comment Specify a comment string. comment can be any text string. It is generally a short description of the login, and is currently used as the field for the user's full name. This information is stored in the user's /etc/passwd entry. -l new_logname Specify the new login name for the user. The new_logname argument is a string no more than eight bytes consisting of characters from the set of alphabetic characters, numeric charac- ters, period (.), underline (_), and hypen (-). The first character should be alpha- betic and the field should contain at least one lower case alphabetic character. A warn- ing message will be written if these restric- tions are not met. A future Solaris release may refuse to accept login fields that do not meet these requirements. The new_logname argument must contain at least one character and must not contain a colon (:) or NEWLINE (\n). -e expire Specify the future date on which a login can no longer be used; after this date, no user will be able to access this login. This option is useful for creating temporary logins. You may type the value of the argu- ment expire (which is a date) in any format you like (except a Julian date). For exam- ple, you may enter 10/6/90 or October 6, 1990. A value of `` '' defeats the status of the expired date. -f inactive Specify the maximum number of days allowed between uses of a login ID before that login ID is declared invalid. Normal values are positive integers. A value of 0 defeats the status. OPERANDS The following operands are supported: login An existing login name to be modified. EXIT STATUS In case of an error, usermod prints an error message and exits with one of the following values: 2 The command syntax was invalid. A usage message for the usermod command is displayed. 3 An invalid argument was provided to an option. 4 The uid given with the -u option is already in use. 5 The password files contain an error. pwconv(1M) can be used to correct possible errors. See passwd(4). 6 The login to be modified does not exist, the group does not exist, or the login shell does not exist. 8 The login to be modified is in use. 9 The new_logname is already in use. 10 Cannot update the /etc/group or /etc/user_attr file. | Other update requests will be implemented. 11 Insufficient space to move the home directory (-m option). Other update requests will be implemented. 12 Unable to complete the move of the home directory to the new home directory. FILES /etc/passwd system password file /etc/shadow system file containing users' encrypted passwords and related information /etc/group system file containing group definitions /etc/user_attr system file containing additional role attributes. | /etc/datemsk system file of date formats ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: __________________________________ | ATTRIBUTE TYPE| ATTRIBUTE VALUE| |__________________________________ | Availability | SUNWcsu | |_______________|_________________| SEE ALSO passwd(1), users(1B), chown(1M), groupadd(1M), groupdel(1M), groupmod(1M), logins(1M), pwconv(1M), useradd(1M), roles(1), profiles(1), auths(1), auth_attr (4), user_attr(4), | prof_attr(4) | NOTES The usermod utility modifies definitions only in the local /etc/group, /etc/passwd, /etc/shadow and /etc/user_attr files. | If a network nameservice such as NIS or NIS+ is being used to supplement the local files with additional entries, usermod cannot change information supplied by the network nameservice. However usermod will verify the uniqueness of user name and user ID against the external nameservice. The usermod utility uses the /etc/datemsk file, available with SUNWaccr, for date formatting. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: roleadd.1M X-Sun-Charset: us-ascii X-Sun-Content-Lines: 185 Maintenance Commands roleadd(1M) NAME roleadd - administer a new role on the system SYNOPSIS roleadd [ -c comment ] [ -d dir ] [ -e expire ] [ -f inactive ] [ -g group ] [ -G group [, group ...]] [ -m [ -k skel_dir ]] [ -u uid [ -o]] [ -s shell ] [ -A authorization [, authorization ...]] [ -P profile [, profile ...]] role roleadd -D [ -b base_dir ] [ -e expire ] [ -f inactive ] [ -g group ] [ -A authorization [, authorization ...]] [ -P profile [, profile ...]] DESCRIPTION roleadd adds a new role entry to the /etc/passwd, /etc/shadow, and /etc/user_attr files. It also creates supplementary group memberships for the role (-G option) and creates the home directory (-m option) for the role if requested. The new role remains locked until the passwd(1) command is executed. Specifying roleadd -D with the -g, -b, -f, -e, -A, or -P options (or any combination of these) sets the default values for the respective fields. See the -D option below. Subsequent roleadd commands without the -D option use these arguments. The system file entries created with this command have a limit of 512 characters per line. Specifying long arguments to several options may exceed this limit. The role field (role) is a string no more than eight bytes consisting of characters from the set of alphabetic charac- ters, numeric characters, period (.), underscore (_), and hypen (-). The first character should be alphabetic and the field should contain at least one lower case alphabetic character. A warning message will be written if these res- trictions are not met. A future Solaris release may refuse to accept role fields that do not meet these requirements. The role field must contain at least one character and must not contain a colon (:) or a newline (\n). OPTIONS -c comment Any text string. It is generally a short description of the role. This information is stored in the role's /etc/passwd entry. -d dir The home directory of the new role. It defaults to base_dir/role, where base_dir is the base directory for new role home directories and role is the new role name. -e expire Specify the expiration date for a role. After this date, no user will be able to assume this role. expire is a date entered in any format you like (except a Julian date). If the date format that you choose includes spaces, it must be quoted. For example, you may enter 10/6/90 or "October 6, 1990". A null value (" ") defeats the status of the expired date. This option is useful for creating temporary roles. -f inactive The maximum number of days allowed between uses of a role ID before that role ID is declared invalid. Normal values are positive integers. A value of 0 defeats the status. -g group An existing group's integer ID or character- string name. Without the -D option, it defines the new role's primary group membership and defaults to the default group. You can reset this default value by invoking roleadd -D -g group. -G group An existing group's integer ID or character- string name. It defines the new role's supple- mentary group membership. Duplicates between group with the -g and -G options are ignored. No more than NGROUPS_MAX groups may be speci- fied. -A authorization One or more comma separated authorizations defined in auth_attr(4). Only a user who has "grant" rights to the "authorization" may assign it to a role. -P profile One or more comma-separated execution profiles defined in prof_attr(4). -k skel_dir A directory that contains skeleton information (such as .profile) that can be copied into a new role's home directory. This directory must already exist. The system provides the /etc/skel directory that can be used for this purpose. -m Create the new role's home directory if it does not already exist. If the directory already exists, it must have read, write, and execute permissions by group, where group is the role's primary group. -s shell Full pathname of the program used as the role's shell on assumption. It defaults to an empty field causing the system to use /bin/pfsh as the default. The value of shell must be a valid executable file. -u uid The UID of the new role. This UID must be a non-negative decimal integer below MAXUID as defined in . The UID defaults to the next available (unique) number above the highest number currently assigned. For example, if UIDs 100, 105, and 200 are assigned, the next default UID number will be 201. (UIDs from 0-99 are also available for roles). -o This option allows a UID to be duplicated (non- unique). -D Display the default values for group, base_dir, skel_dir, shell, inactive, expire, authorization, and profile. When used with the -g, -b, -f, -e, -A, or -P options, the -D option sets the default values for the specified fields. The default values are: group other (GID of 1) base_dir /home skel_dir /etc/skel shell /bin/pfsh inactive 0 expire Null (unset). authorization Null profile All -b base_dir The default base directory for the system if -d dir is not specified. base_dir is concatenated with the role name to define the home direc- tory. If the -m option is not used, base_dir must exist. FILES /etc/passwd system password file /etc/shadow system file containing role's encrypted passwords and related information /etc/group system file containing group definitions /etc/user_attr system file containing additional role attributes. /etc/datemsk system file of date formats /etc/skel /usr/include/limits.h ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: __________________________________ | ATTRIBUTE TYPE| ATTRIBUTE VALUE| |__________________________________ | Availability | SUNWcsu | |_______________|_________________| SEE ALSO passwd(1), users(1B), groupadd(1M), groupdel(1M), roles(1), auths(1), groupmod(1M), grpck(1M), pwck(1M), userdel(1M), usermod(1M), passwd(4), auth_attr(4), prof_attr(4), user_attr(4), attributes(5) DIAGNOSTICS In case of an error, roleadd prints an error message and exits with a non-zero status. NOTES The roleadd utility modifies definitions only in the local /etc/group, /etc/passwd, /etc/shadow and /etc/user_attr files. If a network nameservice such as NIS or NIS+ is being used to supplement the local files with additional entries, roleadd cannot change information supplied by the network nameservice. However roleadd will verify the uniqueness of role name and user ID against the external nameservice. The roleadd utility uses the /etc/datemsk file, available with SUNWaccr, for date formatting. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: roledel.1M X-Sun-Charset: us-ascii X-Sun-Content-Lines: 73 Maintenance Commands roledel(1M) NAME roledel - delete a role from the system SYNOPSIS roledel [ -r ] role DESCRIPTION The roledel utility deletes a role from the system and makes the appropriate role-related changes to the system file and file system. It removes the role from each user's list of assumable roles. OPTIONS The following options are supported: -r Remove the role's home directory from the system. This directory must exist. The files and directories under the home directory will no longer be accessible follow- ing successful execution of the command. OPERANDS The following operands are supported: role An existing role name to be deleted. EXIT STATUS The following exit values are returned: 0 Success. 2 Invalid command syntax. A usage message for the roledel command is displayed. 6 The role to be removed does not exist. 8 The role to be removed is in use. 10 Cannot update the /etc/group or /etc/user_attr file but the role is removed from the /etc/passwd file. 12 Cannot remove or otherwise modify the home directory. FILES /etc/passwd system password file /etc/shadow system file contain role's encrypted passwords and related information /etc/group system file containing group definitions /etc/user_attr system file containing additional role attributes. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: __________________________________ | ATTRIBUTE TYPE| ATTRIBUTE VALUE| |__________________________________ | Availability | SUNWcsu | |_______________|_________________| SEE ALSO passwd(1), users(1B), groupadd(1M), groupdel(1M), groupmod(1M), logins(1M), useradd(1M), usermod(1M), passwd(4), user_attr(4), attributes(5) NOTES The roledel utility only deletes a role definition that is in the local /etc/group, /etc/passwd, /etc/shadow and /etc/user_attr file. If a network name service such as NIS or NIS+ is being used to supplement the local files with additional entries, roledel cannot change information supplied by the network name service. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: rolemod.1M X-Sun-Charset: us-ascii X-Sun-Content-Lines: 184 Maintenance Commands rolemod(1M) NAME rolemod - modify a role's information on the system SYNOPSIS rolemod [ -u uid [ -o ] ] [ -g group ] [ -G group [ , group ... ] ] [ -d dir [ -m ] ] [ -s shell ] [ -c comment ] [ -l new_rolename ] [ -f inactive ] [ -e expire ] [ -A authorization [, authorization ...]] [ -P profile [, profile ...]] role DESCRIPTION The rolemod utility modifies a role's definition on the system. It changes the definition of the specified role and makes the appropriate role-related system file and file system changes. The system file entries created with this command have a limit of 512 characters per line. Specifying long arguments to several options may exceed this limit. OPTIONS The following options are supported: -u uid Specify a new UID for the role. It must be a non-negative decimal integer less than MAXUID as defined in . Note that the UID associated with the role's home directory is not modified with this option; a role will not have access to their home directory until the UID is manually reassigned using chown(1M). -o This option allows the specified UID to be duplicated (non-unique). -g group Specify an existing group's integer ID or character-string name. It redefines the role's primary group membership. -G group Specify an existing group's integer "ID" "," or character string name. It redefines the role's supplementary group membership. Duplicates between group with the -g and -G options are ignored. No more than NGROUPS_UMAX groups may be specified as defined in . -A authorization One or more comma separated authorizations defined in auth_attr(4). Only a user who has "grant" rights to the "authorization" may assign it to a role. This list replaces any existing authorization setting. -P profile One or more comma-separated execution profiles defined in prof_attr(4). This replaces any existing profile setting. -d dir Specify the new home directory of the role. It defaults to base_dir/role, where base_dir is the base directory for new role home directories, and role is the new role name. -m Move the role's home directory to the new directory specified with the -d option. If the directory already exists, it must have permissions read/write/execute by group, where group is the role's primary group. -s shell Specify the full pathname of the program that is used as the role's shell on assumption. The value of shell must be a valid executable file. -c comment Specify a comment string. comment can be any text string. It is generally a short description of the role. This information is stored in the role's /etc/passwd entry. -l new_rolename Specify the new role name for the role. The new_rolename argument is a string no more than eight bytes consisting of characters from the set of alphabetic characters, numeric charac- ters, period (.), underline (_), and hypen (-). The first character should be alpha- betic and the field should contain at least one lower case alphabetic character. A warn- ing message will be written if these restric- tions are not met. A future Solaris release may refuse to accept role fields that do not meet these requirements. The new_rolename argument must contain at least one character and must not contain a colon (:) or NEWLINE (\n). -e expire Specify the future date on which a role can no longer be used; after this date, no user will be able to assume this role. This option is useful for creating temporary roles. You may type the value of the argu- ment expire (which is a date) in any format you like (except a Julian date). For exam- ple, you may enter 10/6/90 or October 6, 1990. A value of `` '' defeats the status of the expired date. -f inactive Specify the maximum number of days allowed between uses of a role ID before that role ID is declared invalid. Normal values are positive integers. A value of 0 defeats the status. OPERANDS The following operands are supported: role An existing role name to be modified. EXIT STATUS In case of an error, rolemod prints an error message and exits with one of the following values: 2 The command syntax was invalid. A usage message for the rolemod command is displayed. 3 An invalid argument was provided to an option. 4 The uid given with the -u option is already in use. 5 The password files contain an error. pwconv(1M) can be used to correct possible errors. See passwd(4). 6 The role to be modified does not exist, the group does not exist, or the role shell does not exist. 8 The role to be modified is in use. 9 The new_rolename is already in use. 10 Cannot update the /etc/group or /etc/user_attr file. Other update requests will be implemented. 11 Insufficient space to move the home directory (-m option). Other update requests will be implemented. 12 Unable to complete the move of the home directory to the new home directory. FILES /etc/passwd system password file /etc/shadow system file containing role's encrypted passwords and related information /etc/group system file containing group definitions /etc/user_attr system file containing additional role attributes. /etc/datemsk system file of date formats ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: __________________________________ | ATTRIBUTE TYPE| ATTRIBUTE VALUE| |__________________________________ | Availability | SUNWcsu | |_______________|_________________| SEE ALSO passwd(1), roles(1), chown(1M), groupadd(1M), groupdel(1M), groupmod(1M), logins(1M), pwconv(1M), roleadd(1M), roledel(1M), auth_attr(4), prof_attr(4), user_attr(4), attributes(5) NOTES The rolemod utility modifies definitions only in the local /etc/group, /etc/passwd, /etc/shadow and /etc/user_attr files. If a network nameservice such as NIS or NIS+ is being used to supplement the local files with additional entries, rolemod cannot change information supplied by the network nameservice. However rolemod will verify the uniqueness of role name and user ID against the external nameservice. The rolemod utility uses the /etc/datemsk file, available with SUNWaccr, for date formatting. From blw@chessie Mon Apr 12 13:36:26 1999 Date: Mon, 12 Apr 1999 13:34:38 -0700 (PDT) From: Brian Wong Subject: 1997/332: Execution Profiles for Restricted Environments To: psarc@sac Cc: glenn.faden@ebay, gary.winiger@ebay Content-Type: text X-Sun-Text-Type: ascii Content-Length: 14375 Please review by 4/16. Postscript in the case directory. sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Execution Profiles for Restricted Environ- ments Submitted by: Glenn Faden, Gary Winiger File: PSARC/1997/332/opinion.ms Date: April 9, 1999 Committee: Brian Wong, Ralph Campbell, Joseph Kowalski, Tim Marsland, David Robinson, Andy Rudoff, Steve Zucker Steering Committee: Solaris Operating Environment Steering Com- mittee (soesc@sac.eng) 1. Summary This project provides the ability to assign arbitrary sets of attributes to users and roles. Attributes specify which accounts are roles, which roles are granted to users, and the specific authorizations and execution profiles which have been granted to an account. In addition, new attri- butes can be defined without any changes to the API. A role is a type of shared account which can only be accessed through a secondary login mechanism such as su(1M), and is only available to specified users. An authorization is a right granted to a user or role to perform a function which is not generally allowed. Trusted applications check that a user (or role) is authorized before performing restricted operations. A profile is a bundling mechanism that contains the list of commands and authorizations required to perform a particular function. For each command, the profile may specify the effective user id and/or the effective group id to be used when executing the command. Authorizations and commands from multiple profiles are additive. Assigning a profile to a role allows users who can assume that role to perform specific privileged operations without giving users access to all superuser powers. For example, a user might be able to administer the printer subsystem, but not add users or change the password of other users. This project provides a CLI for assigning roles, PSARC/1997/332 Copyright 1999 Sun Microsystems - 2 - authorizations, and profiles to users and a "C" API, the data structures and database formats, and conventions for using authorizations, roles, and profiles. 2. Decision & Precedence Information This project is approved as specified in reference [1]. This project may be delivered in a minor release of Solaris. This project and the following project are required to coor- dinate to ensure that the databases introduced by this pro- ject are available through LDAP. PSARC/1998/361 Native LDAP 3. Interfaces The project exports the following interfaces. _________________________________________________________ | Interfaces Exported | |__________________|________________|___________________| |Interface | Classification| Comments | |__________________|________________|___________________| |auths(1) | evolving | | |profiles(1) | evolving | | |roles(1) | evolving | | |pfsh(1) | evolving | | |pfksh(1) | evolving | | |pfcsh(1) | evolving | | | | | | |roleadd(1M) | evolving | useradd(1M) | |roledel(1M) | evolving | userdel(1M) | |rolemod(1M) | evolving | usermod(1M) | |useradd(1M) | evolving | New options for| | | | authorizations | | | | and profiles | |userdel(1M) | evolving | Updates addi-| | | | tional files | |usermod(1M) | evolving | New options for| | | | authorizations | | | | and profiles | | | | | |kva_match(3) | stable | | | | | | |getauthattr(3) | stable | | |getauthnam(3) | stable | | |setauthattr(3) | stable | | |endauthattr(3) | stable | | |free_authattr(3) | stable | | |chkauthattr(3) | stable | | | | | | |getexecattr(3) | stable | | |__________________|________________|___________________| PSARC/1997/332 Copyright 1999 Sun Microsystems - 3 - _________________________________________________________ | Interfaces Exported | |__________________|________________|___________________| |Interface | Classification| Comments | |__________________|________________|___________________| |getexecuser(3) | stable | | |getexecprof(3) | stable | | |setexecattr(3) | stable | | |endexecattr(3) | stable | | |match_execattr(3) | stable | | | | | | |getprofattr(3) | stable | | |getprofnam(3) | stable | | |setprofattr(3) | stable | | |endprofattr(3) | stable | | |free_profattr(3) | stable | | | | | | |getuserattr(3) | stable | | |getuserid(3) | stable | | |getusernam(3) | stable | | |setuserattr(3) | stable | | |enduserattr(3) | stable | | |free_userattr(3) | stable | | | | | | |getauusernam(3) | stable | Existing inter-| | | | face updated to| | | | use nsswitch | |getauusernam_r(3) | stable | getauusernam(3) | | | | | |pam_role_auth.so.1| evolving | pam_role_auths(5)| |libsecdb.so.1 | stable | kva_match(3) | | | | | |auth_attr(4) | evolving | Extensible | | | | without breaking| | | | backward compati-| | | | bility | |exec_attr(4) | evolving | Extensible | | | | without breaking| | | | backward compati-| | | | bility | |prof_attr(4) | evolving | Extensible | | | | without breaking| | | | backward compati-| | | | bility | |user_attr(4) | evolving | Extensible | | | | without breaking| | | | backward compati-| | | | bility | | | | | |audit_user(4) | evolving | No change to| | | | database, now| | | | supports nsswitch| |policy.conf(4) | evolving | | |__________________|________________|___________________| |__________________|________________|___________________| PSARC/1997/332 Copyright 1999 Sun Microsystems - 4 - _________________________________________________________ | Interfaces Exported | |__________________|________________|___________________| |Interface | Classification| Comments | |__________________|________________|___________________| | | | | The project imports the following interfaces. _________________________________________________________ | Interfaces Imported | |_______________|_____________________|_________________| |Interface | Classification | Comments | |_______________|_____________________|_________________| |_nss_XbyY_fgets| consolation private| libc promoted| | | | from not visi-| | | | ble to Sun| | | | Private | |_______________|_____________________|_________________| 4. Opinion There were a number of issues raised at the commitment review. These were responded to in [2]. The primary issue was that no bundled administrative interfaces were being supplied. The project team felt that the unbundled Seabreeze project (LSARC/1998/476) which also uses and manages these databases should be the administrative inter- face. The committee felt that it was not sufficient to depend on an unbundled product as the only administrative interface. The project team responded by modifying existing bundled CLIs and adding new CLIs. A secondary issue was the interdependence of this case with PSARC/1997/331 (Process Privilege Mechanisms) or PSARC/1997/334 (Security Policy Hook Architecture). The project team assured the committee that there was none beyond a shared configuration file that was to be presented with PSARC/1997/334. That file (policy.conf(4)) is now included with this case. 4.1. Authorization Names There was discussion about the syntax of authorization names. The project team has proposed "com.sun..". Members of the committee thought the "com.sun." prefix was perhaps too long, too internal sounding, or potentially objectionable to Solaris OEMs. Alternative proposals of "solaris.", "sol." or "sunw." were made. The project team said they were open to a required technical change. However, since the Seabreeze project (LSARC/1998/476) was already in beta test with the PSARC/1997/332 Copyright 1999 Sun Microsystems - 5 - "com.sun." prefix, the project team did not feel it was appropriate to change the prefix without a required change from the committee. Any change required must be coordinated with an LSARC required change for Seabreeze. 4.2. Authorization and Keyword Registry The naming convention for authorization names is adequate for external customers to manage their own name space. Within Sun and Solaris the naming convention requires a registry for authorization names. There being no other established registry agent, the project team volunteered to act as the registry. A mail alias will be established for this purpose. Unlike authorization names which are hierarchical and have a partitioned name space, keywords in the databases reside in a flat name space. The project team advised that keywords for groups outside Sun should use a unique prefix. The pro- ject team volunteered to act as the registry for Sun. A mail alias will be established for this purpose. 4.3. LDAP The databases as presented do not support LDAP because there is no native LDAP support in the current gate. The project team plans to assist the PSARC/1998/361 project team to include these databases in the native LDAP support. 4.4. Substantially Increased Use of setuid Programs Finally, there was some discussion of the fact that virtu- ally all programs that will use the role functionality will have to be shipped as setuid-enabled. The committee con- cluded that this arrangement is more secure from a technical standpoint, but a minority expressed some skepticism over the notion that more (perhaps many more) setuid programs would be viewed negatively by the market. The steering com- mittee is advised to ensure that proper marketing precedes this product's launch and implementation in order to address such concerns. 5. Minority Opinion(s) None. 6. Advisory Information The committee felt that the presently bundled tools for administering Solaris databases are inadequate. The team had expected to rely on the unbundled Seabreeze product (LSARC/1998/476) for administration. When advised by the PSARC/1997/332 Copyright 1999 Sun Microsystems - 6 - committee that unbundled administration was not acceptable, the project team responded by modifying the existing useradd/del/mod(1M) CLIs and adding new roleadd/del/mod(1M) CLIs. While such CLIs are acceptable for this case, the project team points out that they would have preferred to follow a more encompassing administrative framework and would have done so if it were bundled. The committee agreed, observing that the issue might have been moot had SeaBreeze been a part of Foundation Solaris. The project team is working with the Seabreeze team to provide an encom- passing administration framework for user databases. Both the Seabreeze framework and the Viper framework (the follow-on to Solaris Management Console LSARC/1999/313) make use of this project's user attribute and authorization data- bases and mechanisms. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material 1. Final specification. File: PSARC/1997/332/commitment.materials/* 2. Mail. File: PSARC/1997/332/mail PSARC/1997/332 Copyright 1999 Sun Microsystems From Glenn.Faden@Ebay.Sun.COM Mon Apr 12 14:27:20 1999 Date: Mon, 12 Apr 1999 14:23:53 -0700 (PDT) From: Glenn Faden Subject: Re: 1997/332: Execution Profiles for Restricted Environments To: psarc@sac.eng.sun.com Cc: glenn.faden@Ebay.Sun.COM, gary.winiger@Ebay.Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kRzv1PIFgV2vVPefh0yXKA== Content-Length: 1570 Brian, > > 4.4. Substantially Increased Use of setuid Programs > > Finally, there was some discussion of the fact that virtu- > ally all programs that will use the role functionality will > have to be shipped as setuid-enabled. The committee con- > cluded that this arrangement is more secure from a technical > standpoint, but a minority expressed some skepticism over > the notion that more (perhaps many more) setuid programs > would be viewed negatively by the market. The steering com- > mittee is advised to ensure that proper marketing precedes > this product's launch and implementation in order to address > such concerns. s. > This paragraph is a bit misleading. This project provides two ways to associate special attributes with roles: authorizations and execution profile attributes Authorizations are checked by applications, which typically perform some restricted access check. These programs are frequently made setuid in the base, and use a variety of configuration files, like /etc/cron.d/cron.allow, or /etc/default/sys-suspend to configure lists of users who are authorized to perform these funtions. This project provides a more standardized framework for managing authorizations. Execution profile attributes are associated with processes launched by a profile shell. They are maintained in the exec_attr database, and are an alternative to using the setuid perm bits in the filesystem. Using the profile mechanism to specify attributes provides control over which users or roles gain setuid privileges. --Glenn From glenn@ivrel.eng.sun.com Mon Apr 12 15:16:52 1999 Date: Mon, 12 Apr 1999 15:16:59 -0700 (PDT) From: Glenn Skinner Subject: Re: 1997/332: Execution Profiles for Restricted Environments To: psarc@sac.eng.sun.com Cc: glenn.faden@Ebay, gary.winiger@Ebay MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: sE9ygaJ4ZqeIJi0YeNUzzA== Content-Length: 1690 Date: Mon, 12 Apr 1999 13:34:38 -0700 (PDT) From: Brian Wong Subject: 1997/332: Execution Profiles for Restricted Environments Please review by 4/16. Postscript in the case directory. Subject: Execution Profiles for Restricted Environ- ments Committee: Brian Wong, Ralph Campbell, Joseph Kowalski, Tim Marsland, David Robinson, Andy Rudoff, Steve Zucker 1. Summary This project provides the ability to assign arbitrary sets of attributes to users and roles. Attributes specify which accounts are roles, which roles are granted to users, and the specific authorizations and execution profiles which have been granted to an account. In addition, new attri- butes can be defined without any changes to the API. A role is a type of shared account which can only be accessed through a secondary login mechanism such as su(1M), and is only available to specified users. After reading the case materials for 1999/119 [Jobs, Sessions, Projects and Accounting], I'm struck by the similarity of roles (as defined by this case) to projects (as defined by that case), to the extent that I wonder whether the case at hand was approved prematurely. Suppose for the moment that 1999/119 was already approved and a part of the system. Wouldn't we insist that roles be implemented as projects (perhaps with some extensions)? Stated differently, I'm concerned about introducing roles now and shortly thereafter introducing the very similar, but not quite identical concept of project. It doesn't seem like good architecture. -- Glenn From Glenn.Faden@Ebay.Sun.COM Mon Apr 12 16:44:04 1999 Date: Mon, 12 Apr 1999 16:43:56 -0700 (PDT) From: Glenn Faden Subject: Re: 1997/332: Execution Profiles for Restricted Environments To: psarc@sac.eng.sun.com Cc: glenn.faden@Ebay.Sun.COM, gary.winiger@Ebay.Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8q0sgmz1Swlqo8fndgY6PQ== Content-Length: 1477 Glenn Skinner wrote: > After reading the case materials for 1999/119 [Jobs, Sessions, Projects > and Accounting], I'm struck by the similarity of roles (as defined by > this case) to projects (as defined by that case), to the extent that I > wonder whether the case at hand was approved prematurely. Suppose for > the moment that 1999/119 was already approved and a part of the system. > Wouldn't we insist that roles be implemented as projects (perhaps with > some extensions)? > > Stated differently, I'm concerned about introducing roles now and > shortly thereafter introducing the very similar, but not quite > identical concept of project. It doesn't seem like good architecture. As stated in the case materials, the databases and APIs in this case have been architected to be as extensible as possible. Since first submitted to PSARC 18 months ago, they have been re-engineered to support arbitrary attributes. It is a stated goal of this case, that other projects, for example, 1999/119, can add new user attributes to the user_attr database without any changes to the API. In fact, the answer to 4, in the 20 questions for 1999/119 indicates that the project proposes using the user_attr database from 1997/332. Roles and projects are distinctly different user attributes. Roles are used for access control, so that the powers of root may be distributed and delegated. Projects are used for accounting and charge back. They should remain distinct. --Glenn From tpm@darwin.eng.sun.com Mon Apr 12 19:36:28 1999 Date: Mon, 12 Apr 1999 19:36:29 -0700 (PDT) From: Tim Marsland To: psarc@sac.eng.sun.com, Gary.Winiger@Ebay.Sun.COM Subject: Re: PSARC/1997/332 Cc: brian.wong@eng.sun.com Content-Length: 5422 Here's some feedback on your answers-to-issues posted last week (I started this before Brian's opinion was posted). | sz-7. exec_attr(4): Numeric ids only? | | The gui will only store numeric ids, but user and group names | will also be allowed. Surely the exec_attr database should contain usernames and groupnames? Seems strange to expose the implementation ids behind the names when the username is usually more meaningful and comprehensible. | 28. Names of authorizations: Solaris, sol, sunw, etc. | | See sz-4 above. | However, if for OEM purposes Solaris or sol should be picked, I'm checking on this with the "OEM ready" people now .. | please make this a TCR and coordinate with LSARC 1998/476 Seabreaze. Since you created the dependency independently of PSARC, I think it's just as much your problem to "coordinate" with Seabreeze as it is ours ;-) | sz-3.* 20q8.5: I18N for help files? | | Alternate (localized) help files are looked up by the administrative | tools (e.g., Seabreeze), by creating a pathname which includes the | locale as a directory component. | | ar-2: Where does file.html live when you list "help=file.html"? | | See sz-3 above. | | 30. help files in distributed environment (cross consolidations)? | | We have filed bugs against seabreeze to support both local (file://) | and remote (http://) forms of URLs, and to provide a helppath | for specifying multiple directories. See bug 4217816. I'm not particularly happy with these answers, and I think this is an important issue for the administration of this project. It does seem a bit wrong for a different, unbundled, product to be shipping the help files that describes functionality in a different product. A bit like completely unbundling the manpages from the base OS. I think the default assumption should be that the help files that help an administrator understand the semantics of an authorization should come from the product that provides the implementation(s) that consume the authorizations. That way the product can evolve independently without having to update the administrative product whose basic function is to enable or disable it, and render the help text prettily. Also, one shouldn't have to create an extended URL per authorization to workaround bad defaults. Maybe (if there isn't already) there should be a way to name the base URL to find the help files? Sigh, maybe I just don't understand this properly. And I'm not sure how much of my concerns are created by Seabreeze vs. the database proposed by this project per se. | 32. Relation to other OS Vendor efforts. | | The X/Open Single Sign-on Service (XSSO) refers to account | management services in Appendix D1. This case provides conformance. | | The Common Criteria Protection Profile for Role_Based Access | Control (RBAC) provides additional requirements to which this case | conforms. What I meant was, is anyone else trying to deal with role-based administration issues via a name service? Is there another, similar, database being proposed to IETF, or one in common currency in the world of heterogenous multi-vendor networks? | 37. kva -> keyval in kva_match(3). | | If the arc requires this change, we will make it. I guess 'keyval_' seems to be more self-documenting to me - kva makes me think "kernel virtual address" -- perhaps this is just me. | 39. A Roles section in man pages. | | Since roles are not hard coded we won't be identifying | them by name in man pages. However, when functionality | is different for roles, such as in logging in, we | will point out the difference. Sorry, I meant adding an 'AUTHORIZATIONS' section in each relevant manpage, i.e. instead of (or perhaps as well as, groan) filling the text with various keywords like com.sun.system.set.the.date, let's have a summary table at the end for quick reference. I guess I have two other points (perhaps for the Advice to SC or other "futures" discussion instead of here): - Could you predefine some roles that represent common system administration tasks? I know you have allowed almost infinite rope in this project via the many ways you've responded to our extensibility concerns, so almost any model is implementable now, but that doesn't seem particularly compelling for a product feature in base Solaris. Would it be possible to predefine a couple of roles that would make sense i.e. give the customer who wants to "get role based" a starting policy to work from? As an example - create a pre-defined role to allow local filesystems to be backed up? And another to allow the machine to be shut down. You seem to have some examples in your commit.materials/user_attr.txt, but I presume you're not -really- adding a definition for gfaden to this file .. If not this project, then could this be usefully done in a follow-up project that would define some more formal roles for Solaris administration? - Adding rope and extensibility is always interesting and usually fun. But all these optional policies, hooks, and choices for administration can make the system more complex, less comprehensible, more difficult to administer, and less maintainable both for us and for our customers. There is occasionally virtue in simplicity! So, a question for the ARC as well as the project team, should we be working to eliminate the 'suser' policy completely in favour of a role-based one, long-term? tim From Gary.Winiger@Ebay.Sun.COM Wed Apr 21 13:46:42 1999 Date: Wed, 21 Apr 1999 13:46:13 -0700 From: Gary.Winiger@Ebay.Sun.COM (Gary Winiger) To: psarc@sac.eng.sun.com, Gary.Winiger@Ebay.Sun.COM, Tim.Marsland@eng.sun.com Subject: Re: PSARC/1997/332 Cc: brian.wong@eng.sun.com, glenn.faden.EBay@marduk.Ebay.Sun.COM Content-Length: 11006 Tim, > Here's some feedback on your answers-to-issues posted last week (I > started this before Brian's opinion was posted). Thanks for your comments. It is our view that the opinion should be updated to reflect the items noted here. We will coordinate with Brian to do so. --Glenn & Gary.. > | sz-7. exec_attr(4): Numeric ids only? > | > | The gui will only store numeric ids, but user and group names > | will also be allowed. > > Surely the exec_attr database should contain usernames and groupnames? > Seems strange to expose the implementation ids behind the names when the > username is usually more meaningful and comprehensible. Both formats are supported. The numeric form is more efficient since it can be converted to a uid_t or gud_t without additional lookups in passwd/group. As in other places such as the file system, the user interfaces to the id fields accept and present names so users never have to see numbers. > | 28. Names of authorizations: Solaris, sol, sunw, etc. > | > | See sz-4 above. > | However, if for OEM purposes Solaris or sol should be picked, > > I'm checking on this with the "OEM ready" people now .. Thank you for checking and the "out of band" communications on the OEM recommendations. We have changed the prefix to "solaris". > > | please make this a TCR and coordinate with LSARC 1998/476 Seabreeze. Seabreeze has also made the appropriate changes. Here is a summary from the Seabreeze putback. > Comment: > 4230518: Changed auth rights prefix to "solaris" for primary admin > Changed auth rights prefix to "solaris.admin" for apps > Changed location of user_attr file to /etc > Changed some options on user_attr, auth_attr in files table defn > > Since you created the dependency independently of PSARC, I think it's > just as much your problem to "coordinate" with Seabreeze as it is ours ;-) Agreed. It has been taken care of. > | sz-3.* 20q8.5: I18N for help files? > | > | Alternate (localized) help files are looked up by the administrative > | tools (e.g., Seabreeze), by creating a pathname which includes the > | locale as a directory component. > | > | ar-2: Where does file.html live when you list "help=file.html"? > | > | See sz-3 above. > | > | 30. help files in distributed environment (cross consolidations)? > | > | We have filed bugs against seabreeze to support both local (file://) > | and remote (http://) forms of URLs, and to provide a helppath > | for specifying multiple directories. See bug 4217816. > > I'm not particularly happy with these answers, and I think this is > an important issue for the administration of this project. The bug 4217816 has been changed (by Seabreeze) to an RFE. However, they have implemented localization as follows: The help file URL is formed by Install_Directory_Name/help/auths/$LOCALE/helpfile.html The Seabreeze client (GUI) gets the Install_Directory_Name and locale from client properties. The help files for authorizations and profiles will be delivered in /usr/lib/help/auths/locale/C/ and /usr/lib/help/profiles/locale/C/ In each directory containing html help files there is also a file named index.html which will display the list of authorizations or profiles as hypertext links to the help files in the same directory. A pointer to each help directory is included on the auth_attr(4) and prof_attr(4) man pages, respectively. The user can point his/her browser at the specified directory to get help on any authorization or profile. Until we have a GUI for adding authorizations or profiles, when a new authorization or profile is created, the new help file must be installed in the appropriate help directory, and the index.html file will need to be updated, as well. > It does seem a bit wrong for a different, unbundled, product to be > shipping the help files that describes functionality in a different > product. A bit like completely unbundling the manpages from the base OS. The project team's view is it's like the project that supplies the man page viewer also supplying the man pages. However, the user can still view the help files without Seabreeze, in any web browser. > I think the default assumption should be that the help files that help > an administrator understand the semantics of an authorization should > come from the product that provides the implementation(s) that consume > the authorizations. That way the product can evolve independently > without having to update the administrative product whose basic > function is to enable or disable it, and render the help text > prettily. Also, one shouldn't have to create an extended URL per > authorization to workaround bad defaults. Maybe (if there isn't > already) there should be a way to name the base URL to find the help > files? Agreed. We will provide this information on the auth_attr and prof_attr man pages. > Sigh, maybe I just don't understand this properly. And I'm not sure how > much of my concerns are created by Seabreeze vs. the database proposed by > this project per se. Yes, but based on conversations with the Seabreeze team, we will not be including their authorization names or help files in the foundation. They will install these with Seabreeze. > | 32. Relation to other OS Vendor efforts. > | > | The X/Open Single Sign-on Service (XSSO) refers to account > | management services in Appendix D1. This case provides conformance. > | > | The Common Criteria Protection Profile for Role_Based Access > | Control (RBAC) provides additional requirements to which this case > | conforms. > > What I meant was, is anyone else trying to deal with role-based > administration issues via a name service? Is there another, > similar, database being proposed to IETF, or one in common currency in > the world of heterogenous multi-vendor networks? We have been tracking what has been published, and are not aware of anything that we could use. There is related work being done by the government. NIST has published a number of research papers and prototypes. We are using some of these ideas, but none of the work is focussed specifically on UNIX administration. The National Information Infrastructure Common Operating Environment (NII COE) specification also defines a role-based system. This development is being done to provide a single administrative model for UNIX systems. Trusted Solaris has already been approved as one acceptable implementation of the COE. For standard Solaris and HP-UX systems, the US government originally subcontracted with a number of public and private sector development groups, including the Jet Propulsion Labs. However, this work is in a state of flux. Other products, such as Tivoli, have support for roles. > > | 37. kva -> keyval in kva_match(3). > | > | If the arc requires this change, we will make it. > > I guess 'keyval_' seems to be more self-documenting to me - kva makes > me think "kernel virtual address" -- perhaps this is just me. We also have other kv_ interfaces and typedefs. We can change them all if required. > > | 39. A Roles section in man pages. > | > | Since roles are not hard coded we won't be identifying > | them by name in man pages. However, when functionality > | is different for roles, such as in logging in, we > | will point out the difference. > > Sorry, I meant adding an 'AUTHORIZATIONS' section in each relevant > manpage, i.e. instead of (or perhaps as well as, groan) filling the > text with various keywords like com.sun.system.set.the.date, let's have > a summary table at the end for quick reference. We will forward this suggestion to the Solaris man page group. They are currently working on the affected commands. > I guess I have two other points (perhaps for the Advice to SC or > other "futures" discussion instead of here): > > - Could you predefine some roles that represent common system > administration tasks? I know you have allowed almost infinite > rope in this project via the many ways you've responded to our > extensibility concerns, so almost any model is implementable now, > but that doesn't seem particularly compelling for a product > feature in base Solaris. > > Would it be possible to predefine a couple of roles that would > make sense i.e. give the customer who wants to "get role based" > a starting policy to work from? As an example - create a > pre-defined role to allow local filesystems to be backed up? > And another to allow the machine to be shut down. You seem to > have some examples in your commit.materials/user_attr.txt, but > I presume you're not -really- adding a definition for gfaden to this > file .. > > If not this project, then could this be usefully done in a > follow-up project that would define some more formal roles for > Solaris administration? We agree that one or more follow on projects are needed and such Advice to a Steering Committee is welcome. > - Adding rope and extensibility is always interesting and usually > fun. But all these optional policies, hooks, and choices for > administration can make the system more complex, less > comprehensible, more difficult to administer, and less > maintainable both for us and for our customers. There is > occasionally virtue in simplicity! > > So, a question for the ARC as well as the project team, > should we be working to eliminate the 'suser' policy completely > in favor of a role-based one, long-term? Yes, eventually the use of root/super user should be the degenerative case of a more flexible policy. This will require wide-scale effort. Trusted Solaris has only been partially successful there are still too many Solaris Foundation scripts/programs that check for real user of root. It's ever worse for unbundled and third party programs as they control source not directly modifyable by Solaris Foundation projects. In our opinion, role based control and authorizations is part of the answer. Fine grained privileges to replace the all powerful UID == 0 privilege and the implementation of the Principle of Least Privilege complements it. The project team believes that Solaris Foundation should move in the direction of: Administration with out the need to become super-user (often called Role Base Access Control -- RBAC); User Authorizations -- The ability to grant individual users the right to do certain operations without granting others, for example to use removable media, shutdown the system; Least Privilege -- fragments the rights of UID 0 to bypass all security restrictions on the system into a number of distinctly grantable rights (called privileges) which are individually applied to processes only when needed. RBAC is desirable to reduce the inadvertent or malicious actions that an administrator can do, including reading or modifying user's data. Least Privilege is desirable to reduce the inadvertent or malicious actions that breaking into a system daemon can lead to including reading or modifying user's data. From Gary.Winiger@Ebay.Sun.COM Wed Apr 21 13:47:13 1999 Date: Wed, 21 Apr 1999 13:46:46 -0700 From: Gary.Winiger@Ebay.Sun.COM (Gary Winiger) To: psarc@sac.eng.sun.com, Gary.Winiger@Ebay.Sun.COM, Tim.Marsland@eng.sun.com Subject: Re: PSARC/1997/332 Cc: brian.wong@eng.sun.com, glenn.faden.EBay@marduk.Ebay.Sun.COM Content-Length: 11006 Tim, > Here's some feedback on your answers-to-issues posted last week (I > started this before Brian's opinion was posted). Thanks for your comments. It is our view that the opinion should be updated to reflect the items noted here. We will coordinate with Brian to do so. --Glenn & Gary.. > | sz-7. exec_attr(4): Numeric ids only? > | > | The gui will only store numeric ids, but user and group names > | will also be allowed. > > Surely the exec_attr database should contain usernames and groupnames? > Seems strange to expose the implementation ids behind the names when the > username is usually more meaningful and comprehensible. Both formats are supported. The numeric form is more efficient since it can be converted to a uid_t or gud_t without additional lookups in passwd/group. As in other places such as the file system, the user interfaces to the id fields accept and present names so users never have to see numbers. > | 28. Names of authorizations: Solaris, sol, sunw, etc. > | > | See sz-4 above. > | However, if for OEM purposes Solaris or sol should be picked, > > I'm checking on this with the "OEM ready" people now .. Thank you for checking and the "out of band" communications on the OEM recommendations. We have changed the prefix to "solaris". > > | please make this a TCR and coordinate with LSARC 1998/476 Seabreeze. Seabreeze has also made the appropriate changes. Here is a summary from the Seabreeze putback. > Comment: > 4230518: Changed auth rights prefix to "solaris" for primary admin > Changed auth rights prefix to "solaris.admin" for apps > Changed location of user_attr file to /etc > Changed some options on user_attr, auth_attr in files table defn > > Since you created the dependency independently of PSARC, I think it's > just as much your problem to "coordinate" with Seabreeze as it is ours ;-) Agreed. It has been taken care of. > | sz-3.* 20q8.5: I18N for help files? > | > | Alternate (localized) help files are looked up by the administrative > | tools (e.g., Seabreeze), by creating a pathname which includes the > | locale as a directory component. > | > | ar-2: Where does file.html live when you list "help=file.html"? > | > | See sz-3 above. > | > | 30. help files in distributed environment (cross consolidations)? > | > | We have filed bugs against seabreeze to support both local (file://) > | and remote (http://) forms of URLs, and to provide a helppath > | for specifying multiple directories. See bug 4217816. > > I'm not particularly happy with these answers, and I think this is > an important issue for the administration of this project. The bug 4217816 has been changed (by Seabreeze) to an RFE. However, they have implemented localization as follows: The help file URL is formed by Install_Directory_Name/help/auths/$LOCALE/helpfile.html The Seabreeze client (GUI) gets the Install_Directory_Name and locale from client properties. The help files for authorizations and profiles will be delivered in /usr/lib/help/auths/locale/C/ and /usr/lib/help/profiles/locale/C/ In each directory containing html help files there is also a file named index.html which will display the list of authorizations or profiles as hypertext links to the help files in the same directory. A pointer to each help directory is included on the auth_attr(4) and prof_attr(4) man pages, respectively. The user can point his/her browser at the specified directory to get help on any authorization or profile. Until we have a GUI for adding authorizations or profiles, when a new authorization or profile is created, the new help file must be installed in the appropriate help directory, and the index.html file will need to be updated, as well. > It does seem a bit wrong for a different, unbundled, product to be > shipping the help files that describes functionality in a different > product. A bit like completely unbundling the manpages from the base OS. The project team's view is it's like the project that supplies the man page viewer also supplying the man pages. However, the user can still view the help files without Seabreeze, in any web browser. > I think the default assumption should be that the help files that help > an administrator understand the semantics of an authorization should > come from the product that provides the implementation(s) that consume > the authorizations. That way the product can evolve independently > without having to update the administrative product whose basic > function is to enable or disable it, and render the help text > prettily. Also, one shouldn't have to create an extended URL per > authorization to workaround bad defaults. Maybe (if there isn't > already) there should be a way to name the base URL to find the help > files? Agreed. We will provide this information on the auth_attr and prof_attr man pages. > Sigh, maybe I just don't understand this properly. And I'm not sure how > much of my concerns are created by Seabreeze vs. the database proposed by > this project per se. Yes, but based on conversations with the Seabreeze team, we will not be including their authorization names or help files in the foundation. They will install these with Seabreeze. > | 32. Relation to other OS Vendor efforts. > | > | The X/Open Single Sign-on Service (XSSO) refers to account > | management services in Appendix D1. This case provides conformance. > | > | The Common Criteria Protection Profile for Role_Based Access > | Control (RBAC) provides additional requirements to which this case > | conforms. > > What I meant was, is anyone else trying to deal with role-based > administration issues via a name service? Is there another, > similar, database being proposed to IETF, or one in common currency in > the world of heterogenous multi-vendor networks? We have been tracking what has been published, and are not aware of anything that we could use. There is related work being done by the government. NIST has published a number of research papers and prototypes. We are using some of these ideas, but none of the work is focussed specifically on UNIX administration. The National Information Infrastructure Common Operating Environment (NII COE) specification also defines a role-based system. This development is being done to provide a single administrative model for UNIX systems. Trusted Solaris has already been approved as one acceptable implementation of the COE. For standard Solaris and HP-UX systems, the US government originally subcontracted with a number of public and private sector development groups, including the Jet Propulsion Labs. However, this work is in a state of flux. Other products, such as Tivoli, have support for roles. > > | 37. kva -> keyval in kva_match(3). > | > | If the arc requires this change, we will make it. > > I guess 'keyval_' seems to be more self-documenting to me - kva makes > me think "kernel virtual address" -- perhaps this is just me. We also have other kv_ interfaces and typedefs. We can change them all if required. > > | 39. A Roles section in man pages. > | > | Since roles are not hard coded we won't be identifying > | them by name in man pages. However, when functionality > | is different for roles, such as in logging in, we > | will point out the difference. > > Sorry, I meant adding an 'AUTHORIZATIONS' section in each relevant > manpage, i.e. instead of (or perhaps as well as, groan) filling the > text with various keywords like com.sun.system.set.the.date, let's have > a summary table at the end for quick reference. We will forward this suggestion to the Solaris man page group. They are currently working on the affected commands. > I guess I have two other points (perhaps for the Advice to SC or > other "futures" discussion instead of here): > > - Could you predefine some roles that represent common system > administration tasks? I know you have allowed almost infinite > rope in this project via the many ways you've responded to our > extensibility concerns, so almost any model is implementable now, > but that doesn't seem particularly compelling for a product > feature in base Solaris. > > Would it be possible to predefine a couple of roles that would > make sense i.e. give the customer who wants to "get role based" > a starting policy to work from? As an example - create a > pre-defined role to allow local filesystems to be backed up? > And another to allow the machine to be shut down. You seem to > have some examples in your commit.materials/user_attr.txt, but > I presume you're not -really- adding a definition for gfaden to this > file .. > > If not this project, then could this be usefully done in a > follow-up project that would define some more formal roles for > Solaris administration? We agree that one or more follow on projects are needed and such Advice to a Steering Committee is welcome. > - Adding rope and extensibility is always interesting and usually > fun. But all these optional policies, hooks, and choices for > administration can make the system more complex, less > comprehensible, more difficult to administer, and less > maintainable both for us and for our customers. There is > occasionally virtue in simplicity! > > So, a question for the ARC as well as the project team, > should we be working to eliminate the 'suser' policy completely > in favor of a role-based one, long-term? Yes, eventually the use of root/super user should be the degenerative case of a more flexible policy. This will require wide-scale effort. Trusted Solaris has only been partially successful there are still too many Solaris Foundation scripts/programs that check for real user of root. It's ever worse for unbundled and third party programs as they control source not directly modifyable by Solaris Foundation projects. In our opinion, role based control and authorizations is part of the answer. Fine grained privileges to replace the all powerful UID == 0 privilege and the implementation of the Principle of Least Privilege complements it. The project team believes that Solaris Foundation should move in the direction of: Administration with out the need to become super-user (often called Role Base Access Control -- RBAC); User Authorizations -- The ability to grant individual users the right to do certain operations without granting others, for example to use removable media, shutdown the system; Least Privilege -- fragments the rights of UID 0 to bypass all security restrictions on the system into a number of distinctly grantable rights (called privileges) which are individually applied to processes only when needed. RBAC is desirable to reduce the inadvertent or malicious actions that an administrator can do, including reading or modifying user's data. Least Privilege is desirable to reduce the inadvertent or malicious actions that breaking into a system daemon can lead to including reading or modifying user's data. From Gary.Winiger@Ebay.Sun.COM Wed Apr 21 13:48:16 1999 Date: Wed, 21 Apr 1999 13:47:44 -0700 From: Gary.Winiger@Ebay.Sun.COM (Gary Winiger) To: psarc@sac.eng.sun.com, Gary.Winiger@Ebay.Sun.COM, Tim.Marsland@eng.sun.com Subject: Re: PSARC/1997/332 Cc: brian.wong@eng.sun.com, glenn.faden@Ebay.Sun.COM Content-Length: 11006 Tim, > Here's some feedback on your answers-to-issues posted last week (I > started this before Brian's opinion was posted). Thanks for your comments. It is our view that the opinion should be updated to reflect the items noted here. We will coordinate with Brian to do so. --Glenn & Gary.. > | sz-7. exec_attr(4): Numeric ids only? > | > | The gui will only store numeric ids, but user and group names > | will also be allowed. > > Surely the exec_attr database should contain usernames and groupnames? > Seems strange to expose the implementation ids behind the names when the > username is usually more meaningful and comprehensible. Both formats are supported. The numeric form is more efficient since it can be converted to a uid_t or gud_t without additional lookups in passwd/group. As in other places such as the file system, the user interfaces to the id fields accept and present names so users never have to see numbers. > | 28. Names of authorizations: Solaris, sol, sunw, etc. > | > | See sz-4 above. > | However, if for OEM purposes Solaris or sol should be picked, > > I'm checking on this with the "OEM ready" people now .. Thank you for checking and the "out of band" communications on the OEM recommendations. We have changed the prefix to "solaris". > > | please make this a TCR and coordinate with LSARC 1998/476 Seabreeze. Seabreeze has also made the appropriate changes. Here is a summary from the Seabreeze putback. > Comment: > 4230518: Changed auth rights prefix to "solaris" for primary admin > Changed auth rights prefix to "solaris.admin" for apps > Changed location of user_attr file to /etc > Changed some options on user_attr, auth_attr in files table defn > > Since you created the dependency independently of PSARC, I think it's > just as much your problem to "coordinate" with Seabreeze as it is ours ;-) Agreed. It has been taken care of. > | sz-3.* 20q8.5: I18N for help files? > | > | Alternate (localized) help files are looked up by the administrative > | tools (e.g., Seabreeze), by creating a pathname which includes the > | locale as a directory component. > | > | ar-2: Where does file.html live when you list "help=file.html"? > | > | See sz-3 above. > | > | 30. help files in distributed environment (cross consolidations)? > | > | We have filed bugs against seabreeze to support both local (file://) > | and remote (http://) forms of URLs, and to provide a helppath > | for specifying multiple directories. See bug 4217816. > > I'm not particularly happy with these answers, and I think this is > an important issue for the administration of this project. The bug 4217816 has been changed (by Seabreeze) to an RFE. However, they have implemented localization as follows: The help file URL is formed by Install_Directory_Name/help/auths/$LOCALE/helpfile.html The Seabreeze client (GUI) gets the Install_Directory_Name and locale from client properties. The help files for authorizations and profiles will be delivered in /usr/lib/help/auths/locale/C/ and /usr/lib/help/profiles/locale/C/ In each directory containing html help files there is also a file named index.html which will display the list of authorizations or profiles as hypertext links to the help files in the same directory. A pointer to each help directory is included on the auth_attr(4) and prof_attr(4) man pages, respectively. The user can point his/her browser at the specified directory to get help on any authorization or profile. Until we have a GUI for adding authorizations or profiles, when a new authorization or profile is created, the new help file must be installed in the appropriate help directory, and the index.html file will need to be updated, as well. > It does seem a bit wrong for a different, unbundled, product to be > shipping the help files that describes functionality in a different > product. A bit like completely unbundling the manpages from the base OS. The project team's view is it's like the project that supplies the man page viewer also supplying the man pages. However, the user can still view the help files without Seabreeze, in any web browser. > I think the default assumption should be that the help files that help > an administrator understand the semantics of an authorization should > come from the product that provides the implementation(s) that consume > the authorizations. That way the product can evolve independently > without having to update the administrative product whose basic > function is to enable or disable it, and render the help text > prettily. Also, one shouldn't have to create an extended URL per > authorization to workaround bad defaults. Maybe (if there isn't > already) there should be a way to name the base URL to find the help > files? Agreed. We will provide this information on the auth_attr and prof_attr man pages. > Sigh, maybe I just don't understand this properly. And I'm not sure how > much of my concerns are created by Seabreeze vs. the database proposed by > this project per se. Yes, but based on conversations with the Seabreeze team, we will not be including their authorization names or help files in the foundation. They will install these with Seabreeze. > | 32. Relation to other OS Vendor efforts. > | > | The X/Open Single Sign-on Service (XSSO) refers to account > | management services in Appendix D1. This case provides conformance. > | > | The Common Criteria Protection Profile for Role_Based Access > | Control (RBAC) provides additional requirements to which this case > | conforms. > > What I meant was, is anyone else trying to deal with role-based > administration issues via a name service? Is there another, > similar, database being proposed to IETF, or one in common currency in > the world of heterogenous multi-vendor networks? We have been tracking what has been published, and are not aware of anything that we could use. There is related work being done by the government. NIST has published a number of research papers and prototypes. We are using some of these ideas, but none of the work is focussed specifically on UNIX administration. The National Information Infrastructure Common Operating Environment (NII COE) specification also defines a role-based system. This development is being done to provide a single administrative model for UNIX systems. Trusted Solaris has already been approved as one acceptable implementation of the COE. For standard Solaris and HP-UX systems, the US government originally subcontracted with a number of public and private sector development groups, including the Jet Propulsion Labs. However, this work is in a state of flux. Other products, such as Tivoli, have support for roles. > > | 37. kva -> keyval in kva_match(3). > | > | If the arc requires this change, we will make it. > > I guess 'keyval_' seems to be more self-documenting to me - kva makes > me think "kernel virtual address" -- perhaps this is just me. We also have other kv_ interfaces and typedefs. We can change them all if required. > > | 39. A Roles section in man pages. > | > | Since roles are not hard coded we won't be identifying > | them by name in man pages. However, when functionality > | is different for roles, such as in logging in, we > | will point out the difference. > > Sorry, I meant adding an 'AUTHORIZATIONS' section in each relevant > manpage, i.e. instead of (or perhaps as well as, groan) filling the > text with various keywords like com.sun.system.set.the.date, let's have > a summary table at the end for quick reference. We will forward this suggestion to the Solaris man page group. They are currently working on the affected commands. > I guess I have two other points (perhaps for the Advice to SC or > other "futures" discussion instead of here): > > - Could you predefine some roles that represent common system > administration tasks? I know you have allowed almost infinite > rope in this project via the many ways you've responded to our > extensibility concerns, so almost any model is implementable now, > but that doesn't seem particularly compelling for a product > feature in base Solaris. > > Would it be possible to predefine a couple of roles that would > make sense i.e. give the customer who wants to "get role based" > a starting policy to work from? As an example - create a > pre-defined role to allow local filesystems to be backed up? > And another to allow the machine to be shut down. You seem to > have some examples in your commit.materials/user_attr.txt, but > I presume you're not -really- adding a definition for gfaden to this > file .. > > If not this project, then could this be usefully done in a > follow-up project that would define some more formal roles for > Solaris administration? We agree that one or more follow on projects are needed and such Advice to a Steering Committee is welcome. > - Adding rope and extensibility is always interesting and usually > fun. But all these optional policies, hooks, and choices for > administration can make the system more complex, less > comprehensible, more difficult to administer, and less > maintainable both for us and for our customers. There is > occasionally virtue in simplicity! > > So, a question for the ARC as well as the project team, > should we be working to eliminate the 'suser' policy completely > in favor of a role-based one, long-term? Yes, eventually the use of root/super user should be the degenerative case of a more flexible policy. This will require wide-scale effort. Trusted Solaris has only been partially successful there are still too many Solaris Foundation scripts/programs that check for real user of root. It's ever worse for unbundled and third party programs as they control source not directly modifyable by Solaris Foundation projects. In our opinion, role based control and authorizations is part of the answer. Fine grained privileges to replace the all powerful UID == 0 privilege and the implementation of the Principle of Least Privilege complements it. The project team believes that Solaris Foundation should move in the direction of: Administration with out the need to become super-user (often called Role Base Access Control -- RBAC); User Authorizations -- The ability to grant individual users the right to do certain operations without granting others, for example to use removable media, shutdown the system; Least Privilege -- fragments the rights of UID 0 to bypass all security restrictions on the system into a number of distinctly grantable rights (called privileges) which are individually applied to processes only when needed. RBAC is desirable to reduce the inadvertent or malicious actions that an administrator can do, including reading or modifying user's data. Least Privilege is desirable to reduce the inadvertent or malicious actions that breaking into a system daemon can lead to including reading or modifying user's data. From blw@chessie Fri Apr 23 09:48:47 1999 Date: Fri, 23 Apr 1999 09:48:46 -0700 From: blw@chessie (Brian Wong - Strategic Enterprise Technologies) To: gary.winiger@ebay, glenn.faden@ebay, psarc@sac Subject: 1997/332: Execution Profiles Content-Length: 16197 We wanted to see the 1999/119 material for projects, and I think we're convinced that they are separate cases. I think we're ready to vote on the draft opinion, which I enclose as modified (thanks Gary). Postscript is in the case directory. blw sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Execution Profiles for Restricted Environ- ments Submitted by: Glenn Faden, Gary Winiger File: PSARC/1997/332/opinion.ms Date: April 21, 1999 | Committee: Brian Wong, Ralph Campbell, Joseph Kowalski, Tim Marsland, David Robinson, Andy Rudoff, Steve Zucker Steering Committee: Solaris Operating Environment Steering Com- mittee (soesc@sac.eng) 1. Summary This project provides the ability to assign arbitrary sets of attributes to users and roles. Attributes specify which accounts are roles, which roles are granted to users, and the specific authorizations and execution profiles which have been granted to an account. In addition, new attri- butes can be defined without any changes to the API. A role is a type of shared account which can only be accessed through a secondary login mechanism such as su(1M), and is only available to specified users. An authorization is a right granted to a user or role to perform a function which is not generally allowed. Trusted applications check that a user (or role) is authorized before performing restricted operations. A profile is a bundling mechanism that contains the list of commands and authorizations required to perform a particular function. For each command, the profile may specify the effective user id and/or the effective group id to be used when executing the command. Authorizations and commands from multiple profiles are additive. Assigning a profile to a role allows users who can assume that role to perform specific privileged operations without giving users access to all superuser powers. For example, a user might be able to administer the printer subsystem, but not add users or change the password of other users. This project provides a CLI for assigning roles, PSARC/1997/332 Copyright 1999 Sun Microsystems - 2 - authorizations, and profiles to users and a "C" API, the data structures and database formats, and conventions for using authorizations, roles, and profiles. 2. Decision & Precedence Information This project is approved as specified in reference [1]. This project may be delivered in a minor release of Solaris. This project and the following project are required to coor- dinate to ensure that the databases introduced by this pro- ject are available through LDAP. PSARC/1998/361 Native LDAP 3. Interfaces The project exports the following interfaces. _________________________________________________________ | Interfaces Exported | |__________________|________________|___________________| |Interface | Classification| Comments | |__________________|________________|___________________| |auths(1) | evolving | | |pfcsh(1) | evolving | | |pfexec(1) | evolving | | | |pfksh(1) | evolving | | |pfsh(1) | evolving | | |profiles(1) | evolving | | |roles(1) | evolving | | | | | | |roleadd(1M) | evolving | useradd(1M) | |roledel(1M) | evolving | userdel(1M) | |rolemod(1M) | evolving | usermod(1M) | |useradd(1M) | evolving | New options for| | | | authorizations | | | | and profiles | |userdel(1M) | evolving | Updates addi-| | | | tional files | |usermod(1M) | evolving | New options for| | | | authorizations | | | | and profiles | | | | | |kva_match(3) | stable | | | | | | |getauthattr(3) | stable | | |getauthnam(3) | stable | | |setauthattr(3) | stable | | |endauthattr(3) | stable | | |free_authattr(3) | stable | | |chkauthattr(3) | stable | | | | | | |__________________|________________|___________________| PSARC/1997/332 Copyright 1999 Sun Microsystems - 3 - _________________________________________________________ | Interfaces Exported | |__________________|________________|___________________| |Interface | Classification| Comments | |__________________|________________|___________________| |getexecattr(3) | stable | | |getexecuser(3) | stable | | |getexecprof(3) | stable | | |setexecattr(3) | stable | | |endexecattr(3) | stable | | |match_execattr(3) | stable | | | | | | |getprofattr(3) | stable | | |getprofnam(3) | stable | | |setprofattr(3) | stable | | |endprofattr(3) | stable | | |free_profattr(3) | stable | | | | | | |getuserattr(3) | stable | | |getuserid(3) | stable | | |getusernam(3) | stable | | |setuserattr(3) | stable | | |enduserattr(3) | stable | | |free_userattr(3) | stable | | | | | | |getauusernam(3) | stable | Existing inter-| | | | face updated to| | | | use nsswitch | |getauusernam_r(3) | stable | getauusernam(3) | | | | | |pam_role_auth.so.1| evolving | pam_role_auths(5)| |libsecdb.so.1 | stable | kva_match(3) | | | | | |auth_attr(4) | evolving | Extensible | | | | without breaking| | | | backward compati-| | | | bility | |exec_attr(4) | evolving | Extensible | | | | without breaking| | | | backward compati-| | | | bility | |prof_attr(4) | evolving | Extensible | | | | without breaking| | | | backward compati-| | | | bility | |user_attr(4) | evolving | Extensible | | | | without breaking| | | | backward compati-| | | | bility | | | | | |audit_user(4) | evolving | No change to| | | | database, now| | | | supports nsswitch| |policy.conf(4) | evolving | | |__________________|________________|___________________| PSARC/1997/332 Copyright 1999 Sun Microsystems - 4 - _________________________________________________________ | Interfaces Exported | |__________________|________________|___________________| |Interface | Classification| Comments | |__________________|________________|___________________| |__________________|________________|___________________| The project imports the following interfaces. _________________________________________________________ | Interfaces Imported | |_______________|_____________________|_________________| |Interface | Classification | Comments | |_______________|_____________________|_________________| |_nss_XbyY_fgets| consolation private| libc promoted| | | | from not visi-| | | | ble to Sun| | | | Private | |_______________|_____________________|_________________| 4. Opinion There were a number of issues raised at the commitment review. These were responded to in [2]. The primary issue was that no bundled administrative interfaces were being supplied. The project team felt that the unbundled Seabreeze project (LSARC/1998/476) which also uses and manages these databases should be the administrative inter- face. The committee felt that it was not sufficient to depend on an unbundled product as the only administrative interface. The project team responded by modifying existing bundled CLIs and adding new CLIs. A secondary issue was the interdependence of this case with PSARC/1997/331 (Process Privilege Mechanisms) or PSARC/1997/334 (Security Policy Hook Architecture). The project team assured the committee that there was none beyond a shared configuration file that was to be presented with PSARC/1997/334. That file (policy.conf(4)) is now included with this case. 4.1. Authorization Names There was discussion about the syntax of authorization names. The project team has proposed "com.sun..". Members of the committee thought the "com.sun." prefix was perhaps too long, too internal sounding, or potentially objectionable to Solaris OEMs. Alternative proposals of "solaris.", "sol." or "sunw." were made. The project team said they were open to a required technical change. However, since the Seabreeze project (LSARC/1998/476) was already in beta test with the PSARC/1997/332 Copyright 1999 Sun Microsystems - 5 - "com.sun." prefix, the project team did not feel it was appropriate to change the prefix without a required change from the committee. Any change required must be coordinated with an LSARC required change for Seabreeze. Tim Marsland contacted the "OEM ready" team on behalf of | this case. Based on the response from the "OEM ready" team, | the project team has changed the "com.sun" prefix to the | recommended "solaris" prefix and coordinated the change with | the Seabreeze project. | 4.2. Authorization and Keyword Registry The naming convention for authorization names is adequate for external customers to manage their own name space. Within Sun and Solaris the naming convention requires a registry for authorization names. There being no other established registry agent, the project team volunteered to act as the registry. A mail alias will be established for this purpose. Unlike authorization names which are hierarchical and have a partitioned name space, keywords in the databases reside in a flat name space. The project team advised that keywords for groups outside Sun should use a unique prefix. The pro- ject team volunteered to act as the registry for Sun. A mail alias will be established for this purpose. 4.3. LDAP The databases as presented do not support LDAP because there is no native LDAP support in the current gate. The project team plans to assist the PSARC/1998/361 project team to include these databases in the native LDAP support. 4.4. Increased Use of setuid Programs | Finally, there was some discussion of the fact that more | programs would be setuid-enabled. These programs are | characterized as those that interpret authorizations and are | not presently setuid-enabled. For programs which interpret | authorizations, the project team intends to implement the | "Principle of Least Privilege" by turning off the effective | "root" uid at the beginning of the program and only turning | it back on for the required privilege operations. For pro- | grams which do not interpret authorization, but need to be | run as "root," the role mechanism and the use of execution | profiles to enable "root privilege" for select users of | those programs provides an advantage over running a "root | shell". The committee concluded that this arrangement is | more secure from a technical standpoint, but a minority expressed some skepticism over the notion that more PSARC/1997/332 Copyright 1999 Sun Microsystems - 6 - (perhaps, in the future, many more) setuid programs would be viewed negatively by the market. The steering committee is advised to ensure that proper marketing precedes this product's launch and implementation in order to address such concerns. 5. Minority Opinion(s) None. 6. Advisory Information 6.1. Bundled Administrative Tools | The committee felt that the presently bundled tools for administering Solaris databases are inadequate. The team had expected to rely on the unbundled Seabreeze product (LSARC/1998/476) for administration. When advised by the committee that unbundled administration was not acceptable, the project team responded by modifying the existing useradd/del/mod(1M) CLIs and adding new roleadd/del/mod(1M) CLIs. While such CLIs are acceptable for this case, the project team points out that they would have preferred to follow a more encompassing administrative framework and would have done so if it were bundled. The committee agreed, observing that the issue might have been moot had Seabreeze been a part of Foundation Solaris. The project team is working with the Seabreeze team to provide an encom- passing administration framework for user databases. Both the Seabreeze framework and the Viper framework (the follow-on to Solaris Management Console LSARC/1999/313) make use of this project's user attribute and authorization data- bases and mechanisms. 6.2. Future Projects | As part of mail correspondence subsequent to the review | meeting, the question of the use of this case in future pro- | jects was discussed. In order to make full use of this case | for administration and control in Solaris the committee | recommends that future projects to formalize roles and the | use of authorizations in Solaris be created. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. PSARC/1997/332 Copyright 1999 Sun Microsystems - 7 - 7.3. Appendix C: Reference Material 1. Final specification. File: PSARC/1997/332/commitment.materials/* 2. Mail. File: PSARC/1997/332/mail PSARC/1997/332 Copyright 1999 Sun Microsystems From Joseph.Kowalski@eng.sun.com Fri Apr 23 09:58:22 1999 Date: Fri, 23 Apr 1999 09:56:27 -0700 (PDT) From: Joseph Kowalski Subject: Re: 1997/332: Execution Profiles To: gary.winiger@Ebay.Sun.COM, glenn.faden@Ebay.Sun.COM, psarc@sac.eng.sun.com, Brian.Wong@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /RpOxjhlyke6VBozdJHv+A== Content-Length: 1799 Maybe I just missed this at the reviews, but I was surprized at some of the commitment levels... |auths(1) | evolving | | |pfcsh(1) | evolving | | |pfexec(1) | evolving | | |pfksh(1) | evolving | | |pfsh(1) | evolving | | |profiles(1) | evolving | | |roles(1) | evolving | | | | | | |roleadd(1M) | evolving | useradd(1M) | |roledel(1M) | evolving | userdel(1M) | |rolemod(1M) | evolving | usermod(1M) | |useradd(1M) | evolving | New options for| | | | authorizations | | | | and profiles | |userdel(1M) | evolving | Updates addi-| | | | tional files | |usermod(1M) | evolving | New options for| | | | authorizations | | | | and profiles | With the underlying section 3 interfaces being stable, what is it about these new commands which makes them "less than stable"? If they are "less than stable", is this made clear on the manual pages? In particular, I would assert that the existing useradd/userdel/usermod utilities are stable. Its possible (but pretty confusing) to add evolving options to a stable command, but is this necessary? If it is necessary, how will this be made clear on the man-page? (A nit on the opinion is that "userdel(1M)" as a comment doesn't say much. Should this be "Modeled after userdel(1M)"?) - jek3 From Gary.Winiger@Ebay.Sun.COM Fri Apr 23 11:11:43 1999 Date: Fri, 23 Apr 1999 11:11:15 -0700 From: Gary.Winiger@Ebay.Sun.COM (Gary Winiger) To: gary.winiger@Ebay.Sun.COM, glenn.faden@Ebay.Sun.COM, psarc@sac.eng.sun.com, Brian.Wong@eng.sun.com, Joseph.Kowalski@eng.sun.com Subject: Re: 1997/332: Execution Profiles Content-Length: 3230 Joe, > Maybe I just missed this at the reviews, but I was surprized at some of > the commitment levels... Thanks for your comments. > |auths(1) | evolving | | > |pfcsh(1) | evolving | | > |pfexec(1) | evolving | | > |pfksh(1) | evolving | | > |pfsh(1) | evolving | | > |profiles(1) | evolving | | > |roles(1) | evolving | | > | | | | > |roleadd(1M) | evolving | useradd(1M) | > |roledel(1M) | evolving | userdel(1M) | > |rolemod(1M) | evolving | usermod(1M) | > |useradd(1M) | evolving | New options for| > | | | authorizations | > | | | and profiles | > |userdel(1M) | evolving | Updates addi-| > | | | tional files | > |usermod(1M) | evolving | New options for| > | | | authorizations | > | | | and profiles | > > With the underlying section 3 interfaces being stable, what is it about > these new commands which makes them "less than stable"? If they are > "less than stable", is this made clear on the manual pages? The project team has probably been overly cautious. We couldn't find a commitment level for the user* commands and guessed at evolving. Seems like we picked wrong. The stability of pfsh, pfcsh, and pfksh can be changed to stable. Based on a suggestion by Casper Dik, during our design review, we removed the policy specific code from the shells and put it in a new pfexec(1) command, which the shells invoke. As pfexec(1) is new, we believe it would be safer to note it as evolving. For useradd, roleadd, usermod, and rolemod, new command options will be added in the future to set additional attributes. Since we can add new attributes (key-value pairs) without changing the API, we felt these commands are evolving. The roledel and userdel are stable. For auths, profiles, and roles, new output options will be added in the future. Thus we thought these commands were evolving. All of the forseeable changes are backward compatible. If that allows the commands to be stable, the project team will gladly make make them stable. > In particular, I would assert that the existing useradd/userdel/usermod > utilities are stable. Its possible (but pretty confusing) to add evolving > options to a stable command, but is this necessary? If it is necessary, > how will this be made clear on the man-page? > > (A nit on the opinion is that "userdel(1M)" as a comment doesn't say much. > Should this be "Modeled after userdel(1M)"?) The comment was to indicate that changes to userdel update additional files. Yes, the userdel man page is modeled after the existing userdel man page. --Glenn and Gary.. P.S. The commit.materials have been updated to reflect the changes noted in the recirculated draft opinion. From Joseph.Kowalski@eng.sun.com Fri Apr 23 11:23:11 1999 Date: Fri, 23 Apr 1999 11:21:16 -0700 (PDT) From: Joseph Kowalski Subject: Re: 1997/332: Execution Profiles To: gary.winiger@Ebay.Sun.COM, glenn.faden@Ebay.Sun.COM, psarc@sac.eng.sun.com, Brian.Wong@eng.sun.com, Joseph.Kowalski@eng.sun.com, Gary.Winiger@Ebay.Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yPlY2aBrtdC0Z+41FzYBog== Content-Length: 1053 > All of the forseeable changes are backward compatible. If that > allows the commands to be stable, the project team will gladly make > make them stable. That would be the case. You can always add 100% compatable stuff. Since these are new, I'd suggest that the command lines, return values, etc., be made stable and any textual output be made evolving. (You probably don't want people parsing any of this anyway.) > > (A nit on the opinion is that "userdel(1M)" as a comment doesn't say > > much. Should this be "Modeled after userdel(1M)"?) > > The comment was to indicate that changes to userdel update additional > files. Yes, the userdel man page is modeled after the existing > userdel man page. I was refering to the following lines in the interface table: |roleadd(1M) | evolving | useradd(1M) | |roledel(1M) | evolving | userdel(1M) | |rolemod(1M) | evolving | usermod(1M) | not the lines for user*(1M) themselves. I think this is mostly a comment for Brian. - jek3 From Gary.Winiger@Ebay.Sun.COM Fri Apr 23 11:49:31 1999 Date: Fri, 23 Apr 1999 11:49:02 -0700 From: Gary.Winiger@Ebay.Sun.COM (Gary Winiger) To: gary.winiger@Ebay.Sun.COM, glenn.faden@Ebay.Sun.COM, psarc@sac.eng.sun.com, Brian.Wong@eng.sun.com, Joseph.Kowalski@eng.sun.com, Gary.Winiger@Ebay.Sun.COM Subject: Re: 1997/332: Execution Profiles Content-Length: 1371 Joe, > > All of the forseeable changes are backward compatible. If that > > allows the commands to be stable, the project team will gladly make > > make them stable. > > That would be the case. You can always add 100% compatable stuff. > > Since these are new, I'd suggest that the command lines, return > values, etc., be made stable and any textual output be made evolving. > (You probably don't want people parsing any of this anyway.) Fine with us. Can you help us with what we have to do to express this? Or is it just a line in the opinion that Brian gets to update? Ya, parsing text output is almost never a good idea. > > > (A nit on the opinion is that "userdel(1M)" as a comment doesn't say > > > much. Should this be "Modeled after userdel(1M)"?) > > > > The comment was to indicate that changes to userdel update additional > > files. Yes, the userdel man page is modeled after the existing > > userdel man page. > > I was refering to the following lines in the interface table: > > |roleadd(1M) | evolving | useradd(1M) | > |roledel(1M) | evolving | userdel(1M) | > |rolemod(1M) | evolving | usermod(1M) | > > not the lines for user*(1M) themselves. I think this is mostly a comment > for Brian. OK, that was the intent by referring to user* in the comment section. Gary.. From blw@chessie Fri Apr 23 11:56:33 1999 Date: Fri, 23 Apr 1999 11:56:39 -0700 From: blw@chessie (Brian Wong - Strategic Enterprise Technologies) To: Gary.Winiger@Ebay.Sun.COM, glenn.faden@Ebay.Sun.COM, psarc@sac.eng.sun.com Subject: Re: 1997/332: Execution Profiles Content-Length: 1577 # > > All of the forseeable changes are backward compatible. If that # > > allows the commands to be stable, the project team will gladly make # > > make them stable. # > # > That would be the case. You can always add 100% compatable stuff. # > # > Since these are new, I'd suggest that the command lines, return # > values, etc., be made stable and any textual output be made evolving. # > (You probably don't want people parsing any of this anyway.) # # Fine with us. Can you help us with what we have to do to express # this? Or is it just a line in the opinion that Brian gets to update? # # Ya, parsing text output is almost never a good idea. I'll change the wording, but it would be wise to note the equivalent on the man page, else people won't know not to try to parse them. # > > > (A nit on the opinion is that "userdel(1M)" as a comment doesn't say # > > > much. Should this be "Modeled after userdel(1M)"?) # > > # > > The comment was to indicate that changes to userdel update additional # > > files. Yes, the userdel man page is modeled after the existing # > > userdel man page. # > # > I was refering to the following lines in the interface table: # > # > |roleadd(1M) | evolving | useradd(1M) | # > |roledel(1M) | evolving | userdel(1M) | # > |rolemod(1M) | evolving | usermod(1M) | # > # > not the lines for user*(1M) themselves. I think this is mostly a comment # > for Brian. # # OK, that was the intent by referring to user* in the comment section. I'll update this too. From blw@majipoor.eng.sun.com Wed Apr 28 15:34:05 1999 Date: Wed, 28 Apr 1999 15:32:07 -0700 (PDT) From: Brian Wong To: psarc@sac.eng.sun.com Cc: gary.winigar@ebay, glenn.faden@ebay Subject: 1997/332: draft opinion for vote Content-Length: 15721 Here is the opinion as currently amended in regards to the comments as of now. Dave, is voting by email sufficient? blw sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Execution Profiles for Restricted Environ- ments Submitted by: Glenn Faden, Gary Winiger File: PSARC/1997/332/opinion.ms Date: April 21, 1999 | Committee: Brian Wong, Ralph Campbell, Joseph Kowalski, Tim Marsland, David Robinson, Andy Rudoff, Steve Zucker Steering Committee: Solaris Operating Environment Steering Com- mittee (soesc@sac.eng) 1. Summary This project provides the ability to assign arbitrary sets of attributes to users and roles. Attributes specify which accounts are roles, which roles are granted to users, and the specific authorizations and execution profiles which have been granted to an account. In addition, new attri- butes can be defined without any changes to the API. A role is a type of shared account which can only be accessed through a secondary login mechanism such as su(1M), and is only available to specified users. An authorization is a right granted to a user or role to perform a function which is not generally allowed. Trusted applications check that a user (or role) is authorized before performing restricted operations. A profile is a bundling mechanism that contains the list of commands and authorizations required to perform a particular function. For each command, the profile may specify the effective user id and/or the effective group id to be used when executing the command. Authorizations and commands from multiple profiles are additive. Assigning a profile to a role allows users who can assume that role to perform specific privileged operations without giving users access to all superuser powers. For example, a user might be able to administer the printer subsystem, but not add users or change the password of other users. This project provides a CLI for assigning roles, PSARC/1997/332 Copyright 1999 Sun Microsystems - 2 - authorizations, and profiles to users and a "C" API, the data structures and database formats, and conventions for using authorizations, roles, and profiles. 2. Decision & Precedence Information This project is approved as specified in reference [1]. This project may be delivered in a minor release of Solaris. This project and the following project are required to coor- dinate to ensure that the databases introduced by this pro- ject are available through LDAP. PSARC/1998/361 Native LDAP 3. Interfaces The project exports the following interfaces. ____________________________________________________________ | Interfaces Exported | |__________________|________________|______________________| |Interface | Classification| Comments | |__________________|________________|______________________| |auths(1) | evolving | | |pfcsh(1) | evolving | | |pfexec(1) | evolving | | | |pfksh(1) | evolving | | |pfsh(1) | evolving | | |profiles(1) | Stable | | |roles(1) | Stable | | | | | | |roleadd(1M) | Stable | based on useradd(1M)| |roledel(1M) | Stable | based on userdel(1M)| |rolemod(1M) | Stable | based on usermod(1M)| |useradd(1M) | Stable | New options for| | | | authorizations and| | | | profiles | |userdel(1M) | Stable | Updates additional| | | | files | |usermod(1M) | Stable | New options for| | | | authorizations and| | | | profiles | | | | | |kva_match(3) | Stable | | | | | | |getauthattr(3) | Stable | | |getauthnam(3) | Stable | | |setauthattr(3) | Stable | | |endauthattr(3) | Stable | | |free_authattr(3) | Stable | | |chkauthattr(3) | Stable | | | | | | |__________________|________________|______________________| PSARC/1997/332 Copyright 1999 Sun Microsystems - 3 - ____________________________________________________________ | Interfaces Exported | |__________________|________________|______________________| |Interface | Classification| Comments | |__________________|________________|______________________| |getexecattr(3) | Stable | | |getexecuser(3) | Stable | | |getexecprof(3) | Stable | | |setexecattr(3) | Stable | | |endexecattr(3) | Stable | | |match_execattr(3) | Stable | | | | | | |getprofattr(3) | Stable | | |getprofnam(3) | Stable | | |setprofattr(3) | Stable | | |endprofattr(3) | Stable | | |free_profattr(3) | Stable | | | | | | |getuserattr(3) | Stable | | |getuserid(3) | Stable | | |getusernam(3) | Stable | | |setuserattr(3) | Stable | | |enduserattr(3) | Stable | | |free_userattr(3) | Stable | | | | | | |getauusernam(3) | Stable | Existing interface| | | | updated to use| | | | nsswitch | |getauusernam_r(3) | Stable | getauusernam(3) | | | | | |pam_role_auth.so.1| Evolving | pam_role_auths(5) | |libsecdb.so.1 | Stable | kva_match(3) | | | | | |auth_attr(4) | Evolving | Extensible without| | | | breaking backward| | | | compatibility | |exec_attr(4) | Evolving | Extensible without| | | | breaking backward| | | | compatibility | |prof_attr(4) | Evolving | Extensible without| | | | breaking backward| | | | compatibility | |user_attr(4) | Evolving | Extensible without| | | | breaking backward| | | | compatibility | | | | | |audit_user(4) | Evolving | No change to data-| | | | base, now supports| | | | nsswitch | |policy.conf(4) | Evolving | | |__________________|________________|______________________| PSARC/1997/332 Copyright 1999 Sun Microsystems - 4 - The project imports the following interfaces. _________________________________________________________ | Interfaces Imported | |_______________|_____________________|_________________| |Interface | Classification | Comments | |_______________|_____________________|_________________| |_nss_XbyY_fgets| consolation private| libc promoted| | | | from not visi-| | | | ble to Sun| | | | Private | |_______________|_____________________|_________________| 4. Opinion There were a number of issues raised at the commitment review. These were responded to in [2]. The primary issue was that no bundled administrative interfaces were being supplied. The project team felt that the unbundled Seabreeze project (LSARC/1998/476) which also uses and manages these databases should be the administrative inter- face. The committee felt that it was not sufficient to depend on an unbundled product as the only administrative interface. The project team responded by modifying existing bundled CLIs and adding new CLIs. A secondary issue was the interdependence of this case with PSARC/1997/331 (Process Privilege Mechanisms) or PSARC/1997/334 (Security Policy Hook Architecture). The project team assured the committee that there was none beyond a shared configuration file that was to be presented with PSARC/1997/334. That file (policy.conf(4)) is now included with this case. 4.1. Authorization Names There was discussion about the syntax of authorization names. The project team has proposed "com.sun..". Members of the committee thought the "com.sun." prefix was perhaps too long, too internal sounding, or potentially objectionable to Solaris OEMs. Alternative proposals of "solaris.", "sol." or "sunw." were made. The project team said they were open to a required technical change. However, since the Seabreeze project (LSARC/1998/476) was already in beta test with the "com.sun." prefix, the project team did not feel it was appropriate to change the prefix without a required change from the committee. Any change required must be coordinated with an LSARC required change for Seabreeze. Tim Marsland contacted the "OEM ready" team on behalf of | PSARC/1997/332 Copyright 1999 Sun Microsystems - 5 - this case. Based on the response from the "OEM ready" team, | the project team has changed the "com.sun" prefix to the | recommended "solaris" prefix and coordinated the change with | the Seabreeze project. | 4.2. Authorization and Keyword Registry The naming convention for authorization names is adequate for external customers to manage their own name space. Within Sun and Solaris the naming convention requires a registry for authorization names. There being no other established registry agent, the project team volunteered to act as the registry. A mail alias will be established for this purpose. Unlike authorization names which are hierarchical and have a partitioned name space, keywords in the databases reside in a flat name space. The project team advised that keywords for groups outside Sun should use a unique prefix. The pro- ject team volunteered to act as the registry for Sun. A mail alias will be established for this purpose. 4.3. LDAP The databases as presented do not support LDAP because there is no native LDAP support in the current gate. The project team plans to assist the PSARC/1998/361 project team to include these databases in the native LDAP support. 4.4. Increased Use of setuid Programs | Finally, there was some discussion of the fact that more | programs would be setuid-enabled. These programs are | characterized as those that interpret authorizations and are | not presently setuid-enabled. For programs which interpret | authorizations, the project team intends to implement the | "Principle of Least Privilege" by turning off the effective | "root" uid at the beginning of the program and only turning | it back on for the required privilege operations. For pro- | grams which do not interpret authorization, but need to be | run as "root," the role mechanism and the use of execution | profiles to enable "root privilege" for select users of | those programs provides an advantage over running a "root | shell". The committee concluded that this arrangement is | more secure from a technical standpoint, but a minority expressed some skepticism over the notion that more (perhaps, in the future, many more) setuid programs would be viewed negatively by the market. The steering committee is advised to ensure that proper marketing precedes this product's launch and implementation in order to address such concerns. PSARC/1997/332 Copyright 1999 Sun Microsystems - 6 - 5. Minority Opinion(s) None. 6. Advisory Information 6.1. Bundled Administrative Tools | The committee felt that the presently bundled tools for administering Solaris databases are inadequate. The team had expected to rely on the unbundled Seabreeze product (LSARC/1998/476) for administration. When advised by the committee that unbundled administration was not acceptable, the project team responded by modifying the existing useradd/del/mod(1M) CLIs and adding new roleadd/del/mod(1M) CLIs. While such CLIs are acceptable for this case, the project team points out that they would have preferred to follow a more encompassing administrative framework and would have done so if it were bundled. The committee agreed, observing that the issue might have been moot had Seabreeze been a part of Foundation Solaris. The project team is working with the Seabreeze team to provide an encom- passing administration framework for user databases. Both the Seabreeze framework and the Viper framework (the follow-on to Solaris Management Console LSARC/1999/313) make use of this project's user attribute and authorization data- bases and mechanisms. 6.2. Future Projects | As part of mail correspondence subsequent to the review | meeting, the question of the use of this case in future pro- | jects was discussed. In order to make full use of this case | for administration and control in Solaris the committee | recommends that future projects to formalize roles and the | use of authorizations in Solaris be created. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material 1. Final specification. File: PSARC/1997/332/commitment.materials/* PSARC/1997/332 Copyright 1999 Sun Microsystems - 7 - 2. Mail. File: PSARC/1997/332/mail PSARC/1997/332 Copyright 1999 Sun Microsystems From robinson@jetsun.eng.sun.com Wed Apr 28 15:53:47 1999 Date: Wed, 28 Apr 1999 15:53:56 -0700 (PDT) From: David Robinson To: psarc@sac.eng.sun.com, blw@majipoor.eng.sun.com Subject: Re: 1997/332: draft opinion for vote Cc: gary.winigar@Ebay.Sun.COM, glenn.faden@Ebay.Sun.COM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 16516 Unless there is a pressing time concern, I would like to vote in person. -David > Here is the opinion as currently amended in regards to the comments > as of now. Dave, is voting by email sufficient? > > blw > > > sun > microsystems Systems Architecture Committee > > _________________________________________________________________ > > Subject: Execution Profiles for Restricted Environ- > ments > > Submitted by: Glenn Faden, Gary Winiger > > File: PSARC/1997/332/opinion.ms > > Date: April 21, 1999 | > > Committee: Brian Wong, Ralph Campbell, Joseph Kowalski, > Tim Marsland, David Robinson, Andy Rudoff, > Steve Zucker > > Steering Committee: > Solaris Operating Environment Steering Com- > mittee (soesc@sac.eng) > > 1. Summary > > This project provides the ability to assign arbitrary sets > of attributes to users and roles. Attributes specify which > accounts are roles, which roles are granted to users, and > the specific authorizations and execution profiles which > have been granted to an account. In addition, new attri- > butes can be defined without any changes to the API. > > A role is a type of shared account which can only be > accessed through a secondary login mechanism such as su(1M), > and is only available to specified users. > > An authorization is a right granted to a user or role to > perform a function which is not generally allowed. Trusted > applications check that a user (or role) is authorized > before performing restricted operations. > > A profile is a bundling mechanism that contains the list of > commands and authorizations required to perform a particular > function. For each command, the profile may specify the > effective user id and/or the effective group id to be used > when executing the command. Authorizations and commands > from multiple profiles are additive. Assigning a profile to > a role allows users who can assume that role to perform > specific privileged operations without giving users access > to all superuser powers. For example, a user might be able > to administer the printer subsystem, but not add users or > change the password of other users. > > This project provides a CLI for assigning roles, > > PSARC/1997/332 Copyright 1999 Sun Microsystems > > - 2 - > > authorizations, and profiles to users and a "C" API, the > data structures and database formats, and conventions for > using authorizations, roles, and profiles. > > 2. Decision & Precedence Information > > This project is approved as specified in reference [1]. > > This project may be delivered in a minor release of Solaris. > > This project and the following project are required to coor- > dinate to ensure that the databases introduced by this pro- > ject are available through LDAP. > > PSARC/1998/361 Native LDAP > > 3. Interfaces > > The project exports the following interfaces. > > ____________________________________________________________ > | Interfaces Exported | > |__________________|________________|______________________| > |Interface | Classification| Comments | > |__________________|________________|______________________| > |auths(1) | evolving | | > |pfcsh(1) | evolving | | > |pfexec(1) | evolving | | | > |pfksh(1) | evolving | | > |pfsh(1) | evolving | | > |profiles(1) | Stable | | > |roles(1) | Stable | | > | | | | > |roleadd(1M) | Stable | based on useradd(1M)| > |roledel(1M) | Stable | based on userdel(1M)| > |rolemod(1M) | Stable | based on usermod(1M)| > |useradd(1M) | Stable | New options for| > | | | authorizations and| > | | | profiles | > |userdel(1M) | Stable | Updates additional| > | | | files | > |usermod(1M) | Stable | New options for| > | | | authorizations and| > | | | profiles | > | | | | > |kva_match(3) | Stable | | > | | | | > |getauthattr(3) | Stable | | > |getauthnam(3) | Stable | | > |setauthattr(3) | Stable | | > |endauthattr(3) | Stable | | > |free_authattr(3) | Stable | | > |chkauthattr(3) | Stable | | > | | | | > |__________________|________________|______________________| > > PSARC/1997/332 Copyright 1999 Sun Microsystems > > - 3 - > > ____________________________________________________________ > | Interfaces Exported | > |__________________|________________|______________________| > |Interface | Classification| Comments | > |__________________|________________|______________________| > |getexecattr(3) | Stable | | > |getexecuser(3) | Stable | | > |getexecprof(3) | Stable | | > |setexecattr(3) | Stable | | > |endexecattr(3) | Stable | | > |match_execattr(3) | Stable | | > | | | | > |getprofattr(3) | Stable | | > |getprofnam(3) | Stable | | > |setprofattr(3) | Stable | | > |endprofattr(3) | Stable | | > |free_profattr(3) | Stable | | > | | | | > |getuserattr(3) | Stable | | > |getuserid(3) | Stable | | > |getusernam(3) | Stable | | > |setuserattr(3) | Stable | | > |enduserattr(3) | Stable | | > |free_userattr(3) | Stable | | > | | | | > |getauusernam(3) | Stable | Existing interface| > | | | updated to use| > | | | nsswitch | > |getauusernam_r(3) | Stable | getauusernam(3) | > | | | | > |pam_role_auth.so.1| Evolving | pam_role_auths(5) | > |libsecdb.so.1 | Stable | kva_match(3) | > | | | | > |auth_attr(4) | Evolving | Extensible without| > | | | breaking backward| > | | | compatibility | > |exec_attr(4) | Evolving | Extensible without| > | | | breaking backward| > | | | compatibility | > |prof_attr(4) | Evolving | Extensible without| > | | | breaking backward| > | | | compatibility | > |user_attr(4) | Evolving | Extensible without| > | | | breaking backward| > | | | compatibility | > | | | | > |audit_user(4) | Evolving | No change to data-| > | | | base, now supports| > | | | nsswitch | > |policy.conf(4) | Evolving | | > |__________________|________________|______________________| > > PSARC/1997/332 Copyright 1999 Sun Microsystems > > - 4 - > > The project imports the following interfaces. > > _________________________________________________________ > | Interfaces Imported | > |_______________|_____________________|_________________| > |Interface | Classification | Comments | > |_______________|_____________________|_________________| > |_nss_XbyY_fgets| consolation private| libc promoted| > | | | from not visi-| > | | | ble to Sun| > | | | Private | > |_______________|_____________________|_________________| > > 4. Opinion > > There were a number of issues raised at the commitment > review. These were responded to in [2]. The primary issue > was that no bundled administrative interfaces were being > supplied. The project team felt that the unbundled > Seabreeze project (LSARC/1998/476) which also uses and > manages these databases should be the administrative inter- > face. The committee felt that it was not sufficient to > depend on an unbundled product as the only administrative > interface. The project team responded by modifying existing > bundled CLIs and adding new CLIs. > > A secondary issue was the interdependence of this case with > PSARC/1997/331 (Process Privilege Mechanisms) or > PSARC/1997/334 (Security Policy Hook Architecture). The > project team assured the committee that there was none > beyond a shared configuration file that was to be presented > with PSARC/1997/334. That file (policy.conf(4)) is now > included with this case. > > 4.1. Authorization Names > > There was discussion about the syntax of authorization > names. The project team has proposed > "com.sun..". Members of the committee > thought the "com.sun." prefix was perhaps too long, too > internal sounding, or potentially objectionable to Solaris > OEMs. Alternative proposals of "solaris.", "sol." or > "sunw." were made. The project team said they were open to > a required technical change. However, since the Seabreeze > project (LSARC/1998/476) was already in beta test with the > "com.sun." prefix, the project team did not feel it was > appropriate to change the prefix without a required change > from the committee. > > Any change required must be coordinated with an LSARC > required change for Seabreeze. > > Tim Marsland contacted the "OEM ready" team on behalf of | > > PSARC/1997/332 Copyright 1999 Sun Microsystems > > - 5 - > > this case. Based on the response from the "OEM ready" team, | > the project team has changed the "com.sun" prefix to the | > recommended "solaris" prefix and coordinated the change with | > the Seabreeze project. | > > 4.2. Authorization and Keyword Registry > > The naming convention for authorization names is adequate > for external customers to manage their own name space. > Within Sun and Solaris the naming convention requires a > registry for authorization names. There being no other > established registry agent, the project team volunteered to > act as the registry. A mail alias will be established for > this purpose. > > Unlike authorization names which are hierarchical and have a > partitioned name space, keywords in the databases reside in > a flat name space. The project team advised that keywords > for groups outside Sun should use a unique prefix. The pro- > ject team volunteered to act as the registry for Sun. A > mail alias will be established for this purpose. > > 4.3. LDAP > > The databases as presented do not support LDAP because there > is no native LDAP support in the current gate. The project > team plans to assist the PSARC/1998/361 project team to > include these databases in the native LDAP support. > > 4.4. Increased Use of setuid Programs | > > Finally, there was some discussion of the fact that more | > programs would be setuid-enabled. These programs are | > characterized as those that interpret authorizations and are | > not presently setuid-enabled. For programs which interpret | > authorizations, the project team intends to implement the | > "Principle of Least Privilege" by turning off the effective | > "root" uid at the beginning of the program and only turning | > it back on for the required privilege operations. For pro- | > grams which do not interpret authorization, but need to be | > run as "root," the role mechanism and the use of execution | > profiles to enable "root privilege" for select users of | > those programs provides an advantage over running a "root | > shell". The committee concluded that this arrangement is | > more secure from a technical standpoint, but a minority > expressed some skepticism over the notion that more > (perhaps, in the future, many more) setuid programs would be > viewed negatively by the market. The steering committee is > advised to ensure that proper marketing precedes this > product's launch and implementation in order to address such > concerns. > > PSARC/1997/332 Copyright 1999 Sun Microsystems > > - 6 - > > 5. Minority Opinion(s) > > None. > > 6. Advisory Information > > 6.1. Bundled Administrative Tools | > > The committee felt that the presently bundled tools for > administering Solaris databases are inadequate. The team > had expected to rely on the unbundled Seabreeze product > (LSARC/1998/476) for administration. When advised by the > committee that unbundled administration was not acceptable, > the project team responded by modifying the existing > useradd/del/mod(1M) CLIs and adding new roleadd/del/mod(1M) > CLIs. While such CLIs are acceptable for this case, the > project team points out that they would have preferred to > follow a more encompassing administrative framework and > would have done so if it were bundled. The committee > agreed, observing that the issue might have been moot had > Seabreeze been a part of Foundation Solaris. The project > team is working with the Seabreeze team to provide an encom- > passing administration framework for user databases. > > Both the Seabreeze framework and the Viper framework (the > follow-on to Solaris Management Console LSARC/1999/313) make > use of this project's user attribute and authorization data- > bases and mechanisms. > > 6.2. Future Projects | > > As part of mail correspondence subsequent to the review | > meeting, the question of the use of this case in future pro- | > jects was discussed. In order to make full use of this case | > for administration and control in Solaris the committee | > recommends that future projects to formalize roles and the | > use of authorizations in Solaris be created. > > 7. Appendices > > 7.1. Appendix A: Technical Changes Required > > None. > > 7.2. Appendix B: Technical Changes Advised > > None. > > 7.3. Appendix C: Reference Material > > 1. Final specification. File: > PSARC/1997/332/commitment.materials/* > > PSARC/1997/332 Copyright 1999 Sun Microsystems > > - 7 - > > 2. Mail. File: PSARC/1997/332/mail > > PSARC/1997/332 Copyright 1999 Sun Microsystems > > From Glenn.Faden@Ebay.Sun.COM Wed Apr 28 16:07:10 1999 Date: Wed, 28 Apr 1999 16:15:34 -0700 (PDT) From: Glenn Faden Subject: Re: 1997/332: draft opinion for vote To: psarc@sac.eng.sun.com, blw@majipoor.eng.sun.com, David.Robinson@eng.sun.com Cc: gary.winigar@Ebay.Sun.COM, glenn.faden@Ebay.Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bTRwMxJs8W/3lrukuC9zCQ== Content-Length: 580 Dave, We are still trying to get into Solaris 8 as a late binding. Our case is tentatively scheduled for SOESC commitment review next Wednesday. The SOESC wants to know if the case is (or will soon be) approved by PSARC before they will allow us to do a commitment review. So from our perspective, there is a pressing time concern. --Glenn > > Unless there is a pressing time concern, I would like to vote > in person. > > -David > > > Here is the opinion as currently amended in regards to the comments > > as of now. Dave, is voting by email sufficient? > > > > blw From robinson@jetsun.eng.sun.com Thu Apr 29 15:02:43 1999 Date: Thu, 29 Apr 1999 15:02:31 -0700 (PDT) From: David Robinson Subject: Re: 1997/332: draft opinion for vote To: Glenn Faden cc: psarc@sac.eng.sun.com, blw@majipoor.eng.sun.com, David.Robinson@eng.sun.com, gary.winigar@Ebay.Sun.COM, glenn.faden@Ebay.Sun.COM Content-Type: text X-Sun-Text-Type: ascii Content-Length: 1037 In the issue of helping this project run through the process I would like anyone who believes they will have a comment that will prevent this case from being approved, please send out e-mail by Monday. Lacking any objections the project should be able to assert a high probablility of approval to the SOESC. Any wording or generally agreeable changes can be done and we will take a final vote on Wednesday. -David > We are still trying to get into Solaris 8 as a late binding. > > Our case is tentatively scheduled for SOESC commitment > review next Wednesday. The SOESC wants to know if the > case is (or will soon be) approved by PSARC before they will > allow us to do a commitment review. > > So from our perspective, there is a pressing time concern. > > --Glenn > > > > > Unless there is a pressing time concern, I would like to vote > > in person. > > > > -David > > > > > Here is the opinion as currently amended in regards to the comments > > > as of now. Dave, is voting by email sufficient? > > > > > > blw > From gww@sac.sfbay.sun.com Wed Oct 22 16:47:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MNlGKH011163 for ; Wed, 22 Oct 2008 16:47:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9MNlCho000389; Thu, 23 Oct 2008 07:47:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9500L01ZEPVX00@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Oct 2008 16:47:13 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9500JJGZEOPK20@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Oct 2008 16:47:13 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9MNlClM033823; Wed, 22 Oct 2008 16:47:12 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9MNlCOK011161; Wed, 22 Oct 2008 16:47:12 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m9MNlCK0011160; Wed, 22 Oct 2008 16:47:12 -0700 (PDT) Date: Wed, 22 Oct 2008 16:47:12 -0700 (PDT) From: Gary Winiger Subject: Redacted -- PSARC/1997/332 Execution Profiles for Restricted Environments To: psarc-ext@sun.com Cc: glenn.faden@sun.com, gww@sun.com Message-id: <200810222347.m9MNlCK0011160@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 284 I redacted this case today. Presuming I did it correctly, it should be published to the OpenSolaris ARC web site the next time the site update scripts run. I presume John Plocher will contact me if I've not been complete in my recaction as the update scripts won't publish. Gary..