From owner-freebsd-hackers Sun Aug 10 16:55:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA24631 for hackers-outgoing; Sun, 10 Aug 1997 16:55:55 -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 QAA24626 for ; Sun, 10 Aug 1997 16:55:52 -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 QAA06069; Sun, 10 Aug 1997 16:58:21 -0700 (PDT) Message-Id: <199708102358.QAA06069@implode.root.com> To: Sean Eric Fagan cc: hackers@FreeBSD.ORG Subject: Re: Fix for the PROCFS security hole! In-reply-to: Your message of "Sun, 10 Aug 1997 10:34:50 PDT." <199708101734.KAA17222@kithrup.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 10 Aug 1997 16:58:21 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >In article you write: >>I'm not to sure how to do it, but IF the procfs system could be modified >>to somehow act like the /dev/tty* system, where the second a user >>logs on the device is then owned by them and all other users access is >>revoked. This could work that a setuid proc when exec'd, procfs would >>automatically change permissions on it so that it is untainable. > >The solution I'm working on right now (which I've had in mind for a while) >was to have procfs return an error when doing any I/O to a process which has >ever changed id's, unless (of course) the calling process is root. That will break ps(8)...I've already been down that road and several others... At the moment, I think changing the permissions on the mem file to always be uid 0/gid 2 is the correct solution, but this may require changes to gdb (which I think uses procfs to read/write the target process). I might be wrong about gdb, however - I thought it did the process manipulation a different way, but I then saw its kvm_uread() opens the mem file. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project