From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 14 14:33:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9CBA106564A; Fri, 14 Sep 2012 14:33:44 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A557A8FC0A; Fri, 14 Sep 2012 14:33:44 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so6231378pbb.13 for ; Fri, 14 Sep 2012 07:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q/5xyo6XBXBH27jWa9PcDwT0t9/u5PqY+rVlfwCk8dA=; b=DUN201AMmobh+CVcN3oCBN5smHtZ6kyAdTRO8uvjud7iug8KI4tVhaQYEB/Uf8p4HO Q0ru4Dqxjyi+o6WLBExZTnOc7kvVbQC/Fh9Z1jw2NLdRaNztwwuujg5CwsdDd2ZfWLWR wkoCWtGnD3mpbjEDfEUNCer5oohq6b6GSSMIcgtnOg9xC8Mze/SiRJJ+XDdgH1WvfWCA IPhz8lDWxvKJ9nUyaARS2ox26sYK9reKy/tYhZT1xBOujgyb8Z7Z1lJNMBV5JM1ni/1l lFGpipyPf/shDQZGkYgobgNNUmc9erkx+AcIdHVoM676pwC23xX9OvSfgJOgrAzetPhj GCRw== MIME-Version: 1.0 Received: by 10.66.75.73 with SMTP id a9mr4411040paw.43.1347633224050; Fri, 14 Sep 2012 07:33:44 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.13.170 with HTTP; Fri, 14 Sep 2012 07:33:43 -0700 (PDT) In-Reply-To: <52517366-C10B-4CAA-BDDF-31E2098CBDA3@cederstrand.dk> References: <035514CA-81D6-407F-A2C1-51A9FB0E3A74@cederstrand.dk> <52517366-C10B-4CAA-BDDF-31E2098CBDA3@cederstrand.dk> Date: Fri, 14 Sep 2012 07:33:43 -0700 X-Google-Sender-Auth: 0UODToJbe_iRtXScT-4eqGjhVRU Message-ID: From: mdf@FreeBSD.org To: Erik Cederstrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Change vfork() to posix_spawn()? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 14:33:45 -0000 On Fri, Sep 14, 2012 at 4:45 AM, Erik Cederstrand wro= te: > Den 14/09/2012 kl. 13.03 skrev Ivan Voras : > >> On 14/09/2012 09:49, Erik Cederstrand wrote: >>> Hello hackers, >>> >>> I'm looking through the Clang Analyzer scans on http://scan.freebsd.you= r.org/freebsd-head looking for false positives to report back to LLVM. Ther= e are quite a list of reports suggesting to change vfork() calls to posix_s= pawn(). Example from /bin/rpc: http://scan.freebsd.your.org/freebsd-head/bi= n.rcp/2012-09-12-amd64/report-nsOV80.html#EndPath >>> >>> I know nothing about this but I can see fork and posix_spawn have been = discussed on this list previously. Is this a legitimate warning (in this ca= se and in general in FreeBSD base)? >> >> Currently (on 9-stable at least), posix_spawn() is implemented as a >> wrapper around vfork(), so I doubt replacing one with the other would do >> much. > > The analyzer added this warning in January. The release notes link to thi= s explanation: https://www.securecoding.cert.org/confluence/display/seccode= /POS33-C.+Do+not+use+vfork() > > I guess this is the important part: > > "Because of the implementation of the vfork() function, the parent proces= s is suspended while the child process executes. If a user sends a signal t= o the child process, delaying its execution, the parent process (which is p= rivileged) is also blocked. This means that an unprivileged process can cau= se a privileged process to halt, which is a privilege inversion resulting i= n a denial of service." > Isn't the important part the previous paragraph, which said that some older versions of Linux had the problem? The entire thing reads that the issue comes from an idiom of vfork(), setuid(), then exec, which is both undefined and would be specific to only some *uses* of vfork(), not the implementation. The whole thing isn't worded terribly usefully; e.g. it doesn't explain if it was only Linux that had an issue, which version of Linux is fixed, whether normal code that went straight from vfork() to exec() was fine, etc. Cheers, matthew