From casper@sac.sfbay.sun.com Fri Jul 3 05:43:42 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n63Chfd0012810 for ; Fri, 3 Jul 2009 05:43:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n63ChdFi029833; Fri, 3 Jul 2009 20:43:41 +0800 (SGT) 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 <0KM700G01I0SVY00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 03 Jul 2009 05:43:40 -0700 (PDT) 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 <0KM70039CI0RM1F0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 03 Jul 2009 05:43:39 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n63ChdYk016532; Fri, 03 Jul 2009 05:43:39 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n63ChcLO012797; Fri, 03 Jul 2009 05:43:38 -0700 (PDT) Received: (from casper@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n63Chc5a012793; Fri, 03 Jul 2009 05:43:38 -0700 (PDT) Date: Fri, 03 Jul 2009 05:43:38 -0700 (PDT) From: Casper Dik Subject: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] To: PSARC-ext@sun.com Message-id: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4401 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: In-kernel pfexec implementation. 1.2. Name of Document Author/Supplier: Author: Casper Dik 1.3 Date of This Document: 03 July, 2009 4. Technical Description I'm sponsoring this fasttrack for myself. This project proposes an in-kernel implementation of the pfexec(1) command. Release binding: minor. The implementation of pfexec(1) is changed such that is add the PRIV_PFEXEC credential flag and then executes the program. The execve() system call will notice the PRIV_PFEXEC flag and it will ask the pfexecd daemon whether the file can be executed and which changes to the credential are required. The pfexecd is started at boot through SMF as "svc:/system/pfexecd". Implementing pfexec in the kernel delivers the following advantages: - pfshells come at no charge; this project will deliver the following pf*sh*: pfbash pfcsh pfksh pfksh93 pfsh pftcsh pfzsh A pf*sh* starts, sets the PRIV_PFEXEC flag and executes the shell. Code which supports profile shells in current shells will be removed. - Fewer privileges are needed in the Limit sets for in users in certain roles. (Unsafe privileges are not required in the limit set unless required by the exec_attr entry) - More fine grained control in exec_attr. E.g., instead of creating an exec_attr for "/usr/sbin/mount", you can now create different exec_attrs for each of the mount commands in /usr/lib/fs/*. - Profile shells are a bit more efficient (pfexec is no longer executed by the profile shells; "pfexec" by hand will work as before) Additional, this project will deliver "Forced Privileges" through the exec_attr database: - Unsafe privileges are not required to execute ping, traceroute, etc. (If an executable is set-uid root, then the kernel will lookup the Forced Privileges for that executable) - Set-uid applications in that list will not start as root, instead they run with the appropriate privileges. ppriv(1) will shell the PRIV_PFEXEC flag: % pftcsh > ppriv $$ 4812: sh flags = PRIV_PFEXEC E: basic I: basic P: basic L: all And ppriv(1) can make your shell a profile shell: % ppriv -P $$ There's no restriction in setting the PRIV_PFEXEC as using "pfexec" is not restricted. Exported Interface name PRIV_PFEXEC Committed getpflags(2) svc:/system/pfexecd Committed pfexecd(1m) pf*sh* Committed pfexec(1) new flag in ppriv Committed ppriv(1) --- getpflags.2 Fri Jul 3 14:29:27 2009 +++ getpflags.2.new Fri Jul 3 14:34:05 2009 @@ -47,6 +47,12 @@ privilege debugging enabled. Processes can set and unset this flag at will. + PRIV_PFEXEC + + This one bit flag takes the value of 0 (unset) or 1 (set). + If this flag is set then all the commands are executed as if + they are executed from a profile shell. + NET_MAC_AWARE NET_MAC_AWARE_INHERIT These flags are available only if the system is configured --- pfexec.1 Fri Jul 3 14:35:10 2009 +++ pfexec.1.new Fri Jul 3 14:36:08 2009 @@ -12,8 +12,16 @@ /usr/bin/pfcsh [ options ] [ argument ]... + /usr/bin/pftcsh [ options ] [ argument ]... + /usr/bin/pfksh [ options ] [ argument ]... + /usr/bin/pfksh93 [ options ] [ argument ]... + + /usr/bin/pfbash [ options ] [ argument ]... + + /usr/bin/pfzsh [ options ] [ argument ]... + DESCRIPTION The pfexec program is used to execute commands with the attri- butes specified by the user's profiles in the exec_attr(4) data- --- ppriv.1 Fri Jul 3 14:29:27 2009 +++ ppriv.1.new Fri Jul 3 14:31:50 2009 @@ -45,6 +45,8 @@ -N Turns off privilege debugging for the processes or command supplied. + -P Enable the PRIV_PFEXEC process attribute. + -s spec Modifies a process's privilege sets according to spec, a specification with the format [AEILP][+- =]privsetspec, containing no spaces, where: 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Fri Jul 3 06:08:13 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 n63D8CIh013543 for ; Fri, 3 Jul 2009 06:08:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n63D89j4013537 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 3 Jul 2009 14:08:11 +0100 (BST) 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 <0KM700I0HJ5MT200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 03 Jul 2009 07:08:10 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KM700BNDJ5LME50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 03 Jul 2009 07:08:09 -0600 (MDT) 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 n63D881x012160 for ; Fri, 03 Jul 2009 13:08:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KM700M00ISEQT00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 03 Jul 2009 14:08:08 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KM700G6CJ5JW1C0@fe-emea-10.sun.com>; Fri, 03 Jul 2009 14:08:08 +0100 (BST) Date: Fri, 03 Jul 2009 14:08:07 +0100 From: Darren J Moffat Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Casper Dik Cc: PSARC-ext@sun.com Message-id: <4A4E02B7.8080406@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 2190 Casper Dik wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > In-kernel pfexec implementation. > 1.2. Name of Document Author/Supplier: > Author: Casper Dik > 1.3 Date of This Document: > 03 July, 2009 > 4. Technical Description > I'm sponsoring this fasttrack for myself. > > This project proposes an in-kernel implementation of the > pfexec(1) command. > > Release binding: minor. > > The implementation of pfexec(1) is changed such that is > add the PRIV_PFEXEC credential flag and then executes > the program. The execve() system call will notice the > PRIV_PFEXEC flag and it will ask the pfexecd daemon > whether the file can be executed and which changes to the > credential are required. > > The pfexecd is started at boot through SMF as "svc:/system/pfexecd". I'm assuming here that pfexecd is running as root with all privileges ? Or is it able to run with a reduced set (for example pfexecd shouldn't I think need most of the current basic privs or file_write from the new set in PSARC/2009/378). Though it feels to me like it should be running with all privs because other wise a lower privileged process is acting as an authority to hand out privs it doesn't actually have. Sorry for not bringing this next one up in the prereview but it only just popped into my head. In the current system pfexec itself will do the nameservice lookup to find the exec_attr entry to use. If I understand the new system it will be pfexecd doing that, right ? So this changes things with respect to per user nscd (needed for doing self credential'd lookups) in that user_attr, prof_attr and exec_attr lookups for 'pfexec' won't use the per user nscd ? Or am I missing something. In the pre-review we discussed wither or not a TX configuration would have one pfexecd per system (in the global zone) or one per zone. This would ensure that pfexecd "follows" what happens with nscd which can be one in the global zone or one per zone. I can't tell from the case material what the decision was on that. -- Darren J Moffat From casper@holland.sun.com Fri Jul 3 06:13:04 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 n63DD3u8013623 for ; Fri, 3 Jul 2009 06:13:03 -0700 (PDT) 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 n63DD2Yc029440 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Fri, 3 Jul 2009 06:13:03 -0700 (PDT) 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 <0KM70020JJDQ3P00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 03 Jul 2009 06:13:02 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KM700BOJJDPQX90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 03 Jul 2009 06:13:02 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n63DCx6Y052315; Fri, 03 Jul 2009 14:12:59 +0100 (BST) Date: Fri, 03 Jul 2009 15:12:59 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <4A4E02B7.8080406@Sun.COM> Sender: casper@holland.sun.com To: Darren J Moffat Cc: Casper Dik , PSARC-ext@sun.com Message-id: <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> Status: RO Content-Length: 1442 >I'm assuming here that pfexecd is running as root with all privileges ? >Or is it able to run with a reduced set (for example pfexecd shouldn't I >think need most of the current basic privs or file_write from the new >set in PSARC/2009/378). Though it feels to me like it should be running >with all privs because other wise a lower privileged process is acting >as an authority to hand out privs it doesn't actually have. Yes, correct. >Sorry for not bringing this next one up in the prereview but it only >just popped into my head. In the current system pfexec itself will do >the nameservice lookup to find the exec_attr entry to use. If I >understand the new system it will be pfexecd doing that, right ? So >this changes things with respect to per user nscd (needed for doing self >credential'd lookups) in that user_attr, prof_attr and exec_attr lookups >for 'pfexec' won't use the per user nscd ? Or am I missing something. Right. So where's the per-user nscd case? >In the pre-review we discussed wither or not a TX configuration would >have one pfexecd per system (in the global zone) or one per zone. This >would ensure that pfexecd "follows" what happens with nscd which can be >one in the global zone or one per zone. I can't tell from the case >material what the decision was on that. There's apparently one nscd per TX system and it makes sense there's only one pfexecd in that schema. Casper From Darren.Moffat@sun.com Fri Jul 3 06:38:37 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 n63Dcbt6013696 for ; Fri, 3 Jul 2009 06:38:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n63Dca8H010840 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 3 Jul 2009 06:38:37 -0700 (PDT) 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 <0KM700M0JKKC7E00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 03 Jul 2009 07:38:36 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KM700BK8KKAMG80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 03 Jul 2009 07:38:35 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n63DcY0M019466 for ; Fri, 03 Jul 2009 13:38:34 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KM700E00KEOEW00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 03 Jul 2009 14:38:34 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KM7006CWKK0ZYA0@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 03 Jul 2009 14:38:24 +0100 (BST) Date: Fri, 03 Jul 2009 14:38:24 +0100 From: Darren J Moffat Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> Sender: Darren.Moffat@sun.com To: Casper.Dik@sun.com Cc: PSARC-ext@sun.com Message-id: <4A4E09D0.7000906@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1791 Casper.Dik@Sun.COM wrote: > >> I'm assuming here that pfexecd is running as root with all privileges ? >> Or is it able to run with a reduced set (for example pfexecd shouldn't I >> think need most of the current basic privs or file_write from the new >> set in PSARC/2009/378). Though it feels to me like it should be running >> with all privs because other wise a lower privileged process is acting >> as an authority to hand out privs it doesn't actually have. > > Yes, correct. > >> Sorry for not bringing this next one up in the prereview but it only >> just popped into my head. In the current system pfexec itself will do >> the nameservice lookup to find the exec_attr entry to use. If I >> understand the new system it will be pfexecd doing that, right ? So >> this changes things with respect to per user nscd (needed for doing self >> credential'd lookups) in that user_attr, prof_attr and exec_attr lookups >> for 'pfexec' won't use the per user nscd ? Or am I missing something. > > Right. So where's the per-user nscd case? PSARC 2005/133 covers the introduction of per-user nscd. It is enabled by setting 'enable-per-user-lookup'. >> In the pre-review we discussed wither or not a TX configuration would >> have one pfexecd per system (in the global zone) or one per zone. This >> would ensure that pfexecd "follows" what happens with nscd which can be >> one in the global zone or one per zone. I can't tell from the case >> material what the decision was on that. > > There's apparently one nscd per TX system and it makes sense there's > only one pfexecd in that schema. txzonemgr can be used to change that between one per system and one per zone and the method script for svc:/system/name-service-cache sets it up. -- Darren J Moffat From casper@holland.sun.com Fri Jul 3 07:08: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 n63E8RhG014456 for ; Fri, 3 Jul 2009 07:08:27 -0700 (PDT) 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 n63E8Pr7019416 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Fri, 3 Jul 2009 15:08:26 +0100 (BST) 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 <0KM700505LY1SW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 03 Jul 2009 07:08:25 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KM700BSFLY0QXC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 03 Jul 2009 07:08:24 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n63E8NPW005371; Fri, 03 Jul 2009 15:08:23 +0100 (BST) Date: Fri, 03 Jul 2009 16:08:23 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <4A4E09D0.7000906@Sun.COM> Sender: casper@holland.sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <200907031408.n63E8NPW005371@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> <4A4E09D0.7000906@Sun.COM> Status: RO Content-Length: 880 >PSARC 2005/133 covers the introduction of per-user nscd. > >It is enabled by setting 'enable-per-user-lookup'. Are you expecting that exec_attr and such will fail when they are attempted by root? >>> In the pre-review we discussed wither or not a TX configuration would >>> have one pfexecd per system (in the global zone) or one per zone. This >>> would ensure that pfexecd "follows" what happens with nscd which can be >>> one in the global zone or one per zone. I can't tell from the case >>> material what the decision was on that. >> >> There's apparently one nscd per TX system and it makes sense there's >> only one pfexecd in that schema. > >txzonemgr can be used to change that between one per system and one per >zone and the method script for svc:/system/name-service-cache sets it up. We'll make sure that we'll test pfexecd with TX configured. Casper From danek.duvall@sun.com Fri Jul 3 08:13: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 n63FDAhc023918 for ; Fri, 3 Jul 2009 08:13:11 -0700 (PDT) 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 n63FD4df026483 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 3 Jul 2009 16:13:10 +0100 (BST) 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 <0KM700A0VOXXBL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 03 Jul 2009 08:13:09 -0700 (PDT) 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 <0KM700B99OXWQUF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 03 Jul 2009 08:13:08 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n63FD8eh028834 for ; Fri, 03 Jul 2009 08:13:08 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n63FD7su022910; Fri, 03 Jul 2009 08:13:07 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n63FD7V0022909; Fri, 03 Jul 2009 08:13:07 -0700 (PDT) Date: Fri, 03 Jul 2009 08:13:07 -0700 From: Danek Duvall Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> To: Casper Dik Cc: PSARC-ext@sun.com Message-id: <20090703151307.GO12356@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> User-Agent: Mutt/1.5.20 (2009-06-23) Status: RO Content-Length: 180 On Fri, Jul 03, 2009 at 05:43:38AM -0700, Casper Dik wrote: > And ppriv(1) can make your shell a profile shell: > > % ppriv -P $$ Is there a way to turn that off again? Danek From Nicolas.Williams@sun.com Sun Jul 5 04:24:45 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 n65BOjrc002980 for ; Sun, 5 Jul 2009 04:24:45 -0700 (PDT) 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 n65BOi8c010442; Sun, 5 Jul 2009 04:24:44 -0700 (PDT) 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 <0KMB009033P8BB00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 05 Jul 2009 04:24:44 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB006A43P7P3D0@nwk-avmta-1.sfbay.Sun.COM>; Sun, 05 Jul 2009 04:24:44 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n65BM28u018803; Sun, 05 Jul 2009 06:22:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n65BM17j018802; Sun, 05 Jul 2009 06:22:01 -0500 (CDT) Date: Sun, 05 Jul 2009 06:22:01 -0500 From: Nicolas Williams Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <4A4E02B7.8080406@Sun.COM> To: Darren J Moffat Cc: Casper Dik , PSARC-ext@sun.com Message-id: <20090705112201.GZ15302@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 671 On Fri, Jul 03, 2009 at 02:08:07PM +0100, Darren J Moffat wrote: > >The pfexecd is started at boot through SMF as "svc:/system/pfexecd". > > I'm assuming here that pfexecd is running as root with all privileges ? > Or is it able to run with a reduced set (for example pfexecd shouldn't I > think need most of the current basic privs or file_write from the new > set in PSARC/2009/378). Though it feels to me like it should be running > with all privs because other wise a lower privileged process is acting > as an authority to hand out privs it doesn't actually have. What's wrong with pfexecd dropping privs after registering its door with the kernel? Nico -- From Nicolas.Williams@sun.com Sun Jul 5 04:26:00 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n65BPxUi002992 for ; Sun, 5 Jul 2009 04:25:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n65BPsWw027938; Sun, 5 Jul 2009 19:25:55 +0800 (SGT) 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 <0KMB009013R6KI00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 05 Jul 2009 04:25:54 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB0063D3R5OCE0@nwk-avmta-1.sfbay.Sun.COM>; Sun, 05 Jul 2009 04:25:54 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n65BNCCL018809; Sun, 05 Jul 2009 06:23:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n65BNC1d018808; Sun, 05 Jul 2009 06:23:12 -0500 (CDT) Date: Sun, 05 Jul 2009 06:23:12 -0500 From: Nicolas Williams Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907031408.n63E8NPW005371@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <20090705112312.GA15302@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> <4A4E09D0.7000906@Sun.COM> <200907031408.n63E8NPW005371@dm-holland-02.uk.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 330 On Fri, Jul 03, 2009 at 04:08:23PM +0200, Casper.Dik@Sun.COM wrote: > >PSARC 2005/133 covers the introduction of per-user nscd. > > > >It is enabled by setting 'enable-per-user-lookup'. > > Are you expecting that exec_attr and such will fail when they are > attempted by root? Not so much exec_attr as getusernam(3C). Nico -- From Nicolas.Williams@sun.com Sun Jul 5 04:40:04 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 n65Be3x8003209 for ; Sun, 5 Jul 2009 04:40:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n65Be1BG002696 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 5 Jul 2009 12:40:02 +0100 (BST) 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 <0KMB004094EPFW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 05 Jul 2009 05:40:01 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB00EE34EPRB40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 05 Jul 2009 05:40:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n65BbIst018818; Sun, 05 Jul 2009 06:37:18 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n65BbIxp018817; Sun, 05 Jul 2009 06:37:18 -0500 (CDT) Date: Sun, 05 Jul 2009 06:37:18 -0500 From: Nicolas Williams Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> To: Casper Dik Cc: PSARC-ext@sun.com Message-id: <20090705113718.GB15302@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1024 On Fri, Jul 03, 2009 at 05:43:38AM -0700, Casper Dik wrote: > Additional, this project will deliver "Forced Privileges" through > the exec_attr database: > > - Unsafe privileges are not required to execute ping, traceroute, > etc. (If an executable is set-uid root, then the kernel > will lookup the Forced Privileges for that executable) > - Set-uid applications in that list will not start as root, > instead they run with the appropriate privileges. It's not clear if you meant that there's a new interface for specifying "Forced Privileges". Are you saying that there's now a way to separately specify privileges to "force" on exec() beyond what the process has in its limit set, or that the kernel grants less than "full privilege" (currently euid == 0 + oE = oP = L) to processes exec()ing set-uid programs for which there exist exec_attr(4) entries? If the former then I'd expect there should be more details. If the latter, then, does that apply regardless of whether PRIV_PFEXEC is set? Nico -- From Nicolas.Williams@sun.com Sun Jul 5 04:54:55 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 n65Bssc3003550 for ; Sun, 5 Jul 2009 04:54:54 -0700 (PDT) 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 n65BsstS038868 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 5 Jul 2009 05:54:54 -0600 (MDT) 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 <0KMB0040B53I0000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 05 Jul 2009 04:54:54 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB001SL53GUKD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 05 Jul 2009 04:54:53 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n65BqBxA018833; Sun, 05 Jul 2009 06:52:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n65BqBt9018832; Sun, 05 Jul 2009 06:52:11 -0500 (CDT) Date: Sun, 05 Jul 2009 06:52:11 -0500 From: Nicolas Williams Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> To: Casper Dik Cc: PSARC-ext@sun.com Message-id: <20090705115210.GC15302@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1526 On Fri, Jul 03, 2009 at 05:43:38AM -0700, Casper Dik wrote: > The pfexecd is started at boot through SMF as "svc:/system/pfexecd". - I thought we weren't supposed to keep the 'd' for daemon in service names. - What happens of this service is not online, or even, gasp, disabled? Is there a fallback on exec()ing the old pfexec, or is that just a shim now? (my guess: no fallback) Do exec()s block forever until the service is restarted? Do they block interruptibly? (my guess: yes) Is there any way for users to get notification that this service is not online when they attempt to use it through pfexec? (my guess: no) - What about exec()ing set-uid programs when the service is unavailable? The kernel will also upcall to this service for those, right? If so, does that mean that if the service is offline then the only way to fix it is to login (not su, since it is set-uid!) as a user with sufficient privilege and/or authorization? Or is there any fallback on the old set-uid behavior in this case? (I have no guess about this case :) - Does the kernel cache results from pfexecd? (I'd be surprised if it didn't!) If so, is there a way to prime this cache as a way to protect against problems with the service? (e.g., pre-load or hardcode entries for su(1M)). Is this cache flushed on service restart? On refresh? - Does refreshing the service accomplish anything else besides flushing any kernel-land cache? (my guess: no) Nico -- From Nicolas.Williams@Sun.COM Sun Jul 5 05:07: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 n65C7w7J003747 for ; Sun, 5 Jul 2009 05:07:58 -0700 (PDT) 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 n65C7wv9043327 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 5 Jul 2009 06:07:58 -0600 (MDT) 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 <0KMB007015PAOS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 05 Jul 2009 06:07:58 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB00EU75P9RB60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 05 Jul 2009 06:07:57 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n65C5EZX018847; Sun, 05 Jul 2009 07:05:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n65C5EIe018846; Sun, 05 Jul 2009 07:05:14 -0500 (CDT) Date: Sun, 05 Jul 2009 07:05:14 -0500 From: Nicolas Williams Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <20090705113718.GB15302@Sun.COM> To: Casper Dik Cc: PSARC-ext@Sun.COM Message-id: <20090705120514.GE15302@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <20090705113718.GB15302@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 781 On Sun, Jul 05, 2009 at 06:37:18AM -0500, Nicolas Williams wrote: > Are you saying that there's now a way to separately specify privileges > to "force" on exec() beyond what the process has in its limit set, or > that the kernel grants less than "full privilege" (currently euid == 0 + > oE = oP = L) to processes exec()ing set-uid programs for which there > exist exec_attr(4) entries? > > If the former then I'd expect there should be more details. If the > latter, then, does that apply regardless of whether PRIV_PFEXEC is set? And if the latter, what happens when exec()ing set-uid programs without matching exec_attr(4) entries? Is there any way to apply a wildcard rule to grant not privileges to processes running set-uid programs not listed in exec_attr(4)? Nico -- From casper@holland.sun.com Sun Jul 5 08:01:06 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 n65F15Nf011762 for ; Sun, 5 Jul 2009 08:01:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n65F14h0029066 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Sun, 5 Jul 2009 08:01:05 -0700 (PDT) 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 <0KMB00H0ZDPSQO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 05 Jul 2009 08:01:04 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB00H4CDPRE500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 05 Jul 2009 08:01:04 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n65F10oa061767; Sun, 05 Jul 2009 16:01:00 +0100 (BST) Date: Sun, 05 Jul 2009 17:01:00 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <20090705112201.GZ15302@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Darren J Moffat , Casper Dik , PSARC-ext@sun.com Message-id: <200907051501.n65F10oa061767@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <20090705112201.GZ15302@Sun.COM> Status: RO Content-Length: 737 >On Fri, Jul 03, 2009 at 02:08:07PM +0100, Darren J Moffat wrote: >> >The pfexecd is started at boot through SMF as "svc:/system/pfexecd". >> >> I'm assuming here that pfexecd is running as root with all privileges ? >> Or is it able to run with a reduced set (for example pfexecd shouldn't I >> think need most of the current basic privs or file_write from the new >> set in PSARC/2009/378). Though it feels to me like it should be running >> with all privs because other wise a lower privileged process is acting >> as an authority to hand out privs it doesn't actually have. > >What's wrong with pfexecd dropping privs after registering its door with >the kernel? Because lesser privilege processes could subvert it. Casper From casper@holland.sun.com Sun Jul 5 08:02:07 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 n65F27MS017579 for ; Sun, 5 Jul 2009 08:02:07 -0700 (PDT) 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 n65F26eJ029290 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Sun, 5 Jul 2009 08:02:07 -0700 (PDT) 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 <0KMB00617DRI5L00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 05 Jul 2009 09:02:06 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB00M05DRH6M10@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 05 Jul 2009 09:02:06 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n65F244E061926; Sun, 05 Jul 2009 16:02:04 +0100 (BST) Date: Sun, 05 Jul 2009 17:02:04 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <20090705112312.GA15302@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <200907051502.n65F244E061926@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> <4A4E09D0.7000906@Sun.COM> <200907031408.n63E8NPW005371@dm-holland-02.uk.sun.com> <20090705112312.GA15302@Sun.COM> Status: RO Content-Length: 366 >On Fri, Jul 03, 2009 at 04:08:23PM +0200, Casper.Dik@Sun.COM wrote: >> >PSARC 2005/133 covers the introduction of per-user nscd. >> > >> >It is enabled by setting 'enable-per-user-lookup'. >> >> Are you expecting that exec_attr and such will fail when they are >> attempted by root? > >Not so much exec_attr as getusernam(3C). And why would that fail? Casper From casper@holland.sun.com Sun Jul 5 08:10:02 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n65FA1iQ021024 for ; Sun, 5 Jul 2009 08:10:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n65F9wEv015212 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Sun, 5 Jul 2009 23:10:00 +0800 (SGT) 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 <0KMB00701E4N2C00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 05 Jul 2009 09:09:59 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB00MF8E4M6X10@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 05 Jul 2009 09:09:59 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n65F9ukU063375; Sun, 05 Jul 2009 16:09:56 +0100 (BST) Date: Sun, 05 Jul 2009 17:09:56 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <20090705115210.GC15302@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Casper Dik , PSARC-ext@sun.com Message-id: <200907051509.n65F9ukU063375@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <20090705115210.GC15302@Sun.COM> Status: RO Content-Length: 2107 >On Fri, Jul 03, 2009 at 05:43:38AM -0700, Casper Dik wrote: >> The pfexecd is started at boot through SMF as "svc:/system/pfexecd". > > - I thought we weren't supposed to keep the 'd' for daemon in service > names. Fair enough. > - What happens of this service is not online, or even, gasp, disabled? > > Is there a fallback on exec()ing the old pfexec, or is that just a > shim now? (my guess: no fallback) No fallback. There's no old pfexec. > Do exec()s block forever until the service is restarted? Do they > block interruptibly? (my guess: yes) If the service isn't registered, you disable all profile shells and pfexec. That, I believe, is a feature. > Is there any way for users to get notification that this service is > not online when they attempt to use it through pfexec? (my guess: no) See above. > - What about exec()ing set-uid programs when the service is > unavailable? The kernel will also upcall to this service for those, > right? If so, does that mean that if the service is offline then the > only way to fix it is to login (not su, since it is set-uid!) as a > user with sufficient privilege and/or authorization? > Or is there any fallback on the old set-uid behavior in this case? > > (I have no guess about this case :) The file is still set-uid root; if the kernel cannot figure out which privileges to use, it will fallback to the old set-uid root behaviour. > - Does the kernel cache results from pfexecd? (I'd be surprised if it > didn't!) No, it doesn't. You don't cache things which are cheap to recompute, especially if we're compare this to a full exec. It may save a little but as you point out here, having a cache is expensive so we avoid it. > If so, is there a way to prime this cache as a way to protect against > problems with the service? (e.g., pre-load or hardcode entries for > su(1M)). > > Is this cache flushed on service restart? On refresh? > > - Does refreshing the service accomplish anything else besides flushing > any kernel-land cache? (my guess: no) There's no cache. Casper From casper@holland.sun.com Sun Jul 5 08:14:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n65FEOHO023506 for ; Sun, 5 Jul 2009 08:14:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n65FEMZA017146 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Sun, 5 Jul 2009 23:14:23 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMB00I03EBYQ200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 05 Jul 2009 08:14:22 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB00HHGEBXE500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 05 Jul 2009 08:14:21 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n65FEFfG064198; Sun, 05 Jul 2009 16:14:15 +0100 (BST) Date: Sun, 05 Jul 2009 17:14:15 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <20090705120514.GE15302@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Casper Dik , PSARC-ext@sun.com Message-id: <200907051514.n65FEFfG064198@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <20090705113718.GB15302@Sun.COM> <20090705120514.GE15302@Sun.COM> Status: RO Content-Length: 913 >On Sun, Jul 05, 2009 at 06:37:18AM -0500, Nicolas Williams wrote: >> Are you saying that there's now a way to separately specify privileges >> to "force" on exec() beyond what the process has in its limit set, or >> that the kernel grants less than "full privilege" (currently euid == 0 + >> oE = oP = L) to processes exec()ing set-uid programs for which there >> exist exec_attr(4) entries? >> >> If the former then I'd expect there should be more details. If the >> latter, then, does that apply regardless of whether PRIV_PFEXEC is set? > >And if the latter, what happens when exec()ing set-uid programs without >matching exec_attr(4) entries? Is there any way to apply a wildcard >rule to grant not privileges to processes running set-uid programs not >listed in exec_attr(4)? The current implementation leaves the semantics of a set-uid root executable without an exec_attr entry unchanged. Casper From Nicolas.Williams@sun.com Sun Jul 5 09:35:33 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 n65GZXho008146 for ; Sun, 5 Jul 2009 09:35:33 -0700 (PDT) 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 n65GZUsO028041; Sun, 5 Jul 2009 09:35:30 -0700 (PDT) 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 <0KMB00301I367500@nwk-avmta-2.sfbay.sun.com>; Sun, 05 Jul 2009 09:35:30 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB00HNPI35ED20@nwk-avmta-2.sfbay.sun.com>; Sun, 05 Jul 2009 09:35:29 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n65GWlEq019009; Sun, 05 Jul 2009 11:32:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n65GWlr0019008; Sun, 05 Jul 2009 11:32:47 -0500 (CDT) Date: Sun, 05 Jul 2009 11:32:47 -0500 From: Nicolas Williams Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907051501.n65F10oa061767@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: Darren J Moffat , Casper Dik , PSARC-ext@sun.com Message-id: <20090705163247.GG15302@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <20090705112201.GZ15302@Sun.COM> <200907051501.n65F10oa061767@dm-holland-02.uk.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 856 On Sun, Jul 05, 2009 at 05:01:00PM +0200, Casper.Dik@Sun.COM wrote: > > >On Fri, Jul 03, 2009 at 02:08:07PM +0100, Darren J Moffat wrote: > >> >The pfexecd is started at boot through SMF as "svc:/system/pfexecd". > >> > >> I'm assuming here that pfexecd is running as root with all privileges ? > >> Or is it able to run with a reduced set (for example pfexecd shouldn't I > >> think need most of the current basic privs or file_write from the new > >> set in PSARC/2009/378). Though it feels to me like it should be running > >> with all privs because other wise a lower privileged process is acting > >> as an authority to hand out privs it doesn't actually have. > > > >What's wrong with pfexecd dropping privs after registering its door with > >the kernel? > > Because lesser privilege processes could subvert it. SNOCD wouldn't prevent that? From Nicolas.Williams@sun.com Sun Jul 5 09:41:26 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n65GfPE4008162 for ; Sun, 5 Jul 2009 09:41:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n65GfKKw026876; Mon, 6 Jul 2009 00:41:21 +0800 (SGT) 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 <0KMB00803ICWF100@nwk-avmta-1.sfbay.Sun.COM>; Sun, 05 Jul 2009 09:41:20 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMB00HUWICVAPB0@nwk-avmta-1.sfbay.Sun.COM>; Sun, 05 Jul 2009 09:41:20 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n65GcXfq019015; Sun, 05 Jul 2009 11:38:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n65GcXcX019014; Sun, 05 Jul 2009 11:38:33 -0500 (CDT) Date: Sun, 05 Jul 2009 11:38:33 -0500 From: Nicolas Williams Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907051502.n65F244E061926@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <20090705163833.GH15302@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> <4A4E09D0.7000906@Sun.COM> <200907031408.n63E8NPW005371@dm-holland-02.uk.sun.com> <20090705112312.GA15302@Sun.COM> <200907051502.n65F244E061926@dm-holland-02.uk.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 510 On Sun, Jul 05, 2009 at 05:02:04PM +0200, Casper.Dik@Sun.COM wrote: > >Not so much exec_attr as getusernam(3C). > > And why would that fail? As root it might fail. The reason is that the directory might not want to let host entities see user data, while allowing users to see it. Enabling that was the point of self-credentialled name service lookups. In an environment that demands that pfexecd should fork helper processes to do the name service lookups as the users that are exec()ing things. Nico -- From Darren.Moffat@sun.com Mon Jul 6 01:30:06 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 n668U5i5025218 for ; Mon, 6 Jul 2009 01:30:05 -0700 (PDT) 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 n668TvIZ013778 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 6 Jul 2009 09:30:04 +0100 (BST) 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 <0KMC00509QA34O00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 01:30:03 -0700 (PDT) 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 <0KMC00GL3QA1S3A0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 01:30:02 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n668U1wg027580 for ; Mon, 06 Jul 2009 08:30:01 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMC00A00PAZKH00@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 09:30:01 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMC00F4DQ9V9890@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 09:29:56 +0100 (BST) Date: Mon, 06 Jul 2009 09:29:55 +0100 From: Darren J Moffat Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907031408.n63E8NPW005371@dm-holland-02.uk.sun.com> Sender: Darren.Moffat@sun.com To: Casper.Dik@sun.com Cc: PSARC-ext@sun.com Message-id: <4A51B603.4060406@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> <4A4E09D0.7000906@Sun.COM> <200907031408.n63E8NPW005371@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 682 Casper.Dik@Sun.COM wrote: > >> PSARC 2005/133 covers the introduction of per-user nscd. >> >> It is enabled by setting 'enable-per-user-lookup'. > > Are you expecting that exec_attr and such will fail when they are > attempted by root? I guess it is possible but unlikely. I was really just pointing out that for the case where 'enable-per-user-lookup' is set there will be a difference in the creds used to lookup the entries. I guess in theory there could be an 'intelligent' LDAP server that returns different exec_attr entries based on what the calling creds were. This case would break that. However I'm not sure if that is important or not. -- Darren J Moffat From casper@holland.sun.com Mon Jul 6 05:53:30 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n66CrThH029809 for ; Mon, 6 Jul 2009 05:53:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n66CrP7H003406 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Mon, 6 Jul 2009 20:53:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMD00N052H25300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 05:53:26 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMD009V32H1IUD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 05:53:25 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n66CrN5C008515; Mon, 06 Jul 2009 13:53:23 +0100 (BST) Date: Mon, 06 Jul 2009 14:53:23 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <20090705163833.GH15302@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <200907061253.n66CrN5C008515@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> <4A4E09D0.7000906@Sun.COM> <200907031408.n63E8NPW005371@dm-holland-02.uk.sun.com> <20090705112312.GA15302@Sun.COM> <200907051502.n65F244E061926@dm-holland-02.uk.sun.com> <20090705163833.GH15302@Sun.COM> Status: RO Content-Length: 810 >On Sun, Jul 05, 2009 at 05:02:04PM +0200, Casper.Dik@Sun.COM wrote: >> >Not so much exec_attr as getusernam(3C). >> >> And why would that fail? > >As root it might fail. The reason is that the directory might not want >to let host entities see user data, while allowing users to see it. >Enabling that was the point of self-credentialled name service lookups. > >In an environment that demands that pfexecd should fork helper processes >to do the name service lookups as the users that are exec()ing things. The current implementation uses the client's effective uid and group id. pfexec() always calls getusernam() with an effective uid of root. Both the current implementation and the proposed implementation will call nscd with the same effective uid and no change in behaviour will be seen. Casper From Darren.Moffat@sun.com Mon Jul 6 05:57:19 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 n66CvJoY000155 for ; Mon, 6 Jul 2009 05:57:19 -0700 (PDT) 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 n66CvHIb057536 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 6 Jul 2009 06:57:18 -0600 (MDT) 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 <0KMD00M0H2NH3T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 05:57:17 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMD00KPH2NGRN90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 05:57:17 -0700 (PDT) Received: from fe-emea-09.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 n66CvGHN026336 for ; Mon, 06 Jul 2009 12:57:16 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMD00G002HSZS00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 13:57:16 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMD00EOM2N25F80@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 06 Jul 2009 13:57:02 +0100 (BST) Date: Mon, 06 Jul 2009 13:57:02 +0100 From: Darren J Moffat Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907061253.n66CrN5C008515@dm-holland-02.uk.sun.com> Sender: Darren.Moffat@sun.com To: Casper.Dik@sun.com Cc: Nicolas Williams , PSARC-ext@sun.com Message-id: <4A51F49E.9070600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4A4E02B7.8080406@Sun.COM> <200907031312.n63DCx6Y052315@dm-holland-02.uk.sun.com> <4A4E09D0.7000906@Sun.COM> <200907031408.n63E8NPW005371@dm-holland-02.uk.sun.com> <20090705112312.GA15302@Sun.COM> <200907051502.n65F244E061926@dm-holland-02.uk.sun.com> <20090705163833.GH15302@Sun.COM> <200907061253.n66CrN5C008515@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 961 Casper.Dik@Sun.COM wrote: >> On Sun, Jul 05, 2009 at 05:02:04PM +0200, Casper.Dik@Sun.COM wrote: >>>> Not so much exec_attr as getusernam(3C). >>> And why would that fail? >> As root it might fail. The reason is that the directory might not want >> to let host entities see user data, while allowing users to see it. >> Enabling that was the point of self-credentialled name service lookups. >> >> In an environment that demands that pfexecd should fork helper processes >> to do the name service lookups as the users that are exec()ing things. > > The current implementation uses the client's effective uid and group id. > pfexec() always calls getusernam() with an effective uid of root. > > Both the current implementation and the proposed implementation will > call nscd with the same effective uid and no change in behaviour will > be seen. Great, so self-credentialled lookups don't change anything for this case. I'm happy now. -- Darren J Moffat From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Jul 7 09:13:18 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 n67GDHh0016973 for ; Tue, 7 Jul 2009 09:13:18 -0700 (PDT) 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 n67GD8Tf017338 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 7 Jul 2009 17:13:17 +0100 (BST) 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 <0KMF0015N6E2KB00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 09:13:14 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00C1H6DJ8Z50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 07 Jul 2009 09:12:55 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n67GAVAm005064 for ; Tue, 07 Jul 2009 16:12:54 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay41i.sun.com with ESMTP id BT-MMP-1884293 for PSARC-ext@sun.com; Tue, 07 Jul 2009 16:12:54 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-72057103 for PSARC-ext@sun.com; Tue, 07 Jul 2009 16:12:53 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay4i.sun.com with ESMTP id BT-MMP-10132935 for PSARC-ext@sun.com; Tue, 07 Jul 2009 16:12:53 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id D36639411F; Tue, 07 Jul 2009 18:12:51 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 44E94940B2; Tue, 07 Jul 2009 18:12:51 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n67GCpXY011255; Tue, 07 Jul 2009 18:12:51 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 07 Jul 2009 18:12:51 +0200 Date: Tue, 07 Jul 2009 18:12:50 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <4a537402.2LT8pks6BYYbTDVN%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 0.402sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 07 Jul 2009 16:12:51.0173 (UTC) FILETIME=[C6D4A950:01C9FF1D] Status: RO Content-Length: 2575 Casper Dik wrote: > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > In-kernel pfexec implementation. > 1.2. Name of Document Author/Supplier: > Author: Casper Dik > 1.3 Date of This Document: > 03 July, 2009 > 4. Technical Description > I'm sponsoring this fasttrack for myself. > > This project proposes an in-kernel implementation of the > pfexec(1) command. > > Release binding: minor. > > The implementation of pfexec(1) is changed such that is > add the PRIV_PFEXEC credential flag and then executes > the program. The execve() system call will notice the > PRIV_PFEXEC flag and it will ask the pfexecd daemon > whether the file can be executed and which changes to the > credential are required. Does this mean that the need for the existence of the /usr/bin/pfexec program will remain? OK, from readin below this seems to be true. ... or will there be a file system attribute that allows to create spfexec executable file behavior? > The pfexecd is started at boot through SMF as "svc:/system/pfexecd". > > Implementing pfexec in the kernel delivers the following advantages: > > > - pfshells come at no charge; this project will deliver > the following pf*sh*: > pfbash pfcsh pfksh pfksh93 pfsh pftcsh pfzsh > > A pf*sh* starts, sets the PRIV_PFEXEC flag and executes > the shell. Code which supports profile shells in current > shells will be removed. You mean the code that shifts the arg vector and that prepends /usr/bin/pfexec ? > /usr/bin/pfcsh [ options ] [ argument ]... > > + /usr/bin/pftcsh [ options ] [ argument ]... > + > /usr/bin/pfksh [ options ] [ argument ]... > > + /usr/bin/pfksh93 [ options ] [ argument ]... > + > + /usr/bin/pfbash [ options ] [ argument ]... > + > + /usr/bin/pfzsh [ options ] [ argument ]... > + Will there be the possibility to turn on/off this feature like while the shell is running like I did implement in "bsh" and "sh" in ftp://ftp.berlios.de/pub/schily/ set -P # Turn on profile mode set +P # Turn off profile mode set -o profile # Turn on profile mode set +o profile # Turn off profile mode Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From casper@holland.sun.com Tue Jul 7 09:23:03 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 n67GN3ql017227 for ; Tue, 7 Jul 2009 09:23:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n67GMuuQ028724 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 7 Jul 2009 09:23:03 -0700 (PDT) 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 <0KMF00K0Z6UCB600@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 10:23:00 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF009GZ6UBLLC0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 10:23:00 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n67GMvRS041163; Tue, 07 Jul 2009 17:22:57 +0100 (BST) Date: Tue, 07 Jul 2009 18:22:57 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <4a537402.2LT8pks6BYYbTDVN%Joerg.Schilling@fokus.fraunhofer.de> Sender: casper@holland.sun.com To: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Cc: PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <200907071622.n67GMvRS041163@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4a537402.2LT8pks6BYYbTDVN%Joerg.Schilling@fokus.fraunhofer.de> Status: RO Content-Length: 1803 >Does this mean that the need for the existence of the /usr/bin/pfexec program >will remain? OK, from readin below this seems to be true. Yes, that is correct. >... or will there be a file system attribute that allows to create spfexec >executable file behavior? No. (Note that exec_attrs belong to a profile, not the executable) > >> The pfexecd is started at boot through SMF as "svc:/system/pfexecd". >> >> Implementing pfexec in the kernel delivers the following advantages: >> >> >> - pfshells come at no charge; this project will deliver >> the following pf*sh*: >> pfbash pfcsh pfksh pfksh93 pfsh pftcsh pfzsh >> >> A pf*sh* starts, sets the PRIV_PFEXEC flag and executes >> the shell. Code which supports profile shells in current >> shells will be removed. > >You mean the code that shifts the arg vector and that prepends /usr/bin/pfexec ? Correct. >> /usr/bin/pfcsh [ options ] [ argument ]... >> >> + /usr/bin/pftcsh [ options ] [ argument ]... >> + >> /usr/bin/pfksh [ options ] [ argument ]... >> >> + /usr/bin/pfksh93 [ options ] [ argument ]... >> + >> + /usr/bin/pfbash [ options ] [ argument ]... >> + >> + /usr/bin/pfzsh [ options ] [ argument ]... >> + > >Will there be the possibility to turn on/off this feature like while the shell >is running like I did implement in "bsh" and "sh" in >ftp://ftp.berlios.de/pub/schily/ > >set -P # Turn on profile mode >set +P # Turn off profile mode > >set -o profile # Turn on profile mode >set +o profile # Turn off profile mode No; that use is wrong. A profile can be defined such that you can only run a few executables. Being able to disable the "profileness" of a shell is a bug because of that feature. I tried ksh93 and ksh and neither appears to support those. Casper From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Jul 7 09:26:23 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 n67GQNPP017318 for ; Tue, 7 Jul 2009 09:26:23 -0700 (PDT) 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 n67GQKKs022317 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 7 Jul 2009 10:26:23 -0600 (MDT) 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 <0KMF00H0R6ZWKH00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 09:26:20 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00A546ZT7XD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 09:26:18 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n67GHofu014342 for ; Tue, 07 Jul 2009 16:26:17 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-4005024 for psarc-ext@sun.com; Tue, 07 Jul 2009 16:26:13 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-143755704 for psarc-ext@sun.com; Tue, 07 Jul 2009 16:26:10 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay1i.sun.com with ESMTP id BT-MMP-24621488 for psarc-ext@sun.com; Tue, 07 Jul 2009 16:26:10 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 38950940B2; Tue, 07 Jul 2009 18:26:09 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 899BE940B2; Tue, 07 Jul 2009 18:26:08 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n67GQ8OI011572; Tue, 07 Jul 2009 18:26:08 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 07 Jul 2009 18:26:08 +0200 Date: Tue, 07 Jul 2009 18:26:08 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907071622.n67GMvRS041163@dm-holland-02.uk.sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Casper.Dik@sun.com Cc: PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <4a537720.yHPEr9tI5hvl007k%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 2.017sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4a537402.2LT8pks6BYYbTDVN%Joerg.Schilling@fokus.fraunhofer.de> <200907071622.n67GMvRS041163@dm-holland-02.uk.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 07 Jul 2009 16:26:08.0996 (UTC) FILETIME=[A25ECA40:01C9FF1F] Status: RO Content-Length: 989 Casper.Dik@sun.com wrote: > >Will there be the possibility to turn on/off this feature like while the shell > >is running like I did implement in "bsh" and "sh" in > >ftp://ftp.berlios.de/pub/schily/ > > > >set -P # Turn on profile mode > >set +P # Turn off profile mode > > > >set -o profile # Turn on profile mode > >set +o profile # Turn off profile mode > > > No; that use is wrong. A profile can be defined such that you can only > run a few executables. Being able to disable the "profileness" of a shell > is a bug because of that feature. If you call this a bug, when will the documentation (best practice) bug from Indiana be fixed that is based on manually calling pfexec? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From casper@holland.sun.com Tue Jul 7 10:17:25 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 n67HHPgX020151 for ; Tue, 7 Jul 2009 10:17:25 -0700 (PDT) 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 n67HHN2X001767 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 7 Jul 2009 10:17:25 -0700 (PDT) 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 <0KMF00D0H9CZ9P00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 10:17:23 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00CM19CX9ED0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 10:17:22 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n67HHJUO060697; Tue, 07 Jul 2009 18:17:19 +0100 (BST) Date: Tue, 07 Jul 2009 19:17:19 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <4a537720.yHPEr9tI5hvl007k%Joerg.Schilling@fokus.fraunhofer.de> Sender: casper@holland.sun.com To: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Cc: psarc-ext@sun.com Message-id: <200907071717.n67HHJUO060697@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4a537402.2LT8pks6BYYbTDVN%Joerg.Schilling@fokus.fraunhofer.de> <200907071622.n67GMvRS041163@dm-holland-02.uk.sun.com> <4a537720.yHPEr9tI5hvl007k%Joerg.Schilling@fokus.fraunhofer.de> Status: RO Content-Length: 307 >If you call this a bug, when will the documentation (best practice) bug from >Indiana be fixed that is based on manually calling pfexec? I don't see a relation between the two. I'm not responsible for abuse of pfexec; we could remove pfexec with this case but I have decided not to do that. Casper From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Jul 7 11:18:59 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 n67IIwoN022681 for ; Tue, 7 Jul 2009 11:18:59 -0700 (PDT) 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 n67IIqbL029160 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 7 Jul 2009 12:18:56 -0600 (MDT) 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 <0KMF0022RC7G2R00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 11:18:52 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00LGEC7FUX10@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 11:18:51 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n67I0OWj006026 for ; Tue, 07 Jul 2009 18:18:51 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-789215 for psarc-ext@sun.com; Tue, 07 Jul 2009 18:18:50 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-424821 for psarc-ext@sun.com; Tue, 07 Jul 2009 18:18:48 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay1i.sun.com with ESMTP id BT-MMP-9944466 for psarc-ext@sun.com; Tue, 07 Jul 2009 18:18:48 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id BC0F46F058C; Tue, 07 Jul 2009 20:18:47 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 7AAF16F0580; Tue, 07 Jul 2009 20:18:47 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n67IIk0M013466; Tue, 07 Jul 2009 20:18:47 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 07 Jul 2009 20:18:46 +0200 Date: Tue, 07 Jul 2009 20:18:46 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907071717.n67HHJUO060697@dm-holland-02.uk.sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Casper.Dik@sun.com Cc: psarc-ext@sun.com Message-id: <4a539186.TG3UkcN270CnOX/T%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 1.609sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4a537402.2LT8pks6BYYbTDVN%Joerg.Schilling@fokus.fraunhofer.de> <200907071622.n67GMvRS041163@dm-holland-02.uk.sun.com> <4a537720.yHPEr9tI5hvl007k%Joerg.Schilling@fokus.fraunhofer.de> <200907071717.n67HHJUO060697@dm-holland-02.uk.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 07 Jul 2009 18:18:46.0771 (UTC) FILETIME=[5E516C30:01C9FF2F] Status: RO Content-Length: 1151 Casper.Dik@sun.com wrote: > > > >If you call this a bug, when will the documentation (best practice) bug from > >Indiana be fixed that is based on manually calling pfexec? > > I don't see a relation between the two. I'm not responsible for abuse of > pfexec; we could remove pfexec with this case but I have decided not to do > that. Then let me try to start the discussion in a different way. If you believe that implementing a way to switch the pfexec state in a shell on/off while the shell is running, then the whole pfexec concept contains a bug. This may be very easy be verified: You can always call one of the /bin/pf*sh* and get the pfexec feature enabled and you could terminate this shell whenever you like. So implementing a way to switch on/off the pfexec feature in a running shell just does the same in a more convenient way. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Darren.Moffat@sun.com Tue Jul 7 11:33:23 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n67IXMxc023048 for ; Tue, 7 Jul 2009 11:33:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n67IXLn1010163 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 8 Jul 2009 02:33:21 +0800 (SGT) 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 <0KMF00B0ZCVJ7T00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 12:33:19 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF008K7CVIVHC0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 12:33:19 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n67IXIrO026500 for ; Tue, 07 Jul 2009 18:33:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMF00500CSP2200@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 19:33:18 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMF004SHCVHDE90@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 19:33:18 +0100 (BST) Date: Tue, 07 Jul 2009 19:33:14 +0100 From: Darren J Moffat Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <4a539186.TG3UkcN270CnOX/T%Joerg.Schilling@fokus.fraunhofer.de> Sender: Darren.Moffat@sun.com To: Joerg Schilling Cc: Casper.Dik@sun.com, psarc-ext@sun.com Message-id: <4A5394EA.8070406@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4a537402.2LT8pks6BYYbTDVN%Joerg.Schilling@fokus.fraunhofer.de> <200907071622.n67GMvRS041163@dm-holland-02.uk.sun.com> <4a537720.yHPEr9tI5hvl007k%Joerg.Schilling@fokus.fraunhofer.de> <200907071717.n67HHJUO060697@dm-holland-02.uk.sun.com> <4a539186.TG3UkcN270CnOX/T%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1029 Joerg Schilling wrote: > Casper.Dik@sun.com wrote: > >> >>> If you call this a bug, when will the documentation (best practice) bug from >>> Indiana be fixed that is based on manually calling pfexec? >> I don't see a relation between the two. I'm not responsible for abuse of >> pfexec; we could remove pfexec with this case but I have decided not to do >> that. > > Then let me try to start the discussion in a different way. > > If you believe that implementing a way to switch the pfexec state in a shell > on/off while the shell is running, then the whole pfexec concept contains a bug. > > This may be very easy be verified: > > You can always call one of the /bin/pf*sh* and get the pfexec feature enabled > and you could terminate this shell whenever you like. > > So implementing a way to switch on/off the pfexec feature in a running shell > just does the same in a more convenient way. Please take this discussion to security-discuss@opensolaris.org it is not relevant to this case. -- Darren J Moffat From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Jul 7 12:24:56 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 n67JOtT5026426 for ; Tue, 7 Jul 2009 12:24:56 -0700 (PDT) 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 n67JOoJh021721 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 7 Jul 2009 20:24:54 +0100 (BST) 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 <0KMF00E0VF9EYE00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 12:24:50 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMF00LX9F9EUV70@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 12:24:50 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n67JKGjE011549 for ; Tue, 07 Jul 2009 19:24:50 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-1905906 for psarc-ext@sun.com; Tue, 07 Jul 2009 19:24:49 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-72474804 for psarc-ext@sun.com; Tue, 07 Jul 2009 19:24:48 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay4i.sun.com with ESMTP id BT-MMP-10349883 for psarc-ext@sun.com; Tue, 07 Jul 2009 19:24:48 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 29B8E94180; Tue, 07 Jul 2009 21:24:47 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id A55DE940F8; Tue, 07 Jul 2009 21:24:46 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n67JOkMw014408; Tue, 07 Jul 2009 21:24:46 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 07 Jul 2009 21:24:46 +0200 Date: Tue, 07 Jul 2009 21:24:46 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <4A5394EA.8070406@Sun.COM> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Darren.Moffat@sun.com Cc: psarc-ext@sun.com, Casper.Dik@sun.com Message-id: <4a53a0fe.vkY3GWK1OHkb17J0%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.681sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4a537402.2LT8pks6BYYbTDVN%Joerg.Schilling@fokus.fraunhofer.de> <200907071622.n67GMvRS041163@dm-holland-02.uk.sun.com> <4a537720.yHPEr9tI5hvl007k%Joerg.Schilling@fokus.fraunhofer.de> <200907071717.n67HHJUO060697@dm-holland-02.uk.sun.com> <4a539186.TG3UkcN270CnOX/T%Joerg.Schilling@fokus.fraunhofer.de> <4A5394EA.8070406@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 07 Jul 2009 19:24:46.0679 (UTC) FILETIME=[969B6E70:01C9FF38] Status: RO Content-Length: 668 Darren J Moffat wrote: > > So implementing a way to switch on/off the pfexec feature in a running shell > > just does the same in a more convenient way. > > Please take this discussion to security-discuss@opensolaris.org it is > not relevant to this case. If you believe this, why didn't you tell it to Casper when he started this subthread? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Darren.Moffat@sun.com Tue Jul 7 12:34:16 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n67JYFnw026595 for ; Tue, 7 Jul 2009 12:34:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n67JY4rR013083 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 8 Jul 2009 03:34:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMF0060TFP0CW00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 12:34:12 -0700 (PDT) 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 <0KMF00IXUFOZBOB0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 12:34:12 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n67JYBEb029549 for ; Tue, 07 Jul 2009 19:34:11 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMF00I00FO3W500@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 20:34:10 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMF00413FOYDEA0@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 07 Jul 2009 20:34:10 +0100 (BST) Date: Tue, 07 Jul 2009 20:34:10 +0100 From: Darren J Moffat Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <4a53a0fe.vkY3GWK1OHkb17J0%Joerg.Schilling@fokus.fraunhofer.de> Sender: Darren.Moffat@sun.com To: Joerg Schilling Cc: psarc-ext@sun.com, Casper.Dik@sun.com Message-id: <4A53A332.9040706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> <4a537402.2LT8pks6BYYbTDVN%Joerg.Schilling@fokus.fraunhofer.de> <200907071622.n67GMvRS041163@dm-holland-02.uk.sun.com> <4a537720.yHPEr9tI5hvl007k%Joerg.Schilling@fokus.fraunhofer.de> <200907071717.n67HHJUO060697@dm-holland-02.uk.sun.com> <4a539186.TG3UkcN270CnOX/T%Joerg.Schilling@fokus.fraunhofer.de> <4A5394EA.8070406@Sun.COM> <4a53a0fe.vkY3GWK1OHkb17J0%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1012 Joerg Schilling wrote: > Darren J Moffat wrote: > >>> So implementing a way to switch on/off the pfexec feature in a running shell >>> just does the same in a more convenient way. >> Please take this discussion to security-discuss@opensolaris.org it is >> not relevant to this case. > > If you believe this, why didn't you tell it to Casper when he started this > subthread? I was giving the benefit of the doubt that it might be relevant to the case at hand given the discussion you and Casper have been having and the direction it appears to be going in I've now (not back then) determined I don't believe it relevant to the case under review. Just giving you both a little time to explore before asking that we stay on topic for the specific changes under review rather than branching out in the the greater topic. I'm happy to see the discussion but I don't want it to detract from the review of this case hence the suggestion to move it elsewhere. -- Darren J Moffat From gdamore@Sun.COM Thu Jul 9 14:53:24 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n69LrNwW006266 for ; Thu, 9 Jul 2009 14:53:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n69LrKpA020607 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 10 Jul 2009 05:53:22 +0800 (SGT) 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 <0KMJ00K0DBGXIV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 14:53:21 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMJ00FPDBGVUU20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 14:53:20 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n69LrJv7000025 for ; Thu, 09 Jul 2009 14:53:19 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMJ00400AU3JR00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 14:53:19 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMJ00LMFBGM5U60@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 14:53:10 -0700 (PDT) Date: Thu, 09 Jul 2009 14:53:10 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/377 In-kernel pfexec implementation Sender: Garrett.Damore@Sun.COM To: PSARC-ext Message-id: <4A5666C6.6010302@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 58 This case was approved at PSARC yesterday. - Garrett From casper@holland.sun.com Sat Jul 11 02:08:16 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n6B98FtJ005399 for ; Sat, 11 Jul 2009 02:08:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6B9897O001681 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 11 Jul 2009 17:08:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KMM00B0B1DOBG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 11 Jul 2009 02:08:12 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMM0070X1DOTI10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 11 Jul 2009 02:08:12 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6B98A7b062639; Sat, 11 Jul 2009 10:08:10 +0100 (BST) Date: Sat, 11 Jul 2009 11:08:10 +0200 From: Casper.Dik@sun.com Subject: Re: In-kernel pfexec implementation. [PSARC/2009/377 FastTrack timeout 07/10/2009] In-reply-to: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> Sender: casper@holland.sun.com To: Casper Dik Cc: PSARC-ext@sun.com Message-id: <200907110908.n6B98A7b062639@dm-holland-02.uk.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200907031243.n63Chc5a012793@sac.sfbay.sun.com> Status: RO Content-Length: 552 > >Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >This information is Copyright 2009 Sun Microsystems >1. Introduction > 1.1. Project/Component Working Name: > In-kernel pfexec implementation. > 1.2. Name of Document Author/Supplier: > Author: Casper Dik > 1.3 Date of This Document: > 03 July, 2009 >4. Technical Description >I'm sponsoring this fasttrack for myself. > >This project proposes an in-kernel implementation of the >pfexec(1) command. This case was approved during the psarc meeting on Wednesday 8th, 2009. Casper