Date: Sat, 6 Oct 2001 09:22:10 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: Removing ptrace(2)'s dependency on procfs(5) Message-ID: <Pine.NEB.3.96L.1011006091037.66473B-100000@fledge.watson.org> In-Reply-To: <xzpd741rwix.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 Oct 2001, Dag-Erling Smorgrav wrote: > Robert Watson <rwatson@FreeBSD.ORG> writes: > > Instead, modify p_candebug() to allow debugging of p1 by p1 always. > > Should I also change p_candebug() to always deny the request if p2 is a > system process? That will save quite a lot of checks in ptrace() and > procfs, and possibly some other places as well. Hmm. An interesting question. As I see it, there would be some upsides and some downsides. An upside would relate to process visibility issues: for example, jail() does not permit enclosed processes to see system processes. If the P_SYSTEM check is first, and returns (EINVAL), then a jailed process can enumerate the system process space. Not a huge risk, but not quite in keeping with the intent of p_cansee(). Another choice is to put the check in p_candebug(). However, p_candebug() currently encapsulates security checks rather than validity checks--the inability to debug system processes comes from two components: first, the calling process may not have permission, but second, it's also just not possible :-). Rather than teach p_candebug() about the full scope of the various debugging mechanisms it's supporting, I'd rather have EINVAL checks in the caller. Another reason to do this is that there may potentially be other EINVAL checks depending on the mechanism: for example, if we were to start supporting remote debugging of processes, we might permit reading/writing of memory and registers, but not certain types of mappings. Another possibility would be to reorder the checks of p_cansignal() in ptrace(). I.e., the following: p = pfind(target); if (!p) return (ESRCH) error = p_candebug(curp, p); if (error) return (error); if (p->p_flags & P_SYSTEM) return (EINVAL); This would allow visibility and permission scoping to happen first, since the target is a valid "process", but for ptrace (and other calls) to reject the request if they discover they cannot function in the manner. I think right now I have a preference for the last of these, but I'm willing to be swayed in other directions if that seems useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011006091037.66473B-100000>