From sacadmin Sun Sep 10 22:52:06 2006 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8B5q6tj019294; Sun, 10 Sep 2006 22:52:06 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id k8B5q6CG019290; Sun, 10 Sep 2006 22:52:06 -0700 (PDT) Date: Sun, 10 Sep 2006 22:52:06 -0700 (PDT) From: Gary Winiger Message-Id: <200609110552.k8B5q6CG019290@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: casper.dik@sun.com, glenn.faden@sun.com, jan.pechanec@sun.com Subject: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Status: RO Content-Length: 1841 Subject: PSARC FastTrack [09/20/2006]: remote user audit attribution update Template Version: @(#)sac_nextcase %I% %G% SMI This information Copyright 2006 Sun Microsystems 1. Introduction I'm self sponsoring this fast track. It intends to supersede PSARC/2005/009 remote user audit attribution. It requests a patch release binding and retention of the existing Evolving and Stable historic interface taxonomy for both pam_unix_cred(5) and pam_set_item(3pam). (When stability attributes are updated, both should become Committed.) During off-line review, it was pointed out that the proposed solution of this case, adding a PAM_AUSER item, could be used to cleanup various issues with SMC(1M)'s contrived combination of PAM_RHOST and PAM_RUSER in pam_rhosts(5). Some of this is discussed in the comments of 4628245 "user_attr configuration issues" and in the source: /* * PAM_RUSER is set but PAM_RHOST is not; this is * used by SMC and is a temporary solution until a proper * interface is designed that specifies a "come-from" * username. */ A separate case, dependent on this case, is planned to deal with pam_rhosts(5) use of PAM_AUSER. Full diffmarked man pages are in the case directory. The timer is set for 20 Sept, 2006. Gary.. 1.1. Project/Component Working Name: remote user audit attribution update 1.2. Name of Document Author/Supplier: Author: Gary Winiger 1.3 Date of This Document: 10 September, 2006 4. Technical Description ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Background: In order to correctly attribute auditable actions to remote user, PSARC/2005/009 remote user audit attribution was proposed. Parts of PSARC/2005/009 have been implemented in S11. Even though PSARC/2005/009 has a patch release binding, it has not been exposed in any S10 releases. >From PSARC/2005/009: Commands such as ssh -l , rlogin -l , rlogin -A -l do not correctly attribute audit to the initiating user. In the past this has more or less been ignored. However, with the greater potential use of roles, and a trustworthy way of sending the initiating user's identity, it should now be corrected. Various RFEs and Bugs: 6203206 "sshd should set PAM_RUSER for hostbased userauth for audited logins to roles" 6213280 "Remote role assumption should be provided via ssh" 6213282 "pam_unix_cred should be able to attribute to remote user." have been filed. Trusted Solaris systems have transmitted the initiating user's attributes through IP options. Problem: 6378304 PSARC/2005/009 is a security hole and must be ripped out asserts that the implementation of remote audit attribution is flawed because it uses PAM_RUSER and the rlogin/rsh protocol is is easily spoofable. While it was noted or, at least implied, in PSARC/2005/009 that rlogin/rsh support would fall out of this, it is perceived as an acceptable risk to sites which permit rlogin/rsh. It has since been strongly pointed out that it would be better to add a more complex solution than ship Solaris with an exploitable flaw. Proposal: Revised background: | Commands such as ssh -l , krlogin -l , rlogin -A -l do not correctly attribute audit to the initiating user. In the past this has more or less been ignored. However, with the greater potential use of roles, and a trustworthy way of sending the initiating user's identity, it should now be corrected. Various RFEs and Bugs: | 6203206 "sshd should set PAM_AUSER for hostbased userauth for audited logins to roles" 6213280 "Remote role assumption should be provided via ssh" 6213282 "pam_unix_cred should be able to attribute to remote user." | have been filed. Trusted Extensions systems have transmitted the initiating user's attributes through IP options. 1) Change the current pam_unix_cred(5) implementation to no longer use PAM_RUSER for setting audit attribution. 2) Add a new PAM item to specify a trustworthily authenticated user, PAM_AUSER for audit attribution or other purposes, such as to define who is trying to assume a role. Details: pam_unix_cred(5): DESCRIPTION pam_sm_setcred() initializes the user's project, privilege sets and initializes or updates the user's audit context if it hasn't already been initialized. The following flags may be set in the flags field: PAM_ESTABLISH_CRED PAM_REFRESH_CRED PAM_REINITIALIZE_CRED Initializes the user's project to the project speci- fied in PAM_RESOURCE, or if PAM_RESOURCE is not speci- fied, to the user's default project. Establishes the user's privilege sets. If the audit context is not already initialized and auditing is configured, these flags cause the context to be initialized to that of the user specified in | PAM_AUSER (if any) merged with the user specified in PAM_USER and host specified in PAM_RHOST. If PAM_RHOST is not specified, PAM_TTY specifies the local terminal | name. Attributing audit to PAM_AUSER and merging PAM_USER is required for correctly attributing audit- ing when the entry is done from another user as in the case of "ssh -l login_name" (see ssh(1)). If the audit context is already initialized, the PAM_REINITIALIZE_CRED flag merges the current audit context with that of the user specified in PAM_USER. PAM_REINITIALIZE_CRED is useful when a user is assum- ing a new identity, as with su(1M). PAM_DELETE_CRED This flag has no effect and always returns PAM_SUCCESS. pam_set_item(3pam): DESCRIPTION The pam_get_item() and pam_set_item() functions allow appli- cations and PAM service modules to access and to update PAM information as needed. The information is specified by item_type, and can be one of the following: + PAM_AUSER + The authenticated user name. Applications + which support remotely authenticated users who differ + from the current user, such as ssh -l user, should + set this to the remotely authenticated user. See + pam_unix_cred(5). PAM_RHOST The remote host name. PAM_RUSER | The rlogin/rsh untrusted remote user name. PAM_USER The user name. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Mon Sep 11 05:02:39 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BC2cgh025569; Mon, 11 Sep 2006 05:02:38 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k8BC4kPr018935; Mon, 11 Sep 2006 08:04:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k8BC4krC018932; Mon, 11 Sep 2006 08:04:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17669.20702.476308.78968@gargle.gargle.HOWL> Date: Mon, 11 Sep 2006 08:04:46 -0400 From: James Carlson To: Gary Winiger Cc: PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] In-Reply-To: Gary Winiger's message of 10 September 2006 22:52:06 References: <200609110552.k8B5q6CG019290@sac.sfbay.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1309 Gary Winiger writes: > + PAM_AUSER > + The authenticated user name. Applications > + which support remotely authenticated users who differ > + from the current user, such as ssh -l user, should > + set this to the remotely authenticated user. See > + pam_unix_cred(5). I'm confused by this on two counts: - Why would we trust a remote instance of ssh to report a "remotely authenticated user" any more than we'd trust rsh? The implication is that the local system somehow knows that the remote system's ssh doesn't lie about UIDs, but how do we know that's true? - How are realms handled? There's no reason I can see to suppose that PAM_AUSER corresponds to anything meaningful on the local system (and in fact may conflict with local definitions, as the remote system may have a different administrator). This implies being able to handle realms in which user names are known to be interpretable. How is that done? Is a standard encoding used here, or does the application 'guess' based on the remote host name? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Sep 11 05:11:14 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BCBEjh025594; Mon, 11 Sep 2006 05:11:14 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8BCBDV1000117; Mon, 11 Sep 2006 05:11:14 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8BCB8IL011154; Mon, 11 Sep 2006 13:11:08 +0100 (BST) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5F00G01GCPVM00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Mon, 11 Sep 2006 13:11:08 +0100 (BST) Received: from [129.150.120.189] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5F007F9GIIBH20@d1-emea-10.sun.com>; Mon, 11 Sep 2006 13:11:07 +0100 (BST) Date: Mon, 11 Sep 2006 13:11:03 +0100 From: Darren J Moffat Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] In-reply-to: <17669.20702.476308.78968@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: Gary Winiger , PSARC@sac.sfbay.sun.com, Casper.Dik@Sun.COM, glenn.faden@Sun.COM, Jan.Pechanec@Sun.COM, Nicolas.Williams@Sun.COM Message-id: <45055257.90204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200609110552.k8B5q6CG019290@sac.sfbay.sun.com> <17669.20702.476308.78968@gargle.gargle.HOWL> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 2264 James Carlson wrote: > Gary Winiger writes: >> + PAM_AUSER >> + The authenticated user name. Applications >> + which support remotely authenticated users who differ >> + from the current user, such as ssh -l user, should >> + set this to the remotely authenticated user. See >> + pam_unix_cred(5). > > I'm confused by this on two counts: > > - Why would we trust a remote instance of ssh to report a "remotely > authenticated user" any more than we'd trust rsh? The implication > is that the local system somehow knows that the remote system's > ssh doesn't lie about UIDs, but how do we know that's true? That is the definition of ssh hostbased authentication. This does NOT work with all ssh userauth methods only those that have a strong trust relationship between the client and server. At this time that is only hostbased. The man pages for pam_unix_cred MUST make this very clear, ie it must spell out exactly which SSH userauth methods this works for and why. In particular this does NOT work for keyboard interactive (ie run the PAM pam_authenticate stack) nor does it work for pubkey. At this time it doesn't work for gssapi either. > - How are realms handled? There's no reason I can see to suppose > that PAM_AUSER corresponds to anything meaningful on the local > system (and in fact may conflict with local definitions, as the > remote system may have a different administrator). This implies > being able to handle realms in which user names are known to be > interpretable. How is that done? Is a standard encoding used > here, or does the application 'guess' based on the remote host > name? Again this is implicit in the definition of ssh hostbased auth, that the realm/domain is identical on all systems that participate in ssh hostbased authentication. Note also that hostbased authentication is NOT enabled by default on Solaris (or any other system I'm aware of) and requires explicit setup (which is documented in sshd(1M)). It maybe possible to do sensible PAM_AUSER setup for GSSAPI based applications as well but at this time we don't. I can't remember all the details of why on this but Nicolas Williams should be able to. -- Darren J Moffat From sacadmin Mon Sep 11 05:12:36 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BCCaj8025659; Mon, 11 Sep 2006 05:12:36 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8BCCZMs000452; Mon, 11 Sep 2006 05:12:36 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8BCCUI7011316; Mon, 11 Sep 2006 13:12:30 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5F00D01GIK4H00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Mon, 11 Sep 2006 13:12:30 +0100 (BST) Received: from [129.150.120.189] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5F0072LGKT8I30@d1-emea-09.sun.com>; Mon, 11 Sep 2006 13:12:30 +0100 (BST) Date: Mon, 11 Sep 2006 13:12:26 +0100 From: Darren J Moffat Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] In-reply-to: <200609110552.k8B5q6CG019290@sac.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: PSARC@sac.sfbay.sun.com, Casper.Dik@Sun.COM, glenn.faden@Sun.COM, Jan.Pechanec@Sun.COM Message-id: <450552AA.7020105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200609110552.k8B5q6CG019290@sac.sfbay.sun.com> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 414 The man pages are VERY misleading. It leads the admin to believe that this works for ssh(1) in the general case. It does not and MUST not. In particular this works only for SSH protocol userauth methods that allow secure discovery of the user on the client side. For Solaris this is only hostbased at this time and maybe GSS-API with some mechs. The man pages must make this very clear. -- Darren J Moffat From sacadmin Mon Sep 11 09:50:01 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BGo13T001054; Mon, 11 Sep 2006 09:50:01 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8BGnws6024812; Mon, 11 Sep 2006 09:49:58 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k8BGpnf0027693; Mon, 11 Sep 2006 09:51:49 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k8BGpnCH027692; Mon, 11 Sep 2006 09:51:49 -0700 (PDT) Date: Mon, 11 Sep 2006 09:51:49 -0700 (PDT) From: Gary Winiger Message-Id: <200609111651.k8BGpnCH027692@marduk.eng.sun.com> To: gww@sac.sfbay.sun.com, james.d.carlson@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Cc: PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 2058 > Gary Winiger writes: > > + PAM_AUSER > > + The authenticated user name. Applications > > + which support remotely authenticated users who differ > > + from the current user, such as ssh -l user, should > > + set this to the remotely authenticated user. See > > + pam_unix_cred(5). > > I'm confused by this on two counts: Sorry.... > - Why would we trust a remote instance of ssh to report a "remotely > authenticated user" any more than we'd trust rsh? The implication > is that the local system somehow knows that the remote system's > ssh doesn't lie about UIDs, but how do we know that's true? > > - How are realms handled? There's no reason I can see to suppose > that PAM_AUSER corresponds to anything meaningful on the local > system (and in fact may conflict with local definitions, as the > remote system may have a different administrator). This implies > being able to handle realms in which user names are known to be > interpretable. How is that done? Is a standard encoding used > here, or does the application 'guess' based on the remote host > name? I think the answer to both goes to the requirement that PAM applications ``must do the right thing''. PAM applications run with privilege (or they fail to work). All applications which run with privilege are part of the TCB and must operate correctly. As Darren mentioned, ssh hostbased authentication is one example of an application that correctly knows the authenticated user. Another may be krlogin. su(1M) and SMC(1M) are others, but it doesn't call pam_unix_cred to establish an audit context the same way as an extended login from one machine to another does. As I hinted SMC calls pam_roles, so a follow on may address how pam_roles could use PAM_AUSER. I didn't bring that as part of this case because what should have been a contracted consolidation private interface was documented in the pam_roles man page and therefore presents possible backward compatibility issues. HTH, Gary.. From sacadmin Mon Sep 11 09:58:27 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BGwRld001650; Mon, 11 Sep 2006 09:58:27 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8BGwNRV026698; Mon, 11 Sep 2006 09:58:23 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k8BH0E7D027714; Mon, 11 Sep 2006 10:00:14 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k8BH0EuE027713; Mon, 11 Sep 2006 10:00:14 -0700 (PDT) Date: Mon, 11 Sep 2006 10:00:14 -0700 (PDT) From: Gary Winiger Message-Id: <200609111700.k8BH0EuE027713@marduk.eng.sun.com> To: gww@sac.sfbay.sun.com, Darren.Moffat@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Cc: PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1193 > The man pages are VERY misleading. How so? pam_unix_cred says what it does with PAM_AUSER. pam_set_item defines the PAM_AUSER item. In that definition, it gives an example. Perhaps: + PAM_AUSER + The authenticated user name. Applications + which support remotely authenticated users who differ + from the current user, such as ssh -l user, should ^ and reliably know that user, such as some forms of ssh -l user, should + set this to the remotely authenticated user. See + pam_unix_cred(5). > It leads the admin to believe that this works for ssh(1) in the general > case. It does not and MUST not. In particular this works only for > SSH protocol userauth methods that allow secure discovery of the user on > the client side. For Solaris this is only hostbased at this time and > maybe GSS-API with some mechs. > > The man pages must make this very clear. Are you saying that the ssh man page should be included in this case? I'd think the ssh project team would update the ssh man page when 6203206 "sshd should set PAM_XUSER for hostbased userauth for audited logins to roles" is resolved. Gary.. From sacadmin Mon Sep 11 10:11:48 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BHBmax002593; Mon, 11 Sep 2006 10:11:48 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8BHBl7e023693; Mon, 11 Sep 2006 10:11:48 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8BHBfEL018111; Mon, 11 Sep 2006 18:11:42 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5F00E01UDFTP00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Mon, 11 Sep 2006 18:11:41 +0100 (BST) Received: from [129.150.120.189] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5F007TZUFG8I50@d1-emea-09.sun.com>; Mon, 11 Sep 2006 18:11:41 +0100 (BST) Date: Mon, 11 Sep 2006 18:11:37 +0100 From: Darren J Moffat Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] In-reply-to: <200609111700.k8BH0EuE027713@marduk.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, Casper.Dik@Sun.COM, glenn.faden@Sun.COM, Jan.Pechanec@Sun.COM Message-id: <450598C9.8090702@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200609111700.k8BH0EuE027713@marduk.eng.sun.com> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 1540 Gary Winiger wrote: >> The man pages are VERY misleading. > > How so? pam_unix_cred says what it does with PAM_AUSER. > pam_set_item defines the PAM_AUSER item. In that definition, > it gives an example. Perhaps: They mention ssh -l without mention that it needs to be hostbased auth at this time. > + PAM_AUSER > + The authenticated user name. Applications > + which support remotely authenticated users who differ > + from the current user, such as ssh -l user, should > ^ > and reliably know that user, > such as some forms of ssh -l user, should > + set this to the remotely authenticated user. See > + pam_unix_cred(5). > >> It leads the admin to believe that this works for ssh(1) in the general >> case. It does not and MUST not. In particular this works only for >> SSH protocol userauth methods that allow secure discovery of the user on >> the client side. For Solaris this is only hostbased at this time and >> maybe GSS-API with some mechs. >> >> The man pages must make this very clear. > > Are you saying that the ssh man page should be included in this > case? I'd think the ssh project team would update the ssh man > page when 6203206 "sshd should set PAM_XUSER for hostbased userauth > for audited logins to roles" is resolved. That would be nice, what I believe is most important though is that the pam_unix_cred man page doesn't imply that all userauth methods work (since they don't and can't). -- Darren J Moffat From sacadmin Mon Sep 11 10:39:03 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BHd351003820; Mon, 11 Sep 2006 10:39:03 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8BHcxbp005180; Mon, 11 Sep 2006 10:38:59 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k8BHeoME027768; Mon, 11 Sep 2006 10:40:50 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k8BHeo3a027767; Mon, 11 Sep 2006 10:40:50 -0700 (PDT) Date: Mon, 11 Sep 2006 10:40:50 -0700 (PDT) From: Gary Winiger Message-Id: <200609111740.k8BHeo3a027767@marduk.eng.sun.com> To: gww@eng.sun.com, Darren.Moffat@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Cc: gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 891 > > That would be nice, what I believe is most important though is that the > pam_unix_cred man page doesn't imply that all userauth methods work > (since they don't and can't). Ah, I missed seeing that the 2005/009 man page changes that I didn't see when I diff mark. Thanks...... | name. Attributing audit to PAM_AUSER and merging PAM_USER is required for correctly attributing audit- ing when the entry is done from another user as in the case of "ssh -l login_name" (see ssh(1)). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It is may be misleading. These words were as approved in 2005/009 and probably should have been different then. Perhaps: ``such as in the case of some forms of "ssh -l login_name" (see ssh(1)).'' I'll update the spec when/presuming we converge with this change and the pam_set_item(). Gary.. From sacadmin Mon Sep 11 10:46:15 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BHkFE6003950; Mon, 11 Sep 2006 10:46:15 -0700 (PDT) Received: from gmpea-pix-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k8BHkE8e014814; Mon, 11 Sep 2006 10:46:15 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119] (may be forged)) by gmpea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8BHk9DU003781; Mon, 11 Sep 2006 18:46:09 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5F00K01VYLBH00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Mon, 11 Sep 2006 18:46:09 +0100 (BST) Received: from [129.150.120.189] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5F007Y8W0W8I50@d1-emea-09.sun.com>; Mon, 11 Sep 2006 18:46:09 +0100 (BST) Date: Mon, 11 Sep 2006 18:46:05 +0100 From: Darren J Moffat Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] In-reply-to: <200609111740.k8BHeo3a027767@marduk.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, Casper.Dik@Sun.COM, glenn.faden@Sun.COM, Jan.Pechanec@Sun.COM Message-id: <4505A0DD.1030800@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200609111740.k8BHeo3a027767@marduk.eng.sun.com> User-Agent: Mail/News 1.5.0.4 (X11/20060731) Status: RO Content-Length: 1135 Gary Winiger wrote: >> That would be nice, what I believe is most important though is that the >> pam_unix_cred man page doesn't imply that all userauth methods work >> (since they don't and can't). > > Ah, I missed seeing that the 2005/009 man page changes that I > didn't see when I diff mark. Thanks...... > > | name. Attributing audit to PAM_AUSER and merging > PAM_USER is required for correctly attributing audit- > ing when the entry is done from another user as in the > case of "ssh -l login_name" (see ssh(1)). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > It is may be misleading. These words were as approved in > 2005/009 and probably should have been different then. > > Perhaps: > > ``such as in the case of some forms of "ssh -l login_name" > (see ssh(1)).'' > > I'll update the spec when/presuming we converge with this > change and the pam_set_item(). I have no problem with the actual proposal, I just want to make sure that the man page doesn't miss lead people into thinking this works with all ssh userauth methods. -- Darren J Moffat From sacadmin Mon Sep 11 10:50:06 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BHo69b004002; Mon, 11 Sep 2006 10:50:06 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k8BHqEYE020470; Mon, 11 Sep 2006 13:52:14 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k8BHqEK0020467; Mon, 11 Sep 2006 13:52:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17669.41549.791742.488474@gargle.gargle.HOWL> Date: Mon, 11 Sep 2006 13:52:13 -0400 From: James Carlson To: Gary Winiger Cc: Darren.Moffat@sun.com, gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] In-Reply-To: Gary Winiger's message of 11 September 2006 10:40:50 References: <200609111740.k8BHeo3a027767@marduk.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 497 Gary Winiger writes: > ``such as in the case of some forms of "ssh -l login_name" > (see ssh(1)).'' Maybe. I'd still like to see a clearer reference here, because without the information that this is a "hostauth special," this is likely to lead to more customer calls. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Sep 11 12:43:35 2006 Received: from phys-bohemia2-1 (phys-bohemia2-1.Czech.Sun.COM [129.157.72.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BJhYY7009283; Mon, 11 Sep 2006 12:43:35 -0700 (PDT) Received: from conversion-daemon.bohemia2-mail1.czech.sun.com by bohemia2-mail1.czech.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0J5G001011AX5Z@bohemia2-mail1.czech.sun.com> (original mail from Jan.Pechanec@Sun.COM); Mon, 11 Sep 2006 21:43:30 +0200 (CEST) Received: from andal (andal.Czech.Sun.COM [129.157.18.59]) by bohemia2-mail1.czech.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0J5G002CB1GHFD@bohemia2-mail1.czech.sun.com>; Mon, 11 Sep 2006 21:43:30 +0200 (CEST) Date: Mon, 11 Sep 2006 21:43:18 +0200 (CEST) From: Jan Pechanec Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] In-reply-to: <450598C9.8090702@Sun.COM> X-X-Sender: jp161948@andal To: Darren J Moffat Cc: Gary Winiger , gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, Casper.Dik@Sun.COM, glenn.faden@Sun.COM Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <200609111700.k8BH0EuE027713@marduk.eng.sun.com> <450598C9.8090702@Sun.COM> Status: RO Content-Length: 633 On Mon, 11 Sep 2006, Darren J Moffat wrote: >> Are you saying that the ssh man page should be included in this >> case? I'd think the ssh project team would update the ssh man >> page when 6203206 "sshd should set PAM_XUSER for hostbased userauth >> for audited logins to roles" is resolved. > > That would be nice, what I believe is most important though is that the > pam_unix_cred man page doesn't imply that all userauth methods work (since they > don't and can't). apropriate manual page change was ready at the time I planned putback for 6203206 for the first time so this won't be a problem. Jan. -- Jan Pechanec From sacadmin Mon Sep 11 15:25:11 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8BMPBjY013543; Mon, 11 Sep 2006 15:25:11 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8BMP57G001038; Mon, 11 Sep 2006 18:25:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8BMP4t4023779; Mon, 11 Sep 2006 18:25:04 -0400 (EDT) Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] From: Bill Sommerfeld To: James Carlson Cc: Gary Winiger , Darren.Moffat@sun.com, gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com In-Reply-To: <17669.41549.791742.488474@gargle.gargle.HOWL> References: <200609111740.k8BHeo3a027767@marduk.eng.sun.com> <17669.41549.791742.488474@gargle.gargle.HOWL> Content-Type: text/plain Date: Mon, 11 Sep 2006 18:25:04 -0400 Message-Id: <1158013504.20367.7.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 522 On Mon, 2006-09-11 at 13:52 -0400, James Carlson wrote: > Gary Winiger writes: > > ``such as in the case of some forms of "ssh -l login_name" > > (see ssh(1)).'' > > Maybe. I'd still like to see a clearer reference here, because > without the information that this is a "hostauth special," this is > likely to lead to more customer calls. Indeed. IMHO we'd be better putting effort into figuring out how to tie remote authentication mechanisms (gssapi/kerberos, ssh user keys, etc.,) into audit. - Bill From sacadmin Mon Sep 11 18:16:38 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8C1Gcp1019588; Mon, 11 Sep 2006 18:16:38 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8C1GVpK025423; Mon, 11 Sep 2006 18:16:33 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k8C1INhZ028282; Mon, 11 Sep 2006 18:18:23 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k8C1IN3C028281; Mon, 11 Sep 2006 18:18:23 -0700 (PDT) Date: Mon, 11 Sep 2006 18:18:23 -0700 (PDT) From: Gary Winiger Message-Id: <200609120118.k8C1IN3C028281@marduk.eng.sun.com> To: James.D.Carlson@sun.com, sommerfeld@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Cc: gww@eng.sun.com, Darren.Moffat@sun.com, gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1074 > > Maybe. I'd still like to see a clearer reference here, because > > without the information that this is a "hostauth special," this is > > likely to lead to more customer calls. > > Indeed. IMHO we'd be better putting effort into figuring out how to tie > remote authentication mechanisms (gssapi/kerberos, ssh user keys, etc.,) > into audit. From SunOS MLS (SunOS 4.0 based) through TS8 (SunOS 5.8 based), ``Trusted Solaris'' did this with a combination of an out of band protocol and in band attribute transmission. The equivalent of getpeerucred always gave an equivalent of the ``remote'' ucred. This included the correct and full remote audit context. Lacking that, PAM_AUSER seems like something trusted applications can provide when they have a trustworthy remote user name. Gary.. P.S. I hope to make some of the man page wording changes I'm working on available soon. Perhaps they will help the focus. The only actual from 2005/009 is s/PAM_RUSER/PAM_AUSER/g The rest is potential for use of PAM_AUSER to clean up some ugly implementation. From sacadmin Tue Sep 12 13:21:20 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8CKLK3h014994; Tue, 12 Sep 2006 13:21:20 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k8CKL9YR005684; Tue, 12 Sep 2006 15:21:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k8CKL92T005683; Tue, 12 Sep 2006 15:21:09 -0500 (CDT) Date: Tue, 12 Sep 2006 15:21:09 -0500 From: Nicolas Williams To: Gary Winiger Cc: James.D.Carlson@sun.com, sommerfeld@sun.com, Darren.Moffat@sun.com, gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Message-ID: <20060912202108.GC3764@binky.Central.Sun.COM> References: <200609120118.k8C1IN3C028281@marduk.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609120118.k8C1IN3C028281@marduk.eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1240 On Mon, Sep 11, 2006 at 06:18:23PM -0700, Gary Winiger wrote: > > Indeed. IMHO we'd be better putting effort into figuring out how to tie > > remote authentication mechanisms (gssapi/kerberos, ssh user keys, etc.,) > > into audit. > > From SunOS MLS (SunOS 4.0 based) through TS8 (SunOS 5.8 based), > ``Trusted Solaris'' did this with a combination of an out of > band protocol and in band attribute transmission. The equivalent > of getpeerucred always gave an equivalent of the ``remote'' > ucred. This included the correct and full remote audit context. > Lacking that, PAM_AUSER seems like something trusted applications > can provide when they have a trustworthy remote user name. Audit currently models the authenticated subject as identified by a Unix UID. This is clearly lame in a world in which there are non-user type of actors (hostnames, public keys or fingerprints thereof, Kerberos V principal names, PKIX certs and their DNs and subjectAltNames and what not, etc...). In the case of sshd(1M) we're saying that sometimes we know easily enough what the actor's UID is, and when that happens it will be provided via PAM_AUSER. As for the general case... That's probably a topic for a different forum. Nico -- From sacadmin Tue Sep 12 13:29:32 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8CKTVPE015124; Tue, 12 Sep 2006 13:29:32 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8CKTHBI000553; Tue, 12 Sep 2006 22:29:17 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8CKTHuU016852; Tue, 12 Sep 2006 22:29:17 +0200 (MEST) Message-Id: <200609122029.k8CKTHuU016852@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Nicolas Williams cc: Gary Winiger , James.D.Carlson@sun.com, sommerfeld@sun.com, Darren.Moffat@sun.com, gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] In-Reply-To: <20060912202108.GC3764@binky.Central.Sun.COM> References: <200609120118.k8C1IN3C028281@marduk.eng.sun.com> <20060912202108.GC3764@binky.Central.Sun.COM> Date: Tue, 12 Sep 2006 22:29:17 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 354 >This is clearly lame in a world in which there are non-user type of >actors (hostnames, public keys or fingerprints thereof, Kerberos V >principal names, PKIX certs and their DNs and subjectAltNames and what >not, etc...). But in many cases "non attributable" is just fine because none of this gives you a proper clue as to who is doing what. Casper From sacadmin Tue Sep 12 13:31:46 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8CKVkYw015143; Tue, 12 Sep 2006 13:31:46 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8CKVgCY024207; Tue, 12 Sep 2006 13:31:42 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k8CKXZjk029463; Tue, 12 Sep 2006 13:33:35 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k8CKXZX9029462; Tue, 12 Sep 2006 13:33:35 -0700 (PDT) Date: Tue, 12 Sep 2006 13:33:35 -0700 (PDT) From: Gary Winiger Message-Id: <200609122033.k8CKXZX9029462@marduk.eng.sun.com> To: gww@eng.sun.com, Nicolas.Williams@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Cc: James.D.Carlson@sun.com, sommerfeld@sun.com, Darren.Moffat@sun.com, gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1055 > Audit currently models the authenticated subject as identified by a Unix > UID. > > This is clearly lame in a world in which there are non-user type of > actors (hostnames, public keys or fingerprints thereof, Kerberos V > principal names, PKIX certs and their DNs and subjectAltNames and what > not, etc...). Audit attributes actions to Identified and Authenticated Subjects of the Solaris system. > In the case of sshd(1M) we're saying that sometimes we know easily > enough what the actor's UID is, and when that happens it will be > provided via PAM_AUSER. Actually when extending a login on ones behalf or on the behalf of another (PAM_AUSER case) the correct audit context would be that of the Solaris Subject extneding the login. Unfortunately we can't get that information in Solaris (or TX). PAM_AUSER is a viable alternative when a "single system image" is present (as in the case of the various Solaris evaluations). > As for the general case... That's probably a topic for a different > forum. Yes, not this droid. Gary.. From sacadmin Tue Sep 12 13:39:22 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8CKdM0R015250 for ; Tue, 12 Sep 2006 13:39:22 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8CKdIgb026490; Tue, 12 Sep 2006 13:39:18 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k8CKfBZi029493; Tue, 12 Sep 2006 13:41:11 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k8CKfB19029492; Tue, 12 Sep 2006 13:41:11 -0700 (PDT) Date: Tue, 12 Sep 2006 13:41:11 -0700 (PDT) From: Gary Winiger Message-Id: <200609122041.k8CKfB19029492@marduk.eng.sun.com> To: James.D.Carlson@sun.com, gww@eng.sun.com, sommerfeld@sun.com Cc: Casper.Dik@sun.com, Darren.Moffat@sun.com, Jan.Pechanec@sun.com, PSARC@sac.sfbay.sun.com, glenn.faden@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Status: RO Content-Length: 1673 > Gary.. > P.S. I hope to make some of the man page wording changes I'm working on > available soon. Perhaps they will help the focus. The only actual > from 2005/009 is s/PAM_RUSER/PAM_AUSER/g The rest is potential > for use of PAM_AUSER to clean up some ugly implementation. Later than last night. IMO the proposal is unchanged, however I hope the documentation is improved: pam_set_item(3PAM): DESCRIPTION + PAM_AUSER + The authenticated user name. Applications that are + trusted to correctly identify the authenticated user + should set this item to the authenticated user name. + See NOTES and pam_unix_cred(5). PAM_RUSER | The rlogin/rsh untrusted remote user name. NOTES + PAM_AUSER is not intended as a replacement for PAM_USER. It + is expected to be used to supplement PAM_USER when there is + an authenticated user from a source other than + pam_autenticate(3PAM). Such sources could be sshd-hostbased + authentication, kerberized rlogin, su(1M). pam_unix_cred(5): If the audit context is not already initialized and auditing is configured, these flags cause the context to be initialized to that of the user specified in | PAM_AUSER (if any) merged with the user specified in PAM_USER and host specified in PAM_RHOST. If PAM_RHOST is not specified, PAM_TTY specifies the local terminal | name. Attributing audit to PAM_AUSER and merging PAM_USER is required for correctly attributing audit- | ing when the system entry is done from another user the | can be trustworthly identified. Gary.. From sacadmin Tue Sep 12 13:45:54 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8CKjrlq015369 for ; Tue, 12 Sep 2006 13:45:54 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k8CKm1DE025046; Tue, 12 Sep 2006 16:48:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k8CKm1it025043; Tue, 12 Sep 2006 16:48:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17671.7425.726724.781290@gargle.gargle.HOWL> Date: Tue, 12 Sep 2006 16:48:01 -0400 From: James Carlson To: Gary Winiger Cc: sommerfeld@sun.com, Casper.Dik@sun.com, Darren.Moffat@sun.com, Jan.Pechanec@sun.com, PSARC@sac.sfbay.sun.com, glenn.faden@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] In-Reply-To: Gary Winiger's message of 12 September 2006 13:41:11 References: <200609122041.k8CKfB19029492@marduk.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 590 Gary Winiger writes: > + PAM_AUSER is not intended as a replacement for PAM_USER. It > + is expected to be used to supplement PAM_USER when there is > + an authenticated user from a source other than > + pam_autenticate(3PAM). Such sources could be sshd-hostbased > + authentication, kerberized rlogin, su(1M). That clears up my confusion; thanks. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Sep 12 13:54:21 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8CKsHEX015590; Tue, 12 Sep 2006 13:54:21 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k8CKsGRW005734; Tue, 12 Sep 2006 15:54:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k8CKsGQ9005733; Tue, 12 Sep 2006 15:54:16 -0500 (CDT) Date: Tue, 12 Sep 2006 15:54:16 -0500 From: Nicolas Williams To: Casper.Dik@sun.com Cc: Gary Winiger , James.D.Carlson@sun.com, sommerfeld@sun.com, Darren.Moffat@sun.com, gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Message-ID: <20060912205408.GD3764@binky.Central.Sun.COM> References: <200609120118.k8C1IN3C028281@marduk.eng.sun.com> <20060912202108.GC3764@binky.Central.Sun.COM> <200609122029.k8CKTHuU016852@vaticaan.holland.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609122029.k8CKTHuU016852@vaticaan.holland.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 844 On Tue, Sep 12, 2006 at 10:29:17PM +0200, Casper.Dik@Sun.COM wrote: > >This is clearly lame in a world in which there are non-user type of > >actors (hostnames, public keys or fingerprints thereof, Kerberos V > >principal names, PKIX certs and their DNs and subjectAltNames and what > >not, etc...). > > But in many cases "non attributable" is just fine because none of this > gives you a proper clue as to who is doing what. But if you have any sort of authenticated client name then auditing that somewhere could certainly prove useful. "Hmm, a non-attributable write to /etc/shadow happened here, but look it was a Kerberos V principal, host/borg.sfbay.sun.com," now go look at borg. I believe that would be more useful than merely knowing the IP address of the client, even if only marginally so within an intranet like SWAN. Nico -- From sacadmin Tue Sep 12 15:09:06 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8CM95fX017855; Tue, 12 Sep 2006 15:09:06 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8CM8sMN011376; Tue, 12 Sep 2006 18:08:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8CM8s0i028174; Tue, 12 Sep 2006 18:08:54 -0400 (EDT) Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] From: Bill Sommerfeld To: Casper.Dik@sun.com Cc: Nicolas Williams , Gary Winiger , James.D.Carlson@sun.com, Darren.Moffat@sun.com, gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com In-Reply-To: <200609122029.k8CKTHuU016852@vaticaan.holland.sun.com> References: <200609120118.k8C1IN3C028281@marduk.eng.sun.com> <20060912202108.GC3764@binky.Central.Sun.COM> <200609122029.k8CKTHuU016852@vaticaan.holland.sun.com> Content-Type: text/plain Date: Tue, 12 Sep 2006 18:08:53 -0400 Message-Id: <1158098933.26566.26.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 713 On Tue, 2006-09-12 at 22:29 +0200, Casper.Dik@Sun.COM wrote: > >This is clearly lame in a world in which there are non-user type of > >actors (hostnames, public keys or fingerprints thereof, Kerberos V > >principal names, PKIX certs and their DNs and subjectAltNames and what > >not, etc...). > > But in many cases "non attributable" is just fine because none of this > gives you a proper clue as to who is doing what. I'd argue that it's substantially more useful to audit the kerberos principal or ssh user key used to gain access to an account than to know what account the client system said initiated the connection. Doubly so in the event a role account is shared between multiple users. - Bill From sacadmin Tue Sep 12 15:16:55 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8CMGtpk017935; Tue, 12 Sep 2006 15:16:55 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k8CMGK8Z005875; Tue, 12 Sep 2006 17:16:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k8CMGKX2005874; Tue, 12 Sep 2006 17:16:20 -0500 (CDT) Date: Tue, 12 Sep 2006 17:16:20 -0500 From: Nicolas Williams To: Bill Sommerfeld Cc: Casper.Dik@sun.com, Gary Winiger , James.D.Carlson@sun.com, Darren.Moffat@sun.com, gww@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, glenn.faden@sun.com, Jan.Pechanec@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Message-ID: <20060912221619.GG3764@binky.Central.Sun.COM> References: <200609120118.k8C1IN3C028281@marduk.eng.sun.com> <20060912202108.GC3764@binky.Central.Sun.COM> <200609122029.k8CKTHuU016852@vaticaan.holland.sun.com> <1158098933.26566.26.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1158098933.26566.26.camel@thunk> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 989 On Tue, Sep 12, 2006 at 06:08:53PM -0400, Bill Sommerfeld wrote: > On Tue, 2006-09-12 at 22:29 +0200, Casper.Dik@Sun.COM wrote: > > >This is clearly lame in a world in which there are non-user type of > > >actors (hostnames, public keys or fingerprints thereof, Kerberos V > > >principal names, PKIX certs and their DNs and subjectAltNames and what > > >not, etc...). > > > > But in many cases "non attributable" is just fine because none of this > > gives you a proper clue as to who is doing what. > > I'd argue that it's substantially more useful to audit the kerberos > principal or ssh user key used to gain access to an account than to know > what account the client system said initiated the connection. > > Doubly so in the event a role account is shared between multiple users. Exactly. Whether this should be done as an additional token in all audit events for the given login session, or just in the login event for it, I don't care much, but I bet someone does. Nico -- From sacadmin Wed Sep 20 16:58:14 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8KNwELf024257; Wed, 20 Sep 2006 16:58:14 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8KNwBtT020128; Wed, 20 Sep 2006 16:58:11 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id k8L00HMu011956; Wed, 20 Sep 2006 17:00:17 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id k8L00G09011955; Wed, 20 Sep 2006 17:00:17 -0700 (PDT) Date: Wed, 20 Sep 2006 17:00:17 -0700 (PDT) From: Gary Winiger Message-Id: <200609210000.k8L00G09011955@marduk.eng.sun.com> To: PSARC@sac.sfbay.sun.com, gww@sac.sfbay.sun.com Cc: casper.dik@sun.com, glenn.faden@sun.com, jan.pechanec@sun.com Subject: Re: remote user audit attribution update [PSARC/2006/534 Timeout: 09/20/2006] Status: RO Content-Length: 257 > Full diffmarked man pages are in the case directory. This case was approved at today's PSARC meeting. A proposal.txt file is in the case directory along with updated diffmarked man pages that reflect the changes noted during the discussion. Gary..