From owner-freebsd-arch Sat Oct 6 6:53:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id F07DC37B409 for ; Sat, 6 Oct 2001 06:53:43 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id f96DrNB67051; Sat, 6 Oct 2001 09:53:23 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 6 Oct 2001 09:53:23 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dag-Erling Smorgrav Cc: Peter Wemm , arch@FreeBSD.ORG Subject: Re: Removing ptrace(2)'s dependency on procfs(5) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 6 Oct 2001, Dag-Erling Smorgrav wrote: > Robert Watson 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