From owner-freebsd-security Mon Aug 4 11:00:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA16124 for security-outgoing; Mon, 4 Aug 1997 11:00:57 -0700 (PDT) Received: from enteract.com (enteract.com [206.54.252.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA16113 for ; Mon, 4 Aug 1997 11:00:53 -0700 (PDT) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id NAA07897; Mon, 4 Aug 1997 13:00:35 -0500 (CDT) From: "Thomas H. Ptacek" Message-Id: <199708041800.NAA07897@enteract.com> Subject: Re: Proposed alternate patch for the rfork vulnerability To: bde@zeta.org.au (Bruce Evans) Date: Mon, 4 Aug 1997 13:00:27 -0500 (CDT) Cc: bde@zeta.org.au, tqbf@enteract.com, security@FreeBSD.ORG, sef@Kithrup.COM Reply-To: tqbf@enteract.com In-Reply-To: <199708041753.DAA05901@godzilla.zeta.org.au> from "Bruce Evans" at Aug 5, 97 03:53:05 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Losing the shared descriptor table on exec is also useless. If the > table is shared then you probably want it to continue to be shared. > This only causes security problems in the setuid case. We're on the same side. The issue has already been resolved; the exact same type of problem (relations between processes that allow one to manipulate the other) was addressed with ptrace(). The solution was to ignore SUID and maintain the ptrace flag, while allowing the execve() to succeed. I don't see why FreeBSD has (apparently) decided to address this issue in a different manner, especially because they are now using an rfork() implementation that is incompatible with OpenBSD's. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"