Date: Sat, 6 Oct 2001 09:53:23 -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.1011006095018.66473D-100000@fledge.watson.org> In-Reply-To: <xzpr8sgrirq.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:
> > On 6 Oct 2001, Dag-Erling Smorgrav wrote:
> > > 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. [...]
> >
> > 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(). [...]
>
> I'm confused - I think you misread my question; I was suggesting adding
> the P_SYSTEM check to p_candebug(), not p_cansee(). If you did not
> misread my question, you'll have to clarify what you meant in the above
> three paragraphs :)
Well, I guess the decision I was trying to look at was:
(1) Is it a global security policy that debugging primitives may never be
applied to kernel processes.
(2) Is it a syntactic property of the debugging primitive that it *cannot*
be applied to kernel processes.
I'm leaning towards (2): debugging simply doesn't apply, and should be
checked for by the routines. If it were a security check, that might
imply that you could change the policy to allow such debugging, which you
can't. Since we would still like ESRCH to be returned for processes in
jail when attempting to attach to system processes, that means that the
security check should go first, and the P_SYSTEM check should go second.
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.1011006095018.66473D-100000>