From darrenm@sac.sfbay.sun.com Tue Jul 1 10:32:59 2008 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 m61HWwqn001174 for ; Tue, 1 Jul 2008 10:32:59 -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 m61HWs9g000349; Tue, 1 Jul 2008 18:32:58 +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 <0K3C00K038QWMH00@nwk-avmta-2.sfbay.sun.com>; Tue, 01 Jul 2008 10:32:56 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3C00IDV8QVET30@nwk-avmta-2.sfbay.sun.com>; Tue, 01 Jul 2008 10:32:55 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m61HWrlJ016521; Tue, 01 Jul 2008 10:32:53 -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 m61HWnp7001168; Tue, 01 Jul 2008 10:32:49 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m61HWnxs001164; Tue, 01 Jul 2008 10:32:49 -0700 (PDT) Date: Tue, 01 Jul 2008 10:32:49 -0700 (PDT) From: Darren J Moffat Subject: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] To: PSARC-ext@sun.com Cc: Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Message-id: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1855 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GNU screen 1.2. Name of Document Author/Supplier: Author: John Sonnenschein 1.3 Date of This Document: 01 July, 2008 4. Technical Description 4.1. Details: GNU screen is a terminal multiplexer application distributed by the GNU project which supports session persistence, detachment from the calling shell, session multiplexing ( multiple windows on a single terminal ), and session sharing The current version of screen is 4.0.2. 4.2. Interfaces: Exported Interfaces Interface Classification Comments ------------------------------------------------------------------------- SUNWscreen Uncommitted Package for binaries SUNWscreenrc Uncommitted Package configuration file /usr/bin/screen Uncommitted The screen binary /usr/share/lib/terminfo/s/screen Uncommitted The 'screen' terminfo file /etc/screenrc Uncommitted default configuration file In addition we will deliver a manual page in /usr/share/man section 1 Imported Interfaces Interface Classification Comments ------------------------------------------------------------------------- There's no imported interfaces worth mentioning. 4.3. Packaging & Delivery: SUNWscreen(base package) - base package for binaries SUNWscreenrc(configuration package) - package for configuration file 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gdamore@sun.com Tue Jul 1 11:07:58 2008 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 m61I7vJH002136 for ; Tue, 1 Jul 2008 11:07:58 -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 m61I7ofR016054 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 1 Jul 2008 19:07:56 +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 <0K3C00L05AD7YH00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 Jul 2008 11:07:55 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3C00I2CAD7ER50@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 Jul 2008 11:07:55 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m61I7t1j000978 for ; Tue, 01 Jul 2008 11:07:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3C00901A9EN400@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 Jul 2008 11:07:54 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3C004M3ACZG620@fe-sfbay-10.sun.com>; Tue, 01 Jul 2008 11:07:48 -0700 (PDT) Date: Tue, 01 Jul 2008 11:05:24 -0700 From: "Garrett D'Amore" Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: psarc-ext@sun.com, Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Message-id: <486A71E4.3000206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 3015 Screen uses a socket directory, the location of which is determined by an option. See http://www.delorie.com/gnu/docs/screen/screen_147.html for more information. How will the delivered version of screen be configured? My biggest worry here is that care is taken to ensure that the sockets used by screen are properly protected from any potential security weaknesses. I'd like to see the proposed default /etc/screenrc as well, since a number of other interesting settings can be set there, including a potential reference to an external locking program, etc. I think this is just a matter of completeness in the case materials, to ensure that all referenced files are documented appropriately so that there are no surprises. The following URLs are also informative, btw. http://www.delorie.com/gnu/docs/screen/screen_140.html http://www.delorie.com/gnu/docs/screen/screen_139.html All of those manuals are from a somewhat older version of screen, but I expect their contents are still very much germane. -- Garrett Darren J Moffat wrote: > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > GNU screen > 1.2. Name of Document Author/Supplier: > Author: John Sonnenschein > 1.3 Date of This Document: > 01 July, 2008 > 4. Technical Description > > 4.1. Details: > > GNU screen is a terminal multiplexer application distributed by the > GNU project which supports session persistence, detachment from the > calling shell, session multiplexing ( multiple windows on a single > terminal ), and session sharing > > The current version of screen is 4.0.2. > > 4.2. Interfaces: > > Exported Interfaces > Interface Classification Comments > ------------------------------------------------------------------------- > SUNWscreen Uncommitted Package for binaries > SUNWscreenrc Uncommitted Package configuration file > > /usr/bin/screen Uncommitted The screen binary > /usr/share/lib/terminfo/s/screen Uncommitted The 'screen' terminfo file > /etc/screenrc Uncommitted default configuration file > > In addition we will deliver a manual page in /usr/share/man section 1 > > Imported Interfaces > > Interface Classification Comments > ------------------------------------------------------------------------- > There's no imported interfaces worth mentioning. > > 4.3. Packaging & Delivery: > > SUNWscreen(base package) - base package for binaries > SUNWscreenrc(configuration package) - package for configuration file > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From Nicolas.Williams@sun.com Tue Jul 1 11:26:19 2008 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 m61IQIfo002419 for ; Tue, 1 Jul 2008 11:26:18 -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 m61IQF48006947; Tue, 1 Jul 2008 11:26:17 -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 <0K3C00F09B7SYO00@brm-avmta-1.central.sun.com>; Tue, 01 Jul 2008 12:26:16 -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 <0K3C00F9GB7RRN00@brm-avmta-1.central.sun.com>; Tue, 01 Jul 2008 12:26:16 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m61IQEeJ007450; Tue, 01 Jul 2008 13:26:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m61IQEir007449; Tue, 01 Jul 2008 13:26:14 -0500 (CDT) Date: Tue, 01 Jul 2008 13:26:14 -0500 From: Nicolas Williams Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> To: Darren J Moffat Cc: psarc-ext@sun.com, Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Mail-followup-to: Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Message-id: <20080701182613.GY2735@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: <200807011732.m61HWnxs001164@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: 3420 On Tue, Jul 01, 2008 at 10:32:49AM -0700, Darren J Moffat wrote: > Imported Interfaces > > Interface Classification Comments > ------------------------------------------------------------------------- > There's no imported interfaces worth mentioning. Privately I'm told screen would be built with --enable-pam. But that would imply that screen should be setuid-0 or to be executed with privileges via pfexec. That's because on Solaris PAM requires all [zone] privilege. screen built with --enable-pam uses PAM to authenticate users attaching to detached screen sessions. This is unnecessary, since file permissions are sufficient to ensure that the client attaching is authorized to attach. Besides being unnecessary it's also problematic (see above). Also, screen supports the use of crypted passwords in ~/.screenrc to provide for additional authentication where desired -- that clearly adds very little protection, since a process running with the same euid as screen and not lacking PRIV_PROC_SESSION could always trace/debug screen to allow the attach. But this is not objectionable. So I strongly urge the i-team to not enable PAM support in screen. Finally, I think we really need to know if screen will be setuid-0. The INSTALL file in the distribution says: | Consider this, when deciding whether you install screen setuid-root: | - On some machines root privileges are required to open pty's. Not on Solaris. | - Pty's should be owned by the user, so that she can do chmod to prevent | intruder attacks. The PTYs used by screen will remain world read-writable | if screen is not installed setuid-root. grantpt(3C) ensures that ptys are owned by the user. I see screen knows to use grantpt(3C). | - Some commands only work properly when the pty is owned by the user. | These include mesg and biff. N/A (see above). | - The ^At feature may need to lseek and read the kernel file to retrieve | the load average. Wouldn't work on zones. I've not looked at whether screen knows better ways to do this now, but I really don't mind if this doesn't work. | - On most machines utmp slots can only be created/manipulated with root | privileges. Users will appear to be logged on the primary terminal | instead of the screen windows, if screen is not installed setuid-root. I'm not sure what the deal is with this in Solaris. But I also don't care if I can't use w(1) to see what I'm doing in each screen window. | - Multi-user screen sessions are only allowed when screen has a | root-s-bit. I'm not sure why that would be true, but, I don't mind this either. For this we could always have an RBAC profile if this feature really must be there and if it can only be implemented by giving screen privileges (which ones?). | - If screen sockets of multiple users are kept in one directory (e.g. | /tmp/screens), this directory must be world writable when screen is not | installed setuid-root. Any user can remove or abuse any socket then. On my system screen (from the Solaris CCD) keeps its sockets in /tmp/uscreens/S-$USER/. This strikes me as wrong (/tmp/uscreens is owned by the user running the first instance of screen to run since boot, and it's 777, no sticky bit set). screen should use /tmp/S-$USER, or better, $TMPDIR/S-$USER, which leaves the problem of creating a suitable directory to the login system. Nico -- From johnsonnenschein@gmail.com Tue Jul 1 11:26:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m61IQiLf002489 for ; Tue, 1 Jul 2008 11:26:44 -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 m61IQfH1027837 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 2 Jul 2008 02:26:43 +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 <0K3C00F03B8HZT00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 Jul 2008 12:26:41 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3C00F90B8HRR00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 Jul 2008 12:26:41 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m61IPZW9003908 for ; Tue, 01 Jul 2008 18:26:40 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-613811 for psarc-ext@sun.com; Tue, 01 Jul 2008 18:26:40 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-276563 for psarc-ext@sun.com; Tue, 01 Jul 2008 18:26:38 +0000 (Z) Received: from yx-out-1718.google.com ([74.125.44.157] [74.125.44.157]) by relay1ib.sun.com with ESMTP id BT-MMP-456872 for psarc-ext@sun.com; Tue, 01 Jul 2008 18:26:38 +0000 (Z) Received: by yx-out-1718.google.com with SMTP id 6so3007yxn.68 for ; Tue, 01 Jul 2008 11:26:36 -0700 (PDT) Received: by 10.114.77.1 with SMTP id z1mr6119235waa.8.1214936795429; Tue, 01 Jul 2008 11:26:35 -0700 (PDT) Received: from ?192.168.1.104? ( [76.10.188.43]) by mx.google.com with ESMTPS id z20sm1787519pod.11.2008.07.01.11.26.34 (version=TLSv1/SSLv3 cipher=RC4-MD5) ; Tue, 01 Jul 2008 11:26:35 -0700 (PDT) Date: Tue, 01 Jul 2008 11:26:32 -0700 From: John Sonnenschein Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <486A71E4.3000206@sun.com> To: "Garrett D'Amore" Cc: Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, storycrafter@gmail.com Message-id: <712DB8BC-44F0-4206-9E99-CE57DF2CB583@gmail.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.924) Content-type: multipart/alternative; boundary="Boundary_(ID_7Nf+E95Oq2RqOUD4jLTBSw)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=FmED+Evp4UygCENueQ/ZyRVrPLOnyPmYJnbFNdjkITU=; b=DTdwsw22Ec5j2en/4Vw/ool44ZUWz55AwSkEJRxyDKnZQoS0tu4CJCcfksBxRfjR/l oopkVicyQguPcKNlKyBBy5DMdnhEGdvGNXoaq2+j2+hZoZmaZ8q5Fs0ufMC4xow1eTZo Te5sHR/I4F6btGibH4kkdWKsoyq8HNfmJ1awY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=GOudV/OzKm4p+Vg2ej4PZbrIbuAQea5DDVG6l4jly3RIFm0hVhSqNC0JzVNqB5Sef0 uqxKb74LTrNTUWKzTSSAoE5YfLMbtqYYIGzra4N777ZNTuEnnWGVhaf5P9EYwh/n8TUp GO3fV+wV77MGqwk2PcUtDJo1S5/IsOekfrc6M= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=1.8/5.0, scanned in 1.123sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> <486A71E4.3000206@sun.com> Status: RO Content-Length: 12515 --Boundary_(ID_7Nf+E95Oq2RqOUD4jLTBSw) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT On 1-Jul-08, at 11:05 AM, Garrett D'Amore wrote: > Screen uses a socket directory, the location of which is determined > by an option. See http://www.delorie.com/gnu/docs/screen/screen_147.html > for more information. > > How will the delivered version of screen be configured? My biggest > worry here is that care is taken to ensure that the sockets used by > screen are properly protected from any potential security weaknesses. > The location of the socket directory in this case is per-user, stored in /tmp/screens/S- with permissions set to 700 and owner:group being the owner:group of the calling user > I'd like to see the proposed default /etc/screenrc as well, since a > number of other interesting settings can be set there, including a > potential reference to an external locking program, etc. I think > this is just a matter of completeness in the case materials, to > ensure that all referenced files are documented appropriately so > that there are no surprises. > sure, it's available at http://cr.opensolaris.org/~error404/etcscreenrc > The following URLs are also informative, btw. > > http://www.delorie.com/gnu/docs/screen/screen_140.html > http://www.delorie.com/gnu/docs/screen/screen_139.html > > All of those manuals are from a somewhat older version of screen, > but I expect their contents are still very much germane. > > -- Garrett > On a different note, I am also told I need to inform ARC that screen is to be built with pam support enabled, such that users locking screens can utilize their regular UNIX authentication method to unlock it. This is my fault and a result of inexperience. I apologize. > Darren J Moffat wrote: >> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> GNU screen >> 1.2. Name of Document Author/Supplier: >> Author: John Sonnenschein >> 1.3 Date of This Document: >> 01 July, 2008 >> 4. Technical Description >> >> 4.1. Details: >> >> GNU screen is a terminal multiplexer application distributed by the >> GNU project which supports session persistence, detachment from the >> calling shell, session multiplexing ( multiple windows on a single >> terminal ), and session sharing >> >> The current version of screen is 4.0.2. >> >> 4.2. Interfaces: >> >> Exported Interfaces >> Interface Classification Comments >> >> ------------------------------------------------------------------------- >> SUNWscreen Uncommitted Package for >> binaries >> SUNWscreenrc Uncommitted Package >> configuration file >> >> /usr/bin/screen Uncommitted The screen binary >> /usr/share/lib/terminfo/s/screen Uncommitted The 'screen' >> terminfo file >> /etc/screenrc Uncommitted default >> configuration file >> >> In addition we will deliver a manual page in /usr/share/man >> section 1 >> >> Imported Interfaces >> >> Interface Classification Comments >> >> ------------------------------------------------------------------------- >> There's no imported interfaces worth mentioning. >> >> 4.3. Packaging & Delivery: >> >> SUNWscreen(base package) - base package for >> binaries >> SUNWscreenrc(configuration package) - package for >> configuration file >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> SFW >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> > --Boundary_(ID_7Nf+E95Oq2RqOUD4jLTBSw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: quoted-printable
On 1-Jul-08, at = 11:05 AM, Garrett D'Amore wrote:

