Date: Sun, 10 Aug 1997 16:58:21 -0700 From: David Greenman <dg@root.com> To: Sean Eric Fagan <sef@Kithrup.COM> Cc: hackers@FreeBSD.ORG Subject: Re: Fix for the PROCFS security hole! Message-ID: <199708102358.QAA06069@implode.root.com> In-Reply-To: Your message of "Sun, 10 Aug 1997 10:34:50 PDT." <199708101734.KAA17222@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>In article <Pine.BSF.3.96.970810101530.7449B-100000.kithrup.freebsd.hackers@server.local.sunyit.edu> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708102358.QAA06069>