Date: Mon, 04 Aug 1997 13:14:31 -0700 From: David Greenman <dg@root.com> To: Sean Eric Fagan <sef@kithrup.com> Cc: security@FreeBSD.ORG Subject: Re: My last words on teh subject Message-ID: <199708042014.NAA14244@implode.root.com> In-Reply-To: Your message of "Mon, 04 Aug 1997 11:12:30 PDT." <199708041812.LAA21777@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708042014.NAA14244>