Screen = uses a socket directory, the location of which is determined by an = option.   See http://www= .delorie.com/gnu/docs/screen/screen_147.html for more = information.

How = will the delivered version of screen be configured?  My biggest = worry here is that care is taken to ensure that the sockets used by = screen are properly protected from any potential security = weaknesses.


The location of the = socket directory in this case is per-user, stored in = /tmp/screens/S-<username> with permissions set to 700 and owner:group = being the owner:group of the calling user

I'd like to see the proposed default /etc/screenrc as = well, since a number of other interesting settings can be set there, = including a potential reference to an external locking program, etc. =  I think this is just a matter of completeness in the case = materials, to ensure that all referenced files are documented = appropriately so that there are no = surprises.




The following URLs are also informative, = btw.

http://www= .delorie.com/gnu/docs/screen/screen_140.html
http://www= .delorie.com/gnu/docs/screen/screen_139.html

All of those = manuals are from a somewhat older version of screen, but I expect their = contents are still very much germane.

  -- = Garrett


On a different = note, I am also told I need to inform ARC that screen is to be built = with pam support enabled, such that users locking screens can utilize = their regular UNIX authentication method to unlock it. This is my fault = and a result of inexperience. I = apologize.



Darren J Moffat wrote:
Template Version: @(#)sac_nextcase 1.66 04/17/08 = SMI
This information is = Copyright 2008 Sun Microsystems
1. Introduction
=    1.1. Project/Component Working = Name:
GNU = screen
   1.2. = Name of Document Author/Supplier:
= Author:  John Sonnenschein
   1.3  Date of This = Document:
01 July, = 2008
4. Technical = Description

 4.1. = Details:

=   GNU screen is a terminal multiplexer application distributed = by the
  GNU = project which supports session persistence, detachment from = the
  calling = shell, session multiplexing ( multiple windows on a = single
  terminal = ),  and session sharing

=   The current version of screen is = 4.0.2.

4.2. = Interfaces:

Exported = Interfaces
=   Interface =             &n= bsp;          Classifica= tion      Comments
=   --------------------------------------------------------------= -----------
=   SUNWscreen =             &n= bsp;         Uncommitted =     Package for binaries
  SUNWscreenrc =             &n= bsp;       Uncommitted =     Package configuration = file

=   /usr/bin/screen =             &n= bsp;    Uncommitted     The = screen binary
=   /usr/share/lib/terminfo/s/screen Uncommitted =     The 'screen' terminfo = file
=   /etc/screenrc =             &n= bsp;      Uncommitted =     default configuration = file

  In = addition we will deliver a manual page in /usr/share/man section = 1

  Imported = Interfaces

=   Interface =             &n= bsp;           Clas= sification     Comments
=   --------------------------------------------------------------= -----------
=   There's no imported interfaces worth = mentioning.

4.3. Packaging = & Delivery:

=   SUNWscreen(base package) =             &n= bsp;    - base package for = binaries
=   SUNWscreenrc(configuration package) =       - package for configuration file =
6. Resources and = Schedule
=    6.4. Steering Committee requested = information
   6.4.1. = Consolidation C-team Name:
= SFW
=    6.5. ARC review type: = FastTrack
=    6.6. ARC Exposure: open

=  


= --Boundary_(ID_7Nf+E95Oq2RqOUD4jLTBSw)-- From Nicolas.Williams@sun.com Tue Jul 1 11:48:24 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m61ImNf1003213 for ; Tue, 1 Jul 2008 11:48: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 m61ImCek005303; Wed, 2 Jul 2008 02:48:21 +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 <0K3C0000RC8IHA00@nwk-avmta-2.sfbay.sun.com>; Tue, 01 Jul 2008 11:48:18 -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 <0K3C00I4EC8GEG70@nwk-avmta-2.sfbay.sun.com>; Tue, 01 Jul 2008 11:48:17 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m61ImFuR007545; Tue, 01 Jul 2008 13:48:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m61ImFHj007544; Tue, 01 Jul 2008 13:48:15 -0500 (CDT) Date: Tue, 01 Jul 2008 13:48:15 -0500 From: Nicolas Williams Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <20080701182613.GY2735@Sun.COM> To: Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Mail-followup-to: Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@Sun.COM, johnsonnenschein@gmail.com, storycrafter@gmail.com Message-id: <20080701184814.GA2735@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: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> <20080701182613.GY2735@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: 754 On Tue, Jul 01, 2008 at 01:26:14PM -0500, Nicolas Williams wrote: > | - If screen sockets of multiple users are kept in one directory (e.g. > | /tmp/screens), this directory must be world writable when screen is not > | installed setuid-root. Any user can remove or abuse any socket then. > > On my system screen (from the Solaris CCD) keeps its sockets in > /tmp/uscreens/S-$USER/. FWIW, the screen delivered by the Solaris CCD: - is not setuid/setgid - does not use PAM - it gets the load averages just fine, even though it's not setuid Provided that you disable PAM support in screen and ship it not setuid/setgid, then the only security issue relates to the path where screen puts its sockets (see my previous post about that). Nico -- From johnsonnenschein@gmail.com Tue Jul 1 11:49:49 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m61InmV7003317 for ; Tue, 1 Jul 2008 11:49:49 -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 m61IncJF005949 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 2 Jul 2008 02:49:48 +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 <0K3C00003CAZIQ00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 Jul 2008 11:49:47 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3C00IGRCAYEO70@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 01 Jul 2008 11:49:46 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m61IloJj017296 for ; Tue, 01 Jul 2008 18:49:46 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay43i.sun.com with ESMTP id BT-MMP-254314 for psarc-ext@sun.com; Tue, 01 Jul 2008 18:49:46 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-60238465 for psarc-ext@sun.com; Tue, 01 Jul 2008 18:49:45 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.179] [209.85.146.179]) by relay4i.sun.com with ESMTP id BT-MMP-7598377 for psarc-ext@sun.com; Tue, 01 Jul 2008 18:49:45 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id j37so11174waf.22 for ; Tue, 01 Jul 2008 11:49:05 -0700 (PDT) Received: by 10.114.241.15 with SMTP id o15mr6089262wah.164.1214938145415; Tue, 01 Jul 2008 11:49:05 -0700 (PDT) Received: from ?192.168.1.104? ( [76.10.188.43]) by mx.google.com with ESMTPS id z15sm1947416pod.2.2008.07.01.11.49.03 (version=TLSv1/SSLv3 cipher=RC4-MD5) ; Tue, 01 Jul 2008 11:49:04 -0700 (PDT) Date: Tue, 01 Jul 2008 11:49:02 -0700 From: John Sonnenschein Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <20080701182613.GY2735@Sun.COM> To: Nicolas Williams Cc: Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, storycrafter@gmail.com Message-id: <1447947E-190A-411F-BA5F-C9D5CFE64058@gmail.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.924) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=IJf9V/DU4cmM9q+6ALrl4PvNIWuFY7/H+9t8oCMd1dE=; b=O3fOWunt5tVkG+Nh88EHRPdLDgW6JymD/NNqnBV/VdqUHFM+uSVchM5woHkcfehFgm pvX/v/gl+B+5ioymlc+o+xfwsCI8/rnprrKRvuFlLbqxWWkmJ0vk1q35Sm++y1N4HcuT QHtfQWiT0gk0/p4t3rYsUNi9z7eVNZJvNCP6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=F3Ro9TJtFw0DB5W/nm1xlzztBsfWXycDDungUOck6/pTMjjBL9Fzl+7EizNMdR0c0Y cBXEiitiYNhnoZ/9qYTnzYzTKmYVqsI1ZqVtqWiKiQWRPVwFttsm4A0h5CoICOX3AtBL I9puztW7ddIjz9kc4t5RqNjKFysOnt4E0e5q8= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.094sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> <20080701182613.GY2735@Sun.COM> Status: RO Content-Length: 3964 Fair enough so for this case it shall be built without --enable-pam, and users are responsible for their own passwords through ~/.screenrc . We may wish to revisit this decision in the future when a better analysis of security best-practice with respect to screen can be done On 1-Jul-08, at 11:26 AM, Nicolas Williams wrote: > On Tue, Jul 01, 2008 at 10:32:49AM -0700, Darren J Moffat wrote: >> Imported Interfaces >> >> Interface Classification Comments >> >> ------------------------------------------------------------------------- >> There's no imported interfaces worth mentioning. > > Privately I'm told screen would be built with --enable-pam. But that > would imply that screen should be setuid-0 or to be executed with > privileges via pfexec. That's because on Solaris PAM requires all > [zone] privilege. > > screen built with --enable-pam uses PAM to authenticate users > attaching > to detached screen sessions. This is unnecessary, since file > permissions are sufficient to ensure that the client attaching is > authorized to attach. Besides being unnecessary it's also problematic > (see above). > > Also, screen supports the use of crypted passwords in ~/.screenrc to > provide for additional authentication where desired -- that clearly > adds > very little protection, since a process running with the same euid as > screen and not lacking PRIV_PROC_SESSION could always trace/debug > screen > to allow the attach. But this is not objectionable. > > So I strongly urge the i-team to not enable PAM support in screen. > > Finally, I think we really need to know if screen will be setuid-0. > The > INSTALL file in the distribution says: > > | Consider this, when deciding whether you install screen setuid-root: > | - On some machines root privileges are required to open pty's. > > Not on Solaris. > > | - Pty's should be owned by the user, so that she can do chmod to > prevent > | intruder attacks. The PTYs used by screen will remain world read- > writable > | if screen is not installed setuid-root. > > grantpt(3C) ensures that ptys are owned by the user. I see screen > knows > to use grantpt(3C). > > | - Some commands only work properly when the pty is owned by the > user. > | These include mesg and biff. > > N/A (see above). > > | - The ^At feature may need to lseek and read the kernel file to > retrieve > | the load average. > > Wouldn't work on zones. I've not looked at whether screen knows > better > ways to do this now, but I really don't mind if this doesn't work. > > | - On most machines utmp slots can only be created/manipulated with > root > | privileges. Users will appear to be logged on the primary terminal > | instead of the screen windows, if screen is not installed setuid- > root. > > I'm not sure what the deal is with this in Solaris. But I also don't > care if I can't use w(1) to see what I'm doing in each screen window. > > | - Multi-user screen sessions are only allowed when screen has a > | root-s-bit. > > I'm not sure why that would be true, but, I don't mind this either. > > For this we could always have an RBAC profile if this feature really > must be there and if it can only be implemented by giving screen > privileges (which ones?). > > | - If screen sockets of multiple users are kept in one directory > (e.g. > | /tmp/screens), this directory must be world writable when screen > is not > | installed setuid-root. Any user can remove or abuse any socket > then. > > On my system screen (from the Solaris CCD) keeps its sockets in > /tmp/uscreens/S-$USER/. > > This strikes me as wrong (/tmp/uscreens is owned by the user running > the > first instance of screen to run since boot, and it's 777, no sticky > bit > set). > > screen should use /tmp/S-$USER, or better, $TMPDIR/S-$USER, which > leaves > the problem of creating a suitable directory to the login system. > > Nico > -- From Brian.Ruthven@Sun.COM Wed Jul 2 02:59:32 2008 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 m629xWj4001346 for ; Wed, 2 Jul 2008 02:59:32 -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 m629xVfa012645 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 2 Jul 2008 03:59:32 -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 <0K3D00705IF6OB00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 02:59:30 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3D005VPIF4XB00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 02:59:29 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m629xSfr025598 for ; Wed, 02 Jul 2008 09:59:28 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3D00501I79BZ00@fe-emea-09.sun.com> (original mail from Brian.Ruthven@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 10:59:28 +0100 (BST) Received: from [129.156.173.239] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3D0047OIF0ZJ20@fe-emea-09.sun.com>; Wed, 02 Jul 2008 10:59:24 +0100 (BST) Date: Wed, 02 Jul 2008 10:59:03 +0100 From: Brian Ruthven - Sun UK Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <20080701184814.GA2735@Sun.COM> Sender: Brian.Ruthven@Sun.COM To: Darren J Moffat , psarc-ext@Sun.COM, Petr.Sumbera@Sun.COM, johnsonnenschein@gmail.com, storycrafter@gmail.com Message-id: <486B5167.3020007@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_IDSVa30SQXDdVBkD/+Lryg)" X-PMX-Version: 5.4.1.325704 References: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> <20080701182613.GY2735@Sun.COM> <20080701184814.GA2735@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20071119) Status: RO Content-Length: 5158 This is a multi-part message in MIME format. --Boundary_(ID_IDSVa30SQXDdVBkD/+Lryg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT [ Please forgive my intrusion - if it's not my place to comment on this, please reply to me directly rather than polluting the PSARC mail log with education hints for me :-) ] I am using the setuid-installed screen 4.0.2, and if a regular user can create something called /tmp/screens before the first invocation of screen, then screen complains (probably quite correctly) with something like "Directory '/tmp/screens' must be owned by root." or "'/tmp/screens' must be a directory." However, this seems like a very simple DoS attack to me. It's obvious what the problem is (thankfully, the error messages are meaningful), but still requires manual intervention to fix the problem. What steps could be taken to prevent this? (if it is even worth preventing in the first place) I'll offer the following for consideration: Could the socket dir be located under, e.g. /var/run instead? I hesitantly also suggest a new tmpfs filesystem, something like /var/screens. The solution of Solaris creating the directory every bootup seems like a bit of a hack to me, but I'll mention it anyway :-) Brian Nicolas Williams wrote: > On Tue, Jul 01, 2008 at 01:26:14PM -0500, Nicolas Williams wrote: > >> | - If screen sockets of multiple users are kept in one directory (e.g. >> | /tmp/screens), this directory must be world writable when screen is not >> | installed setuid-root. Any user can remove or abuse any socket then. >> >> On my system screen (from the Solaris CCD) keeps its sockets in >> /tmp/uscreens/S-$USER/. >> > > FWIW, the screen delivered by the Solaris CCD: > > - is not setuid/setgid > - does not use PAM > - it gets the load averages just fine, even though it's not setuid > > Provided that you disable PAM support in screen and ship it not > setuid/setgid, then the only security issue relates to the path where > screen puts its sockets (see my previous post about that). > > Nico > -- Brian Ruthven Sun Microsystems UK Solaris Revenue Product Engineering Tel: +44 (0)1252 422 312 Sparc House, Guillemont Park, Camberley, GU17 9QG --Boundary_(ID_IDSVa30SQXDdVBkD/+Lryg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT [  Please forgive my intrusion - if it's not my place to comment on this, please reply to me directly rather than polluting the PSARC mail log with education hints for me :-)  ]

I am using the setuid-installed screen 4.0.2, and if a regular user can create something called /tmp/screens before the first invocation of screen, then screen complains (probably quite correctly) with something like "Directory '/tmp/screens' must be owned by root." or "'/tmp/screens' must be a directory."

However, this seems like a very simple DoS attack to me. It's obvious what the problem is (thankfully, the error messages are meaningful), but still requires manual intervention to fix the problem. What steps could be taken to prevent this? (if it is even worth preventing in the first place)

I'll offer the following for consideration:
    Could the socket dir be located under, e.g. /var/run instead?
    I hesitantly also suggest a new tmpfs filesystem, something like /var/screens.
    The solution of Solaris creating the directory every bootup seems like a bit of a hack to me, but I'll mention it anyway :-)

Brian


Nicolas Williams wrote: 
On Tue, Jul 01, 2008 at 01:26:14PM -0500, Nicolas Williams wrote:
  
| - If screen sockets of multiple users are kept in one directory (e.g. 
|   /tmp/screens), this directory must be world writable when screen is not
|   installed setuid-root. Any user can remove or abuse any socket then.

On my system screen (from the Solaris CCD) keeps its sockets in
/tmp/uscreens/S-$USER/.
    

FWIW, the screen delivered by the Solaris CCD:

 - is not setuid/setgid
 - does not use PAM
 - it gets the load averages just fine, even though it's not setuid

Provided that you disable PAM support in screen and ship it not
setuid/setgid, then the only security issue relates to the path where
screen puts its sockets (see my previous post about that).

Nico
  

-- 
Brian Ruthven                                        Sun Microsystems UK
Solaris Revenue Product Engineering             Tel: +44 (0)1252 422 312
Sparc House, Guillemont Park, Camberley, GU17 9QG
--Boundary_(ID_IDSVa30SQXDdVBkD/+Lryg)-- From johnsonnenschein@gmail.com Wed Jul 2 09:14:19 2008 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 m62GEIXP011204 for ; Wed, 2 Jul 2008 09:14:19 -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 m62GEBbN019631 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 2 Jul 2008 17:14:17 +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 <0K3D0020HZRQJZ00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 10:14:14 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3D00J90ZRQ4870@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 10:14:14 -0600 (MDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m62GEDb4013157 for ; Wed, 02 Jul 2008 16:14:13 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay12i.sun.com with ESMTP id BT-MMP-678856 for psarc-ext@sun.com; Wed, 02 Jul 2008 16:14:13 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-89556 for psarc-ext@sun.com; Wed, 02 Jul 2008 16:14:13 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.183] [209.85.146.183]) by relay1ib.sun.com with ESMTP id BT-MMP-7567245 for psarc-ext@sun.com; Wed, 02 Jul 2008 16:14:13 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id j37so264865waf.22 for ; Wed, 02 Jul 2008 09:14:07 -0700 (PDT) Received: by 10.114.202.15 with SMTP id z15mr7176772waf.88.1215015247687; Wed, 02 Jul 2008 09:14:07 -0700 (PDT) Received: from ?192.168.1.104? ( [76.10.188.43]) by mx.google.com with ESMTPS id q18sm3781486pog.13.2008.07.02.09.14.06 (version=TLSv1/SSLv3 cipher=RC4-MD5) ; Wed, 02 Jul 2008 09:14:06 -0700 (PDT) Date: Wed, 02 Jul 2008 09:14:05 -0700 From: John Sonnenschein Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <486B5167.3020007@sun.com> To: Brian Ruthven - Sun UK Cc: Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, storycrafter@gmail.com Message-id: <2B41523B-63FD-4B97-BD0F-D915F740BCB6@gmail.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.926) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=rGeqlS51ZvoV7SX43kLKNky3U9qRaqeT5uAXIA05htY=; b=GKWhijwSKk5JgbdEBjAbwwW95uflAF212ELnAM1+Zb1f+zKncObQm78j6Tpw/EeY5w XAzh81iqEyWs9Vxb+OzUIcNMWyFHiuzA/r18YlneEcen64Pc93u/kKG6+nu/GbIdCG+l ZfxaNTF5RFwZS6H+Av+T34lzhbfh3CIz1pS3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=NxU1+9ipcjxrZFkgxhS2+jv3xN+0HzmTKj3VLQURsTxbRA16s6COVMi0t8RC0O7Pxd dgH5lS82RzKFQevSTorcsZU9/Fpy8gR5+bdAtgeseMuzO9c3R/SuoCAbm3xZkV0/PnEc cWwx5mKo2F+F9i73592G5SPBq5J/XPl6joFko= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.076sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> <20080701182613.GY2735@Sun.COM> <20080701184814.GA2735@Sun.COM> <486B5167.3020007@sun.com> Status: RO Content-Length: 2536 Considering all you've mentioned, I think the best and least hack-ish solution might be to deliver with --disable-socket-dir , which ( true to it's name ) disables the system socket dir, using the user's ~/.screen instead On 2-Jul-08, at 2:59 AM, Brian Ruthven - Sun UK wrote: > [ Please forgive my intrusion - if it's not my place to comment on > this, please reply to me directly rather than polluting the PSARC > mail log with education hints for me :-) ] > > I am using the setuid-installed screen 4.0.2, and if a regular user > can create something called /tmp/screens before the first invocation > of screen, then screen complains (probably quite correctly) with > something like "Directory '/tmp/screens' must be owned by root." or > "'/tmp/screens' must be a directory." > > However, this seems like a very simple DoS attack to me. It's > obvious what the problem is (thankfully, the error messages are > meaningful), but still requires manual intervention to fix the > problem. What steps could be taken to prevent this? (if it is even > worth preventing in the first place) > > I'll offer the following for consideration: > Could the socket dir be located under, e.g. /var/run instead? > I hesitantly also suggest a new tmpfs filesystem, something > like /var/screens. > The solution of Solaris creating the directory every bootup > seems like a bit of a hack to me, but I'll mention it anyway :-) > > Brian > > > Nicolas Williams wrote: >> >> On Tue, Jul 01, 2008 at 01:26:14PM -0500, Nicolas Williams wrote: >> >>> | - If screen sockets of multiple users are kept in one directory >>> (e.g. >>> | /tmp/screens), this directory must be world writable when >>> screen is not >>> | installed setuid-root. Any user can remove or abuse any socket >>> then. >>> >>> On my system screen (from the Solaris CCD) keeps its sockets in >>> /tmp/uscreens/S-$USER/. >>> >> FWIW, the screen delivered by the Solaris CCD: >> >> - is not setuid/setgid >> - does not use PAM >> - it gets the load averages just fine, even though it's not setuid >> >> Provided that you disable PAM support in screen and ship it not >> setuid/setgid, then the only security issue relates to the path where >> screen puts its sockets (see my previous post about that). >> >> Nico >> > > -- > Brian Ruthven Sun > Microsystems UK > Solaris Revenue Product Engineering Tel: +44 (0)1252 422 > 312 > Sparc House, Guillemont Park, Camberley, GU17 9QG From Nicolas.Williams@sun.com Wed Jul 2 09:35:23 2008 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 m62GZMeD012184 for ; Wed, 2 Jul 2008 09:35:23 -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 m62GZIiu028172; Wed, 2 Jul 2008 09:35:19 -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 <0K3E0030B0QU7H00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 02 Jul 2008 09:35:18 -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 <0K3E00HQQ0QTSU40@nwk-avmta-1.sfbay.Sun.COM>; Wed, 02 Jul 2008 09:35:17 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m62GZFw7008881; Wed, 02 Jul 2008 11:35:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m62GZFTG008880; Wed, 02 Jul 2008 11:35:15 -0500 (CDT) Date: Wed, 02 Jul 2008 11:35:15 -0500 From: Nicolas Williams Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <486B5167.3020007@sun.com> To: Brian Ruthven - Sun UK Cc: Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Mail-followup-to: Brian Ruthven - Sun UK , Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Message-id: <20080702163515.GR2735@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: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> <20080701182613.GY2735@Sun.COM> <20080701184814.GA2735@Sun.COM> <486B5167.3020007@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: 1196 On Wed, Jul 02, 2008 at 10:59:03AM +0100, Brian Ruthven - Sun UK wrote: > However, this seems like a very simple DoS attack to me. It's obvious > what the problem is (thankfully, the error messages are meaningful), but > still requires manual intervention to fix the problem. What steps could > be taken to prevent this? (if it is even worth preventing in the first > place) We have this attack for lots of other things, sadly. > I'll offer the following for consideration: > Could the socket dir be located under, e.g. /var/run instead? > I hesitantly also suggest a new tmpfs filesystem, something like > /var/screens. > The solution of Solaris creating the directory every bootup seems > like a bit of a hack to me, but I'll mention it anyway :-) IMO the correct solution is for a PAM module (pam_unix_session) to mktemp a user's TMPDIR the first time the user logs in since boot. The module should record this TMPDIR so that the user gets the same TMPDIR on subsequent logins whenever possible (e.g., whenever the TMPDIR is still owned by the user). The module should set that environment variable. And then screen could use $TMPDIR/screens as the socket dir. Nico -- From Nicolas.Williams@sun.com Wed Jul 2 09:36:49 2008 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 m62GamHa012353 for ; Wed, 2 Jul 2008 09:36:49 -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 m62GagZq000762; Wed, 2 Jul 2008 17:36:47 +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 <0K3E00D0F0TA0E00@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Jul 2008 09:36:46 -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 <0K3E00BVC0T92U90@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Jul 2008 09:36:45 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m62GahjV008888; Wed, 02 Jul 2008 11:36:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m62GahAp008887; Wed, 02 Jul 2008 11:36:43 -0500 (CDT) Date: Wed, 02 Jul 2008 11:36:43 -0500 From: Nicolas Williams Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <20080702163515.GR2735@Sun.COM> To: Brian Ruthven - Sun UK Cc: Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Mail-followup-to: Brian Ruthven - Sun UK , Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Message-id: <20080702163642.GO2734@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: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> <20080701182613.GY2735@Sun.COM> <20080701184814.GA2735@Sun.COM> <486B5167.3020007@sun.com> <20080702163515.GR2735@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: 1527 On Wed, Jul 02, 2008 at 11:35:15AM -0500, Nicolas Williams wrote: > On Wed, Jul 02, 2008 at 10:59:03AM +0100, Brian Ruthven - Sun UK wrote: > > However, this seems like a very simple DoS attack to me. It's obvious > > what the problem is (thankfully, the error messages are meaningful), but > > still requires manual intervention to fix the problem. What steps could > > be taken to prevent this? (if it is even worth preventing in the first > > place) > > We have this attack for lots of other things, sadly. > > > I'll offer the following for consideration: > > Could the socket dir be located under, e.g. /var/run instead? > > I hesitantly also suggest a new tmpfs filesystem, something like > > /var/screens. > > The solution of Solaris creating the directory every bootup seems > > like a bit of a hack to me, but I'll mention it anyway :-) > > IMO the correct solution is for a PAM module (pam_unix_session) to > mktemp a user's TMPDIR the first time the user logs in since boot. The > module should record this TMPDIR so that the user gets the same TMPDIR > on subsequent logins whenever possible (e.g., whenever the TMPDIR is > still owned by the user). The module should set that environment > variable. > > And then screen could use $TMPDIR/screens as the socket dir. I forgot to say: not this case. The point is: I don't mind if screen uses /tmp/S-$USER even though that's DoSeable -- the user can always specify a SCREENDIR to screen. I also don't mind if it uses $HOME/.screens. Nico -- From gdamore@sun.com Wed Jul 2 10:45:07 2008 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 m62Hj6Bl017111 for ; Wed, 2 Jul 2008 10:45:07 -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 m62Hj2KS019948 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 2 Jul 2008 10:45:06 -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 <0K3E00F0N3Z6L000@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 10:45:06 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3E00EFR3Z5KT10@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 10:45:05 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m62Hj51P006678 for ; Wed, 02 Jul 2008 10:45:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3E001013M04Z00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 10:45:05 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3E00L0F3Z3ETC0@fe-sfbay-09.sun.com>; Wed, 02 Jul 2008 10:45:04 -0700 (PDT) Date: Wed, 02 Jul 2008 10:42:36 -0700 From: "Garrett D'Amore" Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <20080702163515.GR2735@Sun.COM> Sender: Garrett.Damore@sun.com To: Brian Ruthven - Sun UK , Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, johnsonnenschein@gmail.com, storycrafter@gmail.com Message-id: <486BBE0C.10704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> <20080701182613.GY2735@Sun.COM> <20080701184814.GA2735@Sun.COM> <486B5167.3020007@sun.com> <20080702163515.GR2735@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2450 Nicolas Williams wrote: > On Wed, Jul 02, 2008 at 10:59:03AM +0100, Brian Ruthven - Sun UK wrote: > >> However, this seems like a very simple DoS attack to me. It's obvious >> what the problem is (thankfully, the error messages are meaningful), but >> still requires manual intervention to fix the problem. What steps could >> be taken to prevent this? (if it is even worth preventing in the first >> place) >> > > We have this attack for lots of other things, sadly. > > >> I'll offer the following for consideration: >> Could the socket dir be located under, e.g. /var/run instead? >> I hesitantly also suggest a new tmpfs filesystem, something like >> /var/screens. >> The solution of Solaris creating the directory every bootup seems >> like a bit of a hack to me, but I'll mention it anyway :-) >> > > IMO the correct solution is for a PAM module (pam_unix_session) to > mktemp a user's TMPDIR the first time the user logs in since boot. The > module should record this TMPDIR so that the user gets the same TMPDIR > on subsequent logins whenever possible (e.g., whenever the TMPDIR is > still owned by the user). The module should set that environment > variable. > > And then screen could use $TMPDIR/screens as the socket dir. > An interesting design with merit, but it sounds like something that has ramifications beyond this case, and would need to be run separately (a separate ARC case/fasttrack). Meanwhile, if ~/.screens works, that sounds reasonable to me. My only possible concern there is how this behaves over NFS. John, will multiple screen sessions running on different machines with a shared NFS screens dir interfere with each other? Are there any caveats (such as the hostname being required to be different)? I will also point out, there is a different approach possible: make a tiny wrapper program that checks/makes the screens dir (enforcing permissions), and then just execs the real screen program. This could either be setuid program that then drops its permissions before execing "real-screen", or it could be a shell script that uses a setid helper program to make the screens dir. Such an approach does represent more work (a little) for the project team, but it doesn't require any changes to the upstream sources, and could be done in the context of this case. And FWIW, yes, I prefer /var/run to /tmp for this use, I think. -- Garrett > Nico > From johnsonnenschein@gmail.com Wed Jul 2 11:27:39 2008 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 m62IRdqM018305 for ; Wed, 2 Jul 2008 11:27:39 -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 m62IRc5d038448 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 2 Jul 2008 12:27:38 -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 <0K3E00H095Y2CN00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 11:27:38 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3E00EQ65Y1KJ20@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 02 Jul 2008 11:27:37 -0700 (PDT) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m62IRbQG008127 for ; Wed, 02 Jul 2008 18:27:37 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay16i.sun.com with ESMTP id BT-MMP-95371 for psarc-ext@sun.com; Wed, 02 Jul 2008 18:27:37 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-70846682 for psarc-ext@sun.com; Wed, 02 Jul 2008 18:27:36 +0000 (Z) Received: from py-out-1112.google.com ([64.233.166.179] [64.233.166.179]) by relay1ib.sun.com with ESMTP id BT-MMP-7615115 for psarc-ext@sun.com; Wed, 02 Jul 2008 18:27:36 +0000 (Z) Received: by py-out-1112.google.com with SMTP id u77so286083pyb.5 for ; Wed, 02 Jul 2008 11:27:27 -0700 (PDT) Received: by 10.114.133.1 with SMTP id g1mr7312457wad.123.1215023247165; Wed, 02 Jul 2008 11:27:27 -0700 (PDT) Received: from ?192.168.1.104? ( [76.10.188.43]) by mx.google.com with ESMTPS id a8sm9580319poa.12.2008.07.02.11.27.23 (version=TLSv1/SSLv3 cipher=RC4-MD5) ; Wed, 02 Jul 2008 11:27:25 -0700 (PDT) Date: Wed, 02 Jul 2008 11:27:21 -0700 From: John Sonnenschein Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <486BBE0C.10704@sun.com> To: "Garrett D'Amore" Cc: Brian Ruthven - Sun UK , Darren J Moffat , psarc-ext@sun.com, Petr.Sumbera@sun.com, storycrafter@gmail.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.926) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=hn0M0280bw6atj67AxVAflkqze6NiAfYq3GOn5oqLLE=; b=faSsq43JGjTpikJmh9P5lT5hAUtk1BV56GV76hWhFednV0gAKyPfiGWLOiqZ9UEgA+ Z4R6vxA3Cx7Xx8roOQ+w3PvtwKejq0nSFvLt6baPezCuoROIho4OvTrlqpaj5cp7pfOb 6NluFAXE33W2U+jGw+3ro/EpDVe3XBL+ioBoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=E/piZZ6H1NkEnzIGQpUCMxSOs01FintPyKzwG8FbKGwq1uRBwCwMglQXlgeb38mKyH OAfrtrqJ3fqrRBUYMhP1Kzi0R+nLjw/Jgjad/lXZom5Vcs/FtOV5oZal+u3aFFD/MqiW yVIDDpBI27A5eI0rI3QWvZuia4kL68mS8yBps= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.078sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> <20080701182613.GY2735@Sun.COM> <20080701184814.GA2735@Sun.COM> <486B5167.3020007@sun.com> <20080702163515.GR2735@Sun.COM> <486BBE0C.10704@sun.com> Status: RO Content-Length: 2922 On 2-Jul-08, at 10:42 AM, Garrett D'Amore wrote: > Nicolas Williams wrote: >> On Wed, Jul 02, 2008 at 10:59:03AM +0100, Brian Ruthven - Sun UK >> wrote: >> >>> However, this seems like a very simple DoS attack to me. It's >>> obvious what the problem is (thankfully, the error messages are >>> meaningful), but still requires manual intervention to fix the >>> problem. What steps could be taken to prevent this? (if it is even >>> worth preventing in the first place) >>> >> >> We have this attack for lots of other things, sadly. >> >> >>> I'll offer the following for consideration: >>> Could the socket dir be located under, e.g. /var/run instead? >>> I hesitantly also suggest a new tmpfs filesystem, something >>> like /var/screens. >>> The solution of Solaris creating the directory every bootup >>> seems like a bit of a hack to me, but I'll mention it anyway :-) >>> >> >> IMO the correct solution is for a PAM module (pam_unix_session) to >> mktemp a user's TMPDIR the first time the user logs in since boot. >> The >> module should record this TMPDIR so that the user gets the same >> TMPDIR >> on subsequent logins whenever possible (e.g., whenever the TMPDIR is >> still owned by the user). The module should set that environment >> variable. >> >> And then screen could use $TMPDIR/screens as the socket dir. >> > > An interesting design with merit, but it sounds like something that > has ramifications beyond this case, and would need to be run > separately (a separate ARC case/fasttrack). > > Meanwhile, if ~/.screens works, that sounds reasonable to me. My > only possible concern there is how this behaves over NFS. John, > will multiple screen sessions running on different machines with a > shared NFS screens dir interfere with each other? Are there any > caveats (such as the hostname being required to be different)? when run with per-user socket directory, the format that screen dumps sockets in to .screen is something to the effect of .pts-. which I think ought to be enough specifics that screen is unlikely to create the same file at the same time twice. I think that this is the preferable solution over the others that have been mentioned > I will also point out, there is a different approach possible: make > a tiny wrapper program that checks/makes the screens dir (enforcing > permissions), and then just execs the real screen program. This > could either be setuid program that then drops its permissions > before execing "real-screen", or it could be a shell script that > uses a setid helper program to make the screens dir. Such an > approach does represent more work (a little) for the project team, > but it doesn't require any changes to the upstream sources, and > could be done in the context of this case. > > And FWIW, yes, I prefer /var/run to /tmp for this use, I think. From Vladimir.Marek@sun.com Thu Jul 3 06:06:38 2008 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 m63D6b5d013979 for ; Thu, 3 Jul 2008 06:06:38 -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 m63D6arM023195 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 3 Jul 2008 14:06:36 +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 <0K3F0000FLQZ5300@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Jul 2008 06:06:35 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3F00EQOLQYYBA0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Jul 2008 06:06:34 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m63D6XC8028939 for ; Thu, 03 Jul 2008 13:06:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3F00901LPIEU00@fe-emea-10.sun.com> (original mail from Vladimir.Marek@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Jul 2008 14:06:33 +0100 (BST) Received: from @ ([129.157.18.82]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3F002X7LQVUN10@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Jul 2008 14:06:32 +0100 (BST) Date: Thu, 03 Jul 2008 15:06:28 +0200 From: Vladimir Marek Subject: Re: GNU screen [PSARC/2008/413 FastTrack timeout 07/14/2008] In-reply-to: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> Sender: Vladimir.Marek@sun.com To: psarc-ext@sun.com Mail-followup-to: psarc-ext@sun.com Message-id: <20080703130627.GJ24017@pub> MIME-version: 1.0 Content-type: multipart/signed; boundary=j3zO+32zXj6UcJCE; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200807011732.m61HWnxs001164@sac.sfbay.sun.com> User-Agent: Mutt/1.5.18 (2008-07-02) Status: RO Content-Length: 1520 --j3zO+32zXj6UcJCE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, >=20 > Exported Interfaces > Interface Classification Comments > ----------------------------------------------------------------------= --- > SUNWscreen Uncommitted Package for binaries > SUNWscreenrc Uncommitted Package configuration= file >=20 > /usr/bin/screen Uncommitted The screen binary > /usr/share/lib/terminfo/s/screen Uncommitted The 'screen' terminfo= file That's not enough, I think. You should have - screen - screen-bce - screen-s - screen-w - screen-16color - screen-16color-bce - screen-16color-bce-s - screen-16color-s - screen-256color - screen-256color-bce - screen-256color-bce-s - screen-256color-s - screen.linux - screen.teraterm - screen.xterm-new - screen.xterm-r6 - screen.xterm-xfree86 - screen2 - screen3 Please note that the -bce are for example required for mutt to work correct= ly in screen. Please also include UTF-8 and 256 color support, which are not enabled by default. Thank you --=20 Vlad --j3zO+32zXj6UcJCE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (SunOS) iEUEARECAAYFAkhsztMACgkQqVN0MVP42YxtqwCgrcb7ecbnTfm9SXIFIjy5KBXl qwkAmPTgw3roe1e5Z05/MPyjUnWNmJY= =Jq3C -----END PGP SIGNATURE----- --j3zO+32zXj6UcJCE--