From owner-freebsd-arch Sat Oct 6 7:50:53 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 0768837B415 for ; Sat, 6 Oct 2001 07:50:47 -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 f96EoJB67539; Sat, 6 Oct 2001 10:50:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 6 Oct 2001 10:50:19 -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: > > 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. > > Sure, but doesn't prison_check() take care of ESRCH? I can add the > P_SYSTEM check *after* the prison_check() call in p_candebug(): The question I'm trying to address here is a bit more subtle than that: it's not a question of what we can do, but what we should do. Generally speaking, you might choose to consider security checks of this sort in the following way: there's a certain scope of "valid" requests, and the set of valid requests is going to be limited by a security function. Because there are a number of security failure modes ("you can't even see that it exists" vs. "you can see it, but not touch it"), the ordering and composition of the security checks can be complex. But the question I'm trying to look at here is whether or not, fundamentally, the P_SYSTEM check is a security check. Right now, my leaning is that it is not: checking P_SYSTEM is a validity check because ptrace() and procfs are both definined as allowing the debugging of normal user processes, not system processes. I.e., if you had a system without a security model, you still wouldn't allow debugging of system processes using the user debugger interface. Since the goal of p_candebug() is to impose the general security debugger-related policy, not perform validity checks on arguments, that suggests that the P_SYSTEM check should be present in the service implementation (proc_rwmem() or whatever it's going to be called). Now, that doesn't mean that it shouldn't *also* exist in p_candebug(). You can easily imagine a system security policy that did revolve around protecting system processes--for example, the fact that the jail code restricts the visibility of such processes. Rather than having that implicit on jail membership, it could be explicit, in the form: int p_cansee(...) ... if (p->p_flags & P_SYSTEM) return (ESRCH); ... However, that suggests that if you want to have one in p_candebug(), it should be redundant, and purely an addition to the one in proc_remem(). In fact, I would argue that if there was a P_SYSTEM check in p_candebug(), it should look like this: int p_candebug(...) ... if (p->p_flags & P_SYSTEM) return (EPERM); ... Which is not the desired EINVAL return value. So my opinion is that the P_SYSTEM check should remain in the individual debugging interfaces, and that if redundancy is OK, consider adding a P_SYSTEM->EPERM check in p_candebug(). Interestingly, BTW, this is similar to the issue of read-only mounting of file systems. Right now, my opinion is that if a file system os mounted read-only, that's not a security protection. That's a syntactic function of the mount/file system service. So it should always return EROFS, rather than EPERM, and isn't abstracted into the general security code (via vaccess(), vaccess_acl_posix1e(), vaccess_mac(), et al). An argument to support this is that this is the flag used at the file system level as a validity check to prevent writing to read-only underlying media. 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