From Darren.Moffat@sun.com Fri Jan 23 05:11:11 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0NDBAjL013661 for ; Fri, 23 Jan 2009 05:11:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0NDB01B026045 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Fri, 23 Jan 2009 13:11:09 GMT 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 <0KDX0012PDYJ3P00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 23 Jan 2009 05:11:07 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDX000MKDYHKA30@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 23 Jan 2009 05:11:06 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0NDB54v006208 for ; Fri, 23 Jan 2009 13:11:05 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KDX001019MX5Y00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 23 Jan 2009 13:11:05 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KDX00MJ3DY8OF80@fe-emea-10.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 23 Jan 2009 13:10:56 +0000 (GMT) Date: Fri, 23 Jan 2009 13:10:56 +0000 From: Darren J Moffat Subject: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com Cc: Bart.Blanquart@sun.com Message-id: <4979C1E0.2050404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 19997 I'm sponsoring this fast-track for Bart Blanquart and myself. Timer is set for Friday 30th Jan 2009. Release binding is patch but with no intention to backport to Solaris 10. Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Authorisation based login control: pam_auths 1.2. Name of Document Author/Supplier: Bart Blanquart, Darren Moffat 1.3. Date of This Document: 2008-12-4 1.3.1. Date this project was conceived: 2008-09 2. Project Summary 2.1. Project Description: pam_auths checks for the authorizations 3. Business Summary 3.1. Problem Area: The module provides a simple way of controlling access using authorizations, thereby offering a nameservice-shareable repository and a unified administrative model for controlling user rights. 3.2. Market/Requester: RBAC users. 4. Technical Description: 4.1. Details: pam_auths.so.1 when called in pam_acct_mgmt will check if the user who is being authenticated has the necessary authorizations. The authorizations the module will check for can be: - default solaris.login authorizations and optionally - specified in the auths= option OR - specified in the login_policy_profile= option OR - specified in policy.conf(4) LOGIN_POLICY_PROFILE= The solaris.login authorizations are checked for if the relevant pam_data items are present. +----------------------------+-----------------------------------+ | Data item | Required authorization | +----------------------------+-----------------------------------+ | PAM_RHOST= | solaris.login.remote | +----------------------------+-----------------------------------+ | PAM_TTY=/dev/console | solaris.login.console | +----------------------------+-----------------------------------+ | PAM_TTY= | solaris.login.local | +----------------------------+-----------------------------------+ If no module options are specified, LOGIN_POLICY_PROFILE is unset and none of the above items are set the module returns PAM_IGNORE. The solaris.login authorizations are granted to all accounts via "Basic Solaris User", so the behaviour of the system remains the same in default configurations. If no options are specified and LOGIN_POLICY_PROFILE is set to point to a policy profile (prof_attr(4)) any of the authorizations in that profile are sufficient for the module to return success, assuming the solaris.login checks succeeded or were unnecessary (both PAM_RHOST and PAM_TTY absent). (While at this point there is nothing fundamentally different between a "rights profile" as assigned to users and a "policy profile" as specified as argument here they are conceptually different: the first assigns all rights and auths it contains, while the latter is used to check for any of the auths -- hence the difference in terminology.) If auths= is specified any of the authorizations listed are sufficient for the module to return success, assuming the solaris.login checks succeeded or were unnecessary. If the login_policy_profile= option is specified any one of the authorizations in the profile is needed for the module to return success, assuming the solaris.login checks succeeded or were unnecessary. If either auths= or login_policy_profile= are specified the policy.conf(4) parameter is ignored: it only functions as a mechanism for providing a generic (fallback) configuration. If both auths= and login_policy_profile= are specified the module returns PAM_SERVICE_ERR. In any of the ways of specifying authorizations or policy profiles to the module it is possible to use tokens that will be substituted at run time. This run-time substitution permits a single configuration option (policy.conf(4)'s LOGIN_POLICY_PROFILE=) to point to per-host or per- domain policy profiles, permitting login authorization policies to be set via the nameservice. The substitutable tokens are: %d is replaced by the DNS domain name. %D is replaced by the reverse order DNS domain, listing the top-level domain first, domain second and so on (e.g. a domain name of "east.sun.com" would become com.sun.east) %h is replaced by the hostname, as returned by gethostname(3C) %f is replaced by the fully qualified host name without the trailing dot (so using %f is equivalent to specifying %h.%d) %F is replaced by the reverse order fully qualified host name, without trailing or leading dot (e.g. host.east.sun.com. would become com.sun.east.host). %k is replaced by the Kerberos Realm name. %K is replaced by the reverse order Kerberos Realm name. %n is replaced by the NIS/NIS+ domain name. %N is replaced by the reverse order NIS/NIS+ domain name. If the domain name contains no dots this is equivalent to %n. The tokens to be substituted consist of "%" followed by a single letter. The "%" sign was not listed as a reserved symbol in auth_attr(4), so as part of this case it would need to be added to that man page. Considering, however, that we permit only "%?" and then only as a component (i.e. bordered on both sides by a dot) this is not expected to cause issues in existing deployments, as the likelihood of existing (third party) authorization names of that form is small. Any authorization (specified in auths=, login_policy_profile=, or LOGIN_POLICY_PROFILE) can also contain the "*" character, which permits the easy (and future-proof) specification of a whole set of authorizations: for example where you would have an auth structure like: com.xyzcompany.systems..admin com.xyzcompany.systems..secadmin com.xyzcompany.systems..auditor com.xyzcompany.systems..user specifying "auths=com.xyzcompany.systems.%h.*" would be sufficient to grant login access to the system. The implementation could be done by calling getauthnam(3SECDB) to iterate over "com.xyzcompany.systems.%h.*" and chkauthattr(3SECDB) against each entry that returns. This does assume that auth_attr(4) lists all authorizations that may have been granted, something that is not currently enforced. Addressing that limitation is beyond the scope of this project. 4.2. Bug/RFE Number(s): 6754641 4.3. In Scope: Documented functionality. 4.4. Out of Scope: A networked policy.conf replacement, that would offer an alternative way of providing per-host policy settings. Negative authorizations, permitting the removal of authorizations from specific accounts (so that the root account could be granted solaris.* while taking away solaris.login.remote and solaris.login.local). Ensuring any authorization used in prof_attr(4) or user_attr(4) is also listed in auth_attr(4). 4.5. Interfaces: +--------------------------------------+---------------+---------+ | Interface | Taxonomy | Comment | +--------------------------------------+---------------+---------+ | TBD | Uncommitted | Package | +--------------------------------------+---------------+---------+ | /usr/lib/security/pam_auths.so.1 | Committed | | +--------------------------------------+---------------+---------+ | /usr/lib/security/pam_auths.so.1 | | | | login_policy_profile= | Committed | Option | | auths= | Committed | Option | | wildcard arguments | Committed | | +--------------------------------------+---------------+---------+ | policy.conf keyword | Committed | Keyword | +--------------------------------------+---------------+---------+ | PAM config snippets | | | | (cf. PSARC/2005/275) | | | | Names | Committed |Unchanged| | Semantics* | Committed |Unchanged| | Contents | Uncommitted |Unchanged| +--------------------------------------+---------------+---------+ * The overall semantics change in that the checks for solaris.login.* authorizations are added, but as those authorizations are granted to all users via the "Basic Solaris User" rights profile the behaviour remains the same. Release Binding: patch 4.6. Doc Impact: pam_auths(5) user_attr(5) (See also) auth_attr(5) (See also, fact auths need to be listed to be considered) prof_attr(5) (Rights profiles vs. policy profiles) policy.conf(5) (LOGIN_POLICY_PROFILE, See also) 4.7. Admin/Config Impact: An extra level of control is offered, building on the existing authorizations infrastructure, but existing configurations will not be affected. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: None (no direct end-user interaction) 4.10. Packaging & Delivery: The project delivers one additional PAM module and modifies (replaces) some of the shipped PAM snippets. pam.conf need not be modified nor would local PAM snippets be changed. 4.11. Security Impact: It's a PAM module that would get added to the default stacks (snippets). 4.12. Dependencies: As this module would be listed in PAM snippets it relies on PSARC 2005/275 Per-user PAM configuration. If PSARC 2005/275 does not integrate this project would update pam.conf instead. 5. Reference Documents: 6. Resources and Schedule: 6.5. ARC review type: FastTrack 6.6. ARC Exposure: Open Standards, Environments, and Macros pam_auths(5) NAME pam_auths - PAM account management module SYNOPSIS pam_auths.so.1 DESCRIPTION The pam_auths module implements pam_sm_acct_mgmt(3PAM), which provides functionality to the PAM account management stack. The module provides functions to validate that the user has the necessary authorizations to access the system. Users logging in on the console must have the solaris.login.console authorization, while users logging in locally must have been granted the solaris.login.local auth- orization. A user logging in over the network must have the solaris.login.remote authorization. Additional required authorizations can be specified via module options. A user with any of the listed authorizations as well as the appropriate solaris.login authorization will be granted access. If no options are specified the module will read policy.conf(4) and use the value specified in LOGIN_POLICY_PROFILE= as though it was passed as a login_policy_profile= option. The following options may be passed to the module: auths= A comma-separated list of authorizations, each one of which would be sufficient to permit access. login_policy_profile= A policy profile as defined in prof_attr(4), each of the authorizations in which would be sufficient to permit access. debug Provide syslog(3C) debugging information at the LOG_AUTH | LOG_DEBUG level. The argument to auths is a comma-separated list of authorization names chosen from those names defined in the auth_attr(4) database. Wildcards may be specified as well as substitution tokens, described below. Any one authorization listed is sufficient to be granted access. The argument to policy_profile is the name of a single policy profile as defined in prof_attr(4). Any authorization in the profile (or in an included profile) is sufficient to be granted access. In the profile name no wildcards may be specified, though substitution tokens can be used. Authorization names listed in the profile can contain substitution tokens and the wildcard symbol, as though they were specified as an argument to the auths option. The same token substitution will be applied to the name of the policy profile specified in the policy.conf(4) LOGIN_POLICY_PROFILE keyword. If multiple authorizations are required to be granted access to the system the module should be specified multiple times in the appropriate pam stack. See EXAMPLES for an example or pam.conf(4) for more details about stacking PAM modules. To allow a single PAM configuration to be used on multiple systems in a network authorization or profile names can contain tokens that will be substituted when the module is invoked. The following substitutions will be applied: %d is replaced by the DNS domain name. %D is replaced by the reverse order DNS domain, listing the top-level domain first, domain second and so on (e.g. a domain name of "east.sun.com" would become com.sun.east) %h is replaced by the hostname, as returned by gethostname(3C) %f is replaced by the fully qualified host name without the trailing dot (so using %f is equivalent to specifying %h.%d) %F is replaced by the reverse order fully qualified host name, without trailing or leading dot (e.g. host.east.sun.com. would become com.sun.east.host). %k is replaced by the Kerberos Realm name. %K is replaced by the reverse order Kerberos Realm name. %n is replaced by the NIS/NIS+ domain name. %N is replaced by the reverse order NIS/NIS+ domain name. If the domain name contains no dots this is equivalent to %n. Reverse order names are provided to allow organizations that use the recommended naming scheme for authorizations (see auth_attr(4)) or a variation based on one of the other name service schemes. Reversing a name is done by splitting the name in components, where each component is separated by a dot and reversing the order of the components. Only individual components in an authorization name will be substituted, so any of the above tokes can only appear as a prefix (at the beginning of an authorization name, followed by a dot and the remainder of the authorization name), a suffix (at the end of an authorization name, preceded by a dot and followed by either a comma or space), or as an infix component (between two dots). ERRORS The following error values are returned: PAM_SERVICE_ERR An invalid set of module options was given in the pam.conf(4) for this module. PAM_BUF_ERR A memory buffer error occurred. PAM_IGNORE The module is ignored, as it is not par- ticipating in the result. PAM_PERM_DENIED The user lacks the necessary authorization(s) to log in on this host. PAM_SUCCESS The account is valid for use at this time. PAM_USER_UNKNOWN No account is present for the user EXAMPLES Example 1 Using the pam_auths.so.1 Module The following are sample entries from pam.conf(4). These entries demonstrate the use of the pam_authorizes.so.1 module: other account required pam_auths.so.1 This entry, if no LOGIN_POLICY_PROFILE keyword is specified in policy.conf(4), requires anyone logging in to have been granted the solaris.login.console authorization when logging in on the console, the solaris.login.local authorization when logging in on a virtual terminal, a terminal or a Sun Ray. A user logging in remotely would need to have been granted the solaris.login.remote authorization. Example 2 Using a default policy other account required pam_auths.so.1 This entry, with LOGIN_POLICY_PROFILE=com.xyzcompany.servers.login in policy.conf(4), requires anyone logging in to have been granted the solaris.login.console authorization when logging in on the console, the solaris.login.local authorization when logging in on a virtual terminal, a terminal or a Sun Ray. A user logging in remotely would need to have been granted the solaris.login.remote authorization. Any user logging in would need to have been granted the com.xyzcompany.servers.login authorization, in addition to the solaris.login authorization listed above. Example 3 Requiring An Additional Authorization other account required pam_auths.so.1 auths=com.xyzcompany.network.hostname This entry would require a user to have the appropiate solaris.login. authorization, as described in the example above but to also have the com.xyzcompany.network.hostname authorization. Example 4 Using Token Substitution other account required pam_auths.so.1 auths=%D.network.%h This entry would require a user to have the appropriate solaris.login. authorization, as described in Example 1 above, but to also have an additional authorization. The name of the authorization required is determined when it is invoked, so depends on the configuration of the host on which it is installed. On a host with the fully qualified hostname "sample.companyxyz.com" the authorization required would be "com.companyxyz.network.sample". Example 5 Requiring Multiple Authorizations other account required pam_auths.so.1 auths=com.xyzcompany.access.server other account required pam_auths.so.1 auths=com.xyzcompany.access.dmz,com.xyzcompany.access.sensitive other account required pam_auths.so.1 auths=com.xyzcompany.access.dns These entries would require anyone logging in to have been granted three authorizations: com.xyzcompany.access.server, com.xyzcompany.access.dns and either com.xyzcompany.access.dmz or com.xyzcompany.access.sensitive. Example 6 Requiring Specific Authorizations for Console and Remote Logins sshd-pubkey account required pam_auths.so.1 auths=com.xyzcompany.access.server.network sshd-kbdint account required pam_auths.so.1 auths=com.xyzcompany.access.server.network ... login account required pam_auths.so.1 auths=com.xyzcompany.access.server.console These entries would require that a user logging in over the network via Secure Shell (see sshd(1m)) has the com.xyzcompany.access.server.network authorizations. If other mechanisms exist to log in on the system over the network the relevant PAM stacks would need to be similarly configured. The second part of this example specifies that a user would need to have been granted the authorization com.xyzcompany.access.server.console in order to be able to log in on the console of the system. In both instances the user would also need the solaris.login authorizations, as described in Example 1, above. Example 7 Specifying a host-specific policy using LOGIN_POLICY_PROFILE and substitution tokens Using the default PAM configuration but specifying LOGIN_POLICY_PROFILE=%F.login would require any user logging in from having a host-specific authorization, of the form com.xyzcompany.hostname.login as well as the solaris.login authorizations. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Committed | |_____________________________|_____________________________| | MT-Level | MT-Safe with exceptions | |_____________________________|_____________________________| The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multithreaded application uses its own PAM handle. SEE ALSO pam(3PAM), pam_authenticate(3PAM), pam_sm_acct_mgmt(3PAM), syslog(3C), libpam(3LIB), nsswitch.conf(4), pam.conf(4), attributes(5), policy.conf(4), auth_attr(4), prof_attr(4), user_attr(4) -- Darren J Moffat From carlsonj@phorcys.east.sun.com Fri Jan 23 07:21:03 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0NFL3QL016490 for ; Fri, 23 Jan 2009 07:21:03 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0NFKkhd029816; Fri, 23 Jan 2009 07:21:00 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KDX00909JYXRV00@brm-avmta-1.central.sun.com>; Fri, 23 Jan 2009 08:20:57 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KDX003I3JYWCW40@brm-avmta-1.central.sun.com>; Fri, 23 Jan 2009 08:20:56 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0NFKuDU004753; Fri, 23 Jan 2009 10:20:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0NFKu2s004750; Fri, 23 Jan 2009 10:20:56 -0500 (EST) Date: Fri, 23 Jan 2009 10:20:56 -0500 From: James Carlson Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] In-reply-to: <4979C1E0.2050404@Sun.COM> To: Darren J Moffat Cc: PSARC-EXT@sun.com, Bart.Blanquart@sun.com Message-id: <18809.57432.237101.440639@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4979C1E0.2050404@Sun.COM> Status: RO Content-Length: 1259 Darren J Moffat writes: > %d is replaced by the DNS domain name. Which one is "the" DNS domain name? I don't think there's a canonical one on the system. You can have multiple search domains in /etc/resolv.conf. If you're referring to /etc/defaultdomain, that's actually the NIS/NIS+ domain, not DNS. > %h is replaced by the hostname, as returned by > gethostname(3C) That's just the local host name. Is the remote host name ever significant? > %f is replaced by the fully qualified host name without the > trailing dot (so using %f is equivalent to specifying > %h.%d) That doesn't make sense to me. The "%h" value is from gethostname(3C), but how do you know that this value isn't itself a FQDN? It's common practice at some sites to set the hostname either to a FQDN or to some domain name that's relative to the organization. The practice of making it a simple one-word name on the SWAN is in many ways due to our use of NIS and its odd limitations. That's not necessarily the norm outside of Sun, though. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gww@sac.sfbay.sun.com Tue Jan 27 16:56:16 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0S0uFFH006540 for ; Tue, 27 Jan 2009 16:56:16 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0S0u0Ct040449 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 27 Jan 2009 17:56:15 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE500D3ZP9PRO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 27 Jan 2009 16:56:13 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE500C2GP9PPY20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 27 Jan 2009 16:56:13 -0800 (PST) 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 n0S0uCmY058342; Tue, 27 Jan 2009 16:56:12 -0800 (PST) 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 n0S0uBUL006537; Tue, 27 Jan 2009 16:56:11 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n0S0uBEO006536; Tue, 27 Jan 2009 16:56:11 -0800 (PST) Date: Tue, 27 Jan 2009 16:56:11 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] To: Darren.Moffat@sun.com, PSARC-EXT@sun.com Cc: Bart.Blanquart@sun.com Message-id: <200901280056.n0S0uBEO006536@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 339 > Timer is set for Friday 30th Jan 2009. Release binding is patch but > with no intention to backport to Solaris 10. I intend to have a comment on this case, if nothing else a +1, but an pressed for time right now, so I'd like to ask for more time probably til 3/4 Feb if I don't get my comments posted before then. Thankx, Gary.. From Darren.Moffat@sun.com Thu Jan 29 06:48:16 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TEmG8l002632 for ; Thu, 29 Jan 2009 06:48:16 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0TEmFAC014028 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 29 Jan 2009 06:48:16 -0800 (PST) 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 <0KE80092ZMGFBQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 29 Jan 2009 06:48:15 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE8008FUMGEYZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 29 Jan 2009 06:48:15 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0TEmD3F007365 for ; Thu, 29 Jan 2009 14:48:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KE800401L8XUE00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 29 Jan 2009 14:48:13 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE800GXRMG2RC40@fe-emea-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 29 Jan 2009 14:48:02 +0000 (GMT) Date: Thu, 29 Jan 2009 14:48:02 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] In-reply-to: <18809.57432.237101.440639@gargle.gargle.HOWL> Sender: Darren.Moffat@sun.com To: James Carlson Cc: PSARC-EXT@sun.com, Bart.Blanquart@sun.com Message-id: <4981C1A2.8020000@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4979C1E0.2050404@Sun.COM> <18809.57432.237101.440639@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 1808 James Carlson wrote: > Darren J Moffat writes: >> %d is replaced by the DNS domain name. > > Which one is "the" DNS domain name? I don't think there's a canonical > one on the system. You can have multiple search domains in > /etc/resolv.conf. > > If you're referring to /etc/defaultdomain, that's actually the > NIS/NIS+ domain, not DNS. I can't believe we made this rookie mistake, especially since I've made exactly the same comments to many people over the years. Doh! Doh! Doh! in my best Homer Simpson voice :-) We will drop %d. >> %h is replaced by the hostname, as returned by >> gethostname(3C) > > That's just the local host name. Is the remote host name ever > significant? We have discussed wither or not the remote hostname (as found in PAM_RHOST if it is available) is significant. At this time we think not but we could easily add it later as an expansion if needed. >> %f is replaced by the fully qualified host name without the >> trailing dot (so using %f is equivalent to specifying >> %h.%d) > > That doesn't make sense to me. The "%h" value is from > gethostname(3C), but how do you know that this value isn't itself a > FQDN? It's common practice at some sites to set the hostname either > to a FQDN or to some domain name that's relative to the organization. We will drop this expansion as well. We have also decided to add one expansion: %H is replaced by the "reverse" of the value returned by gethostname(3C) for example if gethostname returns 'foo.example.com' then %H expands to: 'com.example.foo' in the degenerate case where the value from gethostname(3C) has no dots %H is the same as %h. And update version of the spec is in the case dir. I've also pushed the timer out to 4th Feb 2009 as requested by Gary. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Thu Jan 29 09:56:24 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0THuOwr025438 for ; Thu, 29 Jan 2009 09:56:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0THuJBB016142; Thu, 29 Jan 2009 09:56:21 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE800H21V5WYP00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 29 Jan 2009 09:56:20 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE800A5LV5V7850@nwk-avmta-1.sfbay.Sun.COM>; Thu, 29 Jan 2009 09:56:20 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0THuHrI017487; Thu, 29 Jan 2009 12:56:17 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0THuHmO017484; Thu, 29 Jan 2009 12:56:17 -0500 (EST) Date: Thu, 29 Jan 2009 12:56:17 -0500 From: James Carlson Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] In-reply-to: <4981C1A2.8020000@Sun.COM> To: Darren J Moffat Cc: PSARC-EXT@sun.com, Bart.Blanquart@sun.com Message-id: <18817.60865.652245.251799@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4979C1E0.2050404@Sun.COM> <18809.57432.237101.440639@gargle.gargle.HOWL> <4981C1A2.8020000@Sun.COM> Status: RO Content-Length: 1051 Darren J Moffat writes: > >> %h is replaced by the hostname, as returned by > >> gethostname(3C) > > > > That's just the local host name. Is the remote host name ever > > significant? > > We have discussed wither or not the remote hostname (as found in > PAM_RHOST if it is available) is significant. At this time we think not > but we could easily add it later as an expansion if needed. OK. > We have also decided to add one expansion: > > %H is replaced by the "reverse" of the value returned > by gethostname(3C) for example if gethostname returns > 'foo.example.com' then %H expands to: 'com.example.foo' > in the degenerate case where the value from > gethostname(3C) has no dots %H is the same as %h. > > > And update version of the spec is in the case dir. OK; that all looks good to me. +1 -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gww@sac.sfbay.sun.com Wed Feb 4 12:08:29 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n14K8TAI012615 for ; Wed, 4 Feb 2009 12:08:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n14K8QSw029935 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 4 Feb 2009 12:08:29 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEK0020X5A2AP00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 04 Feb 2009 13:08:26 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEK00HHP5A11090@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 04 Feb 2009 13:08:25 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n14K8O1D038995; Wed, 04 Feb 2009 12:08:24 -0800 (PST) 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 n14K8OO2012013; Wed, 04 Feb 2009 12:08:24 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n14K8OpT012001; Wed, 04 Feb 2009 12:08:24 -0800 (PST) Date: Wed, 04 Feb 2009 12:08:24 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] To: Darren.Moffat@sun.com, PSARC-EXT@sun.com Cc: Bart.Blanquart@sun.com Message-id: <200902042008.n14K8OpT012001@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4770 > Timer is set for Friday 30th Jan 2009. Release binding is patch but > with no intention to backport to Solaris 10. IMO, any backport would require integration with the S10 RBAC interfaces including SMC. For this particular project, that looks to me like a testing effort. But should it be more than testing, I'm reluctant to gage that Patch is without impact. I'd be happier with a Minor release binding. > The solaris.login authorizations are checked for if the relevant > pam_data items are present. Nit these are PAM items, they are NOT PAM data viz. pam_set_item() vs pam_set_data() > +----------------------------+-----------------------------------+ > | Data item | Required authorization | > +----------------------------+-----------------------------------+ > | PAM_RHOST= | solaris.login.remote | > +----------------------------+-----------------------------------+ > | PAM_TTY=/dev/console | solaris.login.console | > +----------------------------+-----------------------------------+ > | PAM_TTY= | solaris.login.local | > +----------------------------+-----------------------------------+ What is the precedence when both PAM_RHOST and PAM_TTY are specified? > The solaris.login authorizations are granted to all accounts via > "Basic Solaris User", so the behaviour of the system remains the same > in default configurations. Since we do not want customers modifying Sun delivered Rights Profiles, IMO it would be better to add a new Rights Profile and add that to PROFS_GRANTED, or to add solaris.login.* to AUTHS_GRANTED. > (While at this point there is nothing fundamentally different between > a "rights profile" as assigned to users and a "policy profile" as > specified as argument here they are conceptually different: the first > assigns all rights and auths it contains, while the latter is used to > check for any of the auths -- hence the difference in terminology.) Has the project team checked with the RBAC project team (specifically Glenn Faden) about this difference? Similarly has the project team checked about substitutable tokens (below)? Has the project team gotten the RBAC team's agreement? Has the project team checked with the Solaris Platform Security team (specifically Craig Payne) on how this helps/conflicts with the projects in planning for user account control and user account management? Has the project team gotten that team's agreement? > The substitutable tokens are: > 4.11. Security Impact: > It's a PAM module that would get added to the default stacks > (snippets). > > 4.12. Dependencies: > As this module would be listed in PAM snippets it relies on PSARC > 2005/275 Per-user PAM configuration. > If PSARC 2005/275 does not integrate this project would update > pam.conf instead. Is this case or isn't it dependent on 2005/275? What exactly are the proposed snippet and/or pam.conf changes? Will they be applied by default in a Patch release binding? > Standards, Environments, and Macros pam_auths(5) > The argument to auths is a comma-separated list of authorization names > chosen from those names defined in the auth_attr(4) database. > Wildcards > may be specified as well as substitution tokens, described below. Any > one authorization listed is sufficient to be granted access. > > The argument to policy_profile is the name of a single policy profile > as defined in prof_attr(4). Any authorization in the profile (or in > an included profile) is sufficient to be granted access. In the profile > name no wildcards may be specified, though substitution tokens can > be used. > Authorization names listed in the profile can contain substitution > tokens > and the wildcard symbol, as though they were specified as an argument > to the auths option. This could/should be clarified to ensure that it is understood that the appropriate solaris.login authorization is needed as well as one of the explicit authorizations. > Example 5 Requiring Multiple Authorizations > > > other account required pam_auths.so.1 > auths=com.xyzcompany.access.server > other account required pam_auths.so.1 > auths=com.xyzcompany.access.dmz,com.xyzcompany.access.sensitive > other account required pam_auths.so.1 auths=com.xyzcompany.access.dns > > These entries would require anyone logging in to have been granted > three > authorizations: com.xyzcompany.access.server, > com.xyzcompany.access.dns and > either com.xyzcompany.access.dmz or com.xyzcompany.access.sensitive. Isn't it really four? One of solaris.login and these three. Gary.. From Bart.Blanquart@sun.com Thu Feb 5 06:16:49 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n15EGmO2003834 for ; Thu, 5 Feb 2009 06:16:48 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n15EGeUa006618 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 5 Feb 2009 07:16:48 -0700 (MST) 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 <0KEL00JDVJNX2E00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 05 Feb 2009 06:16:45 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEL00D1RJN7EL80@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 05 Feb 2009 06:16:20 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n15EGJWG016842 for ; Thu, 05 Feb 2009 14:16:19 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEL00H00IM6B800@fe-emea-10.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 05 Feb 2009 14:16:19 +0000 (GMT) Received: from [129.159.234.4] ([unknown] [129.159.234.4]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEL002C5JMX4Y10@fe-emea-10.sun.com>; Thu, 05 Feb 2009 14:16:10 +0000 (GMT) Date: Thu, 05 Feb 2009 15:16:09 +0100 From: Bart Blanquart Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] In-reply-to: <200902042008.n14K8OpT012001@sac.sfbay.sun.com> Sender: Bart.Blanquart@sun.com To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-EXT@sun.com Reply-to: Bart.Blanquart@sun.com Message-id: <498AF4A9.70905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902042008.n14K8OpT012001@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 6806 On 02/04/09 21:08, Gary Winiger wrote: >> Timer is set for Friday 30th Jan 2009. Release binding is patch but with no intention to backport to Solaris 10. > > IMO, any backport would require integration with the S10 RBAC > interfaces including SMC. For this particular project, that > looks to me like a testing effort. But should it be more than > testing, I'm reluctant to gage that Patch is without impact. > I'd be happier with a Minor release binding. Though we don't have the intention to backport to S10 there are business reasons that may make such a backport desirable, so I would like to retain patch binding. I don't see any impact whasoever to SMC from this change: SMC already handles the nearly 130 authorizations, the 25+ rights profiles with authorizations, and the "Basic Solaris User" rights profile with about 20 authorizations. Adding a couple authorizations or modifying a rights profile won't make a difference... which a quick test just now confirms. >> The solaris.login authorizations are checked for if the relevant >> pam_data items are present. > > Nit these are PAM items, they are NOT PAM data viz. > pam_set_item() vs pam_set_data() Noted. The documentation will be updated to reflect this. >> +----------------------------+-----------------------------------+ >> | Data item | Required authorization | >> +----------------------------+-----------------------------------+ >> | PAM_RHOST= | solaris.login.remote | >> +----------------------------+-----------------------------------+ >> | PAM_TTY=/dev/console | solaris.login.console | >> +----------------------------+-----------------------------------+ >> | PAM_TTY= | solaris.login.local | >> +----------------------------+-----------------------------------+ > > What is the precedence when both PAM_RHOST and PAM_TTY are > specified? If PAM_RHOST is present its authorization will be checked for and the PAM_TTY authorization will not be checked. The documentation will be updated to reflect this. >> The solaris.login authorizations are granted to all accounts via >> "Basic Solaris User", so the behaviour of the system remains the same >> in default configurations. > > Since we do not want customers modifying Sun delivered Rights > Profiles, IMO it would be better to add a new Rights Profile > and add that to PROFS_GRANTED, or to add solaris.login.* to > AUTHS_GRANTED. > Customers that want to deviate from the default profile can define their own "Site Solaris User" and assign that in PROFS_GRANTED. I don't see the value in adding another default profile as "Basic Solaris User" is just that. >> (While at this point there is nothing fundamentally different between >> a "rights profile" as assigned to users and a "policy profile" as >> specified as argument here they are conceptually different: the first >> assigns all rights and auths it contains, while the latter is used to >> check for any of the auths -- hence the difference in terminology.) > > Has the project team checked with the RBAC project team > (specifically Glenn Faden) about this difference? Similarly > has the project team checked about substitutable tokens (below)? > Has the project team gotten the RBAC team's agreement? > Has the project team checked with the Solaris Platform Security > team (specifically Craig Payne) on how this helps/conflicts with > the projects in planning for user account control and user account > management? Has the project team gotten that team's agreement? > I would expect Glenn's participation in the open security-discuss review of the initial proposal to count as a reply to the first question, and both that open discussion and this case as the check for conflicts with any other projects. >> The substitutable tokens are: > >> 4.11. Security Impact: >> It's a PAM module that would get added to the default stacks >> (snippets). >> >> 4.12. Dependencies: >> As this module would be listed in PAM snippets it relies on PSARC >> 2005/275 Per-user PAM configuration. >> If PSARC 2005/275 does not integrate this project would update >> pam.conf instead. > > Is this case or isn't it dependent on 2005/275? What exactly are > the proposed snippet and/or pam.conf changes? Will they be > applied by default in a Patch release binding? > It is not a dependency as such: we basically intend to play nice with whatever the appropriate PAM configuration mechanism is: if 2005/275 is integrated that means we add the module to the appropriate snippet, otherwise we edit pam.conf. The PAM configuration change is the addition of this module to the "other" account stack. >> Standards, Environments, and Macros pam_auths(5) > >> The argument to auths is a comma-separated list of authorization >> names chosen from those names defined in the auth_attr(4) >> database. Wildcards may be specified as well as substitution >> tokens, described below. Any one authorization listed is >> sufficient to be granted access. >> >> The argument to policy_profile is the name of a single policy >> profile as defined in prof_attr(4). Any authorization in the >> profile (or in an included profile) is sufficient to be granted >> access. In the profile name no wildcards may be specified, >> though substitution tokens can be used. >> Authorization names listed in the profile can contain >> substitution tokens and the wildcard symbol, as though they were >> specified as an argument to the auths option. > > This could/should be clarified to ensure that it is understood > that the appropriate solaris.login authorization is needed as well > as one of the explicit authorizations. Ok. The documentation will be updated to reflect this. >> Example 5 Requiring Multiple Authorizations >> >> >> other account required pam_auths.so.1 >> auths=com.xyzcompany.access.server >> other account required pam_auths.so.1 >> auths=com.xyzcompany.access.dmz,com.xyzcompany.access.sensitive >> other account required pam_auths.so.1 >> auths=com.xyzcompany.access.dns >> >> These entries would require anyone logging in to have been >> granted three authorizations: com.xyzcompany.access.server, >> com.xyzcompany.access.dns and >> either com.xyzcompany.access.dmz or >> com.xyzcompany.access.sensitive. > > Isn't it really four? One of solaris.login and these three. It is. Good catch. The docs will be updated. Bart From Darren.Moffat@Sun.COM Fri Feb 6 07:29:29 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n16FTTc7025078 for ; Fri, 6 Feb 2009 07:29:29 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n16FTToc001161 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Fri, 6 Feb 2009 07:29:29 -0800 (PST) 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 <0KEN00J05HP33300@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 06 Feb 2009 07:29:27 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEN002HHHP2EJE0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 06 Feb 2009 07:29:26 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n16FTPoN015731 for ; Fri, 06 Feb 2009 15:29:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEN00100H94UO00@fe-emea-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 06 Feb 2009 15:29:25 +0000 (GMT) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEN007JNHOTXE10@fe-emea-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 06 Feb 2009 15:29:17 +0000 (GMT) Date: Fri, 06 Feb 2009 15:29:17 +0000 From: Darren J Moffat Subject: PSARC/2009/036 Authorisation based login control: pam_auths Sender: Darren.Moffat@Sun.COM To: PSARC-EXT@Sun.COM, Bart Blanquart Message-id: <498C574D.7000602@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 268 I've updated the spec to reflect the latest revisions and extended the timer until 11th Feb 2009. I don't believe there are any technical issues left to be resolved though. spec-v3.txt in the case dir is the latest (spec.txt is a link to it). -- Darren J Moffat From gww@sac.sfbay.sun.com Mon Feb 9 14:13:50 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n19MDnc7001908 for ; Mon, 9 Feb 2009 14:13:49 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n19MDmWL063773 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 9 Feb 2009 15:13:49 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KET0050JKF0T000@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 09 Feb 2009 15:13:48 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KET004EUKEZ5610@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 09 Feb 2009 15:13:47 -0700 (MST) 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 n19MDkK0018401; Mon, 09 Feb 2009 14:13:46 -0800 (PST) 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 n19MDj3M001906; Mon, 09 Feb 2009 14:13:45 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n19MDj7s001905; Mon, 09 Feb 2009 14:13:45 -0800 (PST) Date: Mon, 09 Feb 2009 14:13:45 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] To: Bart.Blanquart@sun.com, gww@sac.sfbay.sun.com Cc: Darren.Moffat@sun.com, PSARC-EXT@sun.com Message-id: <200902092213.n19MDj7s001905@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1777 > >> (While at this point there is nothing fundamentally different between > >> a "rights profile" as assigned to users and a "policy profile" as > >> specified as argument here they are conceptually different: the first > >> assigns all rights and auths it contains, while the latter is used to > >> check for any of the auths -- hence the difference in terminology.) > > > > Has the project team checked with the RBAC project team > > (specifically Glenn Faden) about this difference? Similarly > > has the project team checked about substitutable tokens (below)? > > Has the project team gotten the RBAC team's agreement? > > Has the project team checked with the Solaris Platform Security > > team (specifically Craig Payne) on how this helps/conflicts with > > the projects in planning for user account control and user account > > management? Has the project team gotten that team's agreement? > > > > I would expect Glenn's participation in the open security-discuss review > of the initial proposal to count as a reply to the first question, and > both that open discussion and this case as the check for conflicts with > any other projects. One of the goals of review is to point out other projects operating in the same area. 20 Questions 1 asks: "* How does this project align with existing or proposed ARC cases?" Glenn and Craig seem to be a good place to go for initial alignment discussions. In particular the Solaris Platform Security team is in the planning stages for a project dealing with user authentication access control that, among other things, will deal with locality. This project seems to me to have overlap there. The point is to contact that team and clarify interaction. Gary.. From gww@sac.sfbay.sun.com Mon Feb 9 15:01:58 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n19N1wuo004532 for ; Mon, 9 Feb 2009 15:01:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n19N1v9q026861 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Mon, 9 Feb 2009 16:01:58 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KET00A0FMN6NF00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 09 Feb 2009 16:01:54 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KET004SEMN64W30@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 09 Feb 2009 16:01:54 -0700 (MST) 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 n19N1qEk050951; Mon, 09 Feb 2009 15:01:52 -0800 (PST) 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 n19N1quG004530; Mon, 09 Feb 2009 15:01:52 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n19N1qWS004529; Mon, 09 Feb 2009 15:01:52 -0800 (PST) Date: Mon, 09 Feb 2009 15:01:52 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] To: Bart.Blanquart@sun.com, gww@sac.sfbay.sun.com Cc: Darren.Moffat@sun.com, PSARC-EXT@sun.com Message-id: <200902092301.n19N1qWS004529@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1620 > >> The solaris.login authorizations are granted to all accounts via > >> "Basic Solaris User", so the behaviour of the system remains the same > >> in default configurations. > > > > Since we do not want customers modifying Sun delivered Rights > > Profiles, IMO it would be better to add a new Rights Profile > > and add that to PROFS_GRANTED, or to add solaris.login.* to > > AUTHS_GRANTED. > > > > Customers that want to deviate from the default profile can define their > own "Site Solaris User" and assign that in PROFS_GRANTED. I don't see > the value in adding another default profile as "Basic Solaris User" is > just that. I realize that. And they may not want to do so. It seems to me that it would be just as easy for this project to add the solaris.login.* to policy.conf AUTHS_GRANTED= than to Basic Solaris User and then the admin could just change policy.conf rather than have to create a new profile and update pam.conf if they wanted no remote login for example -- this the same strategy as for disabling use of cdrw. > >> Standards, Environments, and Macros pam_auths(5) Looking at the man page again, I missed a few things the first time. As the man page is also for a programming interface for callers of pam as well as an administrative interface for the parameters to the module, the pam items need to be discussed. Additionally, I presume PAM_USER is the user whose authorizations are checked. I didn't see that explicitly mentioned. Specifically I presume ruid, PAM_RUSER and PAM_AUSER have not part in the policy. Gary.. From Darren.Moffat@sun.com Tue Feb 10 01:57:28 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1A9vSBo000152 for ; Tue, 10 Feb 2009 01:57:28 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1A9vDh2017906 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 10 Feb 2009 09:57:26 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEU00G07GZNF400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 10 Feb 2009 01:57:23 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEU004NUGZLM0B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 10 Feb 2009 01:57:22 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1A9vLA3016312 for ; Tue, 10 Feb 2009 09:57:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEU00M00G21JT00@fe-emea-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 10 Feb 2009 09:57:21 +0000 (GMT) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEU0036CGZ1ZGA0@fe-emea-09.sun.com>; Tue, 10 Feb 2009 09:57:02 +0000 (GMT) Date: Tue, 10 Feb 2009 09:57:01 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] In-reply-to: <200902092301.n19N1qWS004529@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: Bart.Blanquart@sun.com, PSARC-EXT@sun.com, Glenn Faden Message-id: <49914F6D.8050705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200902092301.n19N1qWS004529@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 2375 Gary Winiger wrote: >> >> The solaris.login authorizations are granted to all accounts via >> >> "Basic Solaris User", so the behaviour of the system remains the same >> >> in default configurations. >> > >> > Since we do not want customers modifying Sun delivered Rights >> > Profiles, IMO it would be better to add a new Rights Profile >> > and add that to PROFS_GRANTED, or to add solaris.login.* to >> > AUTHS_GRANTED. >> > >> >> Customers that want to deviate from the default profile can define their >> own "Site Solaris User" and assign that in PROFS_GRANTED. I don't see >> the value in adding another default profile as "Basic Solaris User" is >> just that. > > I realize that. And they may not want to do so. It seems to me > that it would be just as easy for this project to add the > solaris.login.* to policy.conf AUTHS_GRANTED= than to Basic Solaris > User and then the admin could just change policy.conf rather than > have to create a new profile and update pam.conf if they wanted > no remote login for example -- this the same strategy as for > disabling use of cdrw. Interesting, I though we wanted to move away from further use of the AUTHS_GRANTED=, PROFS_GRANTED= in policy.conf for stuff that users tend to have by default since they are host specific rather than "Basic Solaris User" which can come from the name service. I don't have too strong a preference one way or the other bug I would like to know what someone other than you or I thinks about this. Glenn Faden maybe ? >> >> Standards, Environments, and Macros pam_auths(5) > > Looking at the man page again, I missed a few things the first > time. As the man page is also for a programming interface for > callers of pam as well as an administrative interface for the > parameters to the module, the pam items need to be discussed. > > Additionally, I presume PAM_USER is the user whose authorizations > are checked. I didn't see that explicitly mentioned. Specifically > I presume ruid, PAM_RUSER and PAM_AUSER have not part in the policy. Correct we only use PAM_USER not PAM_RUSER or PAM_AUSER and definitely definitely not ruid or euid. We can make that clear in the final spec even though I thought it was implicitly clear since we hadn't mentioned PAM_RUSER or PAM_AUSER by name. -- Darren J Moffat From gww@sac.sfbay.sun.com Wed Feb 11 12:55:10 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1BKt9Hu013674 for ; Wed, 11 Feb 2009 12:55:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1BKsmCI020810 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 11 Feb 2009 20:55:08 GMT 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 <0KEX00M1763V8S00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 11 Feb 2009 12:55:07 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEX00H9A63UIX90@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 11 Feb 2009 12:55:06 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1BKt5Xs013035; Wed, 11 Feb 2009 12:55:05 -0800 (PST) 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 n1BKt4Ht013663; Wed, 11 Feb 2009 12:55:05 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n1BKt4nc013662; Wed, 11 Feb 2009 12:55:04 -0800 (PST) Date: Wed, 11 Feb 2009 12:55:04 -0800 (PST) From: Gary Winiger Subject: Re: PSARC/2009/036 Authorisation based login control: pam_auths [ timeout 01/30/2009 ] To: Darren.Moffat@sun.com, gww@sac.sfbay.sun.com Cc: bart.blanquart@sun.com, Glenn.Faden@sun.com, PSARC-EXT@sun.com Message-id: <200902112055.n1BKt4nc013662@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 892 > > User and then the admin could just change policy.conf rather than > > have to create a new profile and update pam.conf if they wanted > > no remote login for example -- this the same strategy as for > > disabling use of cdrw. > > > Interesting, I though we wanted to move away from further use of the > AUTHS_GRANTED=, PROFS_GRANTED= in policy.conf for stuff that users tend > to have by default since they are host specific rather than "Basic > Solaris User" which can come from the name service. > > I don't have too strong a preference one way or the other bug I would > like to know what someone other than you or I thinks about this. Glenn > Faden maybe ? There is this issue an the project coordination issue that are being worked off line. At PSARC today, the timer was extended until the next scheduled meeting, 25 Feb. to get the coordination aligned. Gary..