From owner-freebsd-security  Mon Aug  4 13:12:42 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id NAA24347
          for security-outgoing; Mon, 4 Aug 1997 13:12:42 -0700 (PDT)
Received: from implode.root.com (implode.root.com [198.145.90.17])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA24342
          for <security@FreeBSD.ORG>; Mon, 4 Aug 1997 13:12:40 -0700 (PDT)
Received: from implode.root.com (localhost [127.0.0.1])
	by implode.root.com (8.8.5/8.8.5) with ESMTP id NAA14244;
	Mon, 4 Aug 1997 13:14:31 -0700 (PDT)
Message-Id: <199708042014.NAA14244@implode.root.com>
To: Sean Eric Fagan <sef@kithrup.com>
cc: security@FreeBSD.ORG
Subject: Re: My last words on teh subject 
In-reply-to: Your message of "Mon, 04 Aug 1997 11:12:30 PDT."
             <199708041812.LAA21777@kithrup.com> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Mon, 04 Aug 1997 13:14:31 -0700
Sender: owner-freebsd-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>Period.  Get it?  Do not reply to this, do not offer me your opinion.

   Well, I'm going to anyway. :-)

   Obviously I agree with Sean or I wouldn't have chosen his fix over the one
put forward by tqbf. It really comes down to just a few issues:

1) The process address space and context can't be shared across an exec; it
   should be obvious why this is the case. It is entirely consistent for the
   file descriptor table sharing to be severed, too, especially when one
   considers the primary purpose of rfork().
2) Files are normally closed on exec; thus doing an exec in a child would
   normally close all files in the parent and all other processes in a thread.
   This means that without special coding in both the parent and the child,
   exec is escentially useless after an rfork(). This is simply broken and
   makes rfork() much less useful in typical situations.
3) Dropping setuid/setgid will almost certainly cause a target image that is
   specifically set this way to break badly. We do this with ptrace() only
   because of a probably wrong assumption that ptrace() of such a process is
   still useful. Further, while this fixes the security problem, it ignores
   the bigger picture of fd table sharing across an exec being generally
   unuseful and broken from an API perspective.
4) Failing to do the exec with EPERM is very inconsistent with expected
   behavior of exec, and few applications, if any, are going to handle this
   well.

   I originally thought that dropping setuid/setgid in the case of a shared
fd table was the right approach, until I realized #2 and then considered #3
and #1. Further, Sean's points about the intended usage of rfork() further
point to only one viable (to my mind) solution: copy the file descriptor
table, thus severing the sharing while keeping the files themselves open.

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project