X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=f23hlJ1Zz6Oy9v0kP8NPLyU724qQwG+keiBLoRaqW7A
	9X+V2XvshWDDsPK0WrHOt3eZmQyL36Flo4iXoahWtf+Ks2edHdW11+hG/ZDaqLJz
	+bkA3LjHh475TAO1MWT63D6q4BtMfbophjC4BydsxBYrXAQH2HTdRLhpMY58LO0U
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=zxeqnCeQeAYSE4SD6ce1sEqyGR0=; b=gE2L6LUJDj1CNwTLP
	a1RrhNZzPnYM49lKSNUz1Ub93f5QkPQcCSWeZ5/5teAgTeXWkd8s2f3MWDHFnFCy
	IKPKKqXWFHMmWIkDoBtMzzG8DqWWhXpfzOox3+4xqXqSiME0a20qMZhnjGf/xrUs
	QOsbL3f4rnX9Jc+q2Se6nWNuJg=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO:	mailout01.t-online.de
Message-ID:	<541415B1.8090500@t-online.de>
Date:	Sat, 13 Sep 2014 12:00:17 +0200
From:	Christian Franke <Christian DOT Franke AT t-online DOT de>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Cannot exec() program outside of /bin if PATH is unset
References:	<5413271B DOT 1010109 AT t-online DOT de> <54134A83 DOT 80107 AT redhat DOT com> <54135451 DOT 3060902 AT t-online DOT de> <601154762 DOT 20140913012935 AT yandex DOT ru> <541378C4 DOT 6030705 AT t-online DOT de> <54137BDE DOT 6040907 AT redhat DOT com> <54137C7F DOT 1040507 AT redhat DOT com>
In-Reply-To:	<54137C7F.1040507@redhat.com>
X-IsSubscribed:	yes

Eric Blake wrote:
> On 09/12/2014 05:03 PM, Eric Blake wrote:
>> On 09/12/2014 04:50 PM, Christian Franke wrote:
>>> Andrey Repin wrote:
>>>>> Hmm... is postfix actually broken?
>>>>> Unsetting PATH is IMO sane (from the POSIX POV) if all exec() calls use
>>>>> absolute path names.
>>>> If all exec() calls are made with full paths, unsetting $PATH does not
>>>> improve
>>>> security in any way,
>>> Of course. But postfix could be configured to run "unknown" external
>>> programs through its various daemons. In this case, a fixed (here:
>>> empty) PATH improves security. If not convinced, please discuss with the
>>> author of postfix :-)
>> An empty PATH leaves it up to the implementation what helpers get run
>> (if it doesn't fall over first), which is LESS secure than a guaranteed
>> safe PATH of confstr(_CS_PATH).
> By the way, passing a _safe_ PATH to your child process IS a good idea
> for security-conscious programs, but you have to do it correctly

Agree. The postfix spawn(8) and pipe(8) daemons actually spawn external 
programs with PATH set to _PATH_DEFPATH.


> (by passing an actual safe path, and NOT by completely unsetting PATH).
>

Disagree. The postfix master(8) spawns all of its daemons with PATH 
unset. This IMO does not violate POSIX.

Note that setting PATH=/bin on Cygwin does not fix the security problem 
in the DLL search order. Even with "SafeDllSearchMode" enabled, the 
current directory is always checked before PATH. Running some Cygwin 
program from /usr/sbin, /usr/local/bin, /usr/libexec, ... would load a 
possible malicious cyg*.dll from current directory regardless of PATH 
setting. Only programs in /bin are safe.

Using SetDllDirectory("c:\\cygwin\\bin") somewhere in cygwin1.dll would 
fix this also.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -