From owner-freebsd-audit Thu Apr 12 20:34:31 2001 Delivered-To: freebsd-audit@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7B94937B42C; Thu, 12 Apr 2001 20:34:28 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3D3Z2f14610; Thu, 12 Apr 2001 23:35:02 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 12 Apr 2001 23:35:01 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-audit@FreeBSD.org Cc: tmm@FreeBSD.org Subject: Re: relationship between credential-managing daemons and normal processes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After some discussion with Thomas, running testings, etc, I've modified p_cansched() and p_cansignal() to take into account more restricted policies to remove these exceptions to the expected regression test results in 5.0-CURRENT. The commit messages document the details, but essentially the goal was to remove cases where the effective uid of the target process was used in the decision-making process, preventing processes from manipulating the scheduling of the daemon processes, or delivering signals to them improperly. Here's the new uid-based logic for p_cansched(): if (p1->p_cred->p_ruid == p2->p_cred->p_ruid) return (0); if (p1->p_ucred->cr_uid == p2->p_cred->p_ruid) return (0); Here's the new uid-based logic for p_cansignal(): if (p1->p_cred->p_ruid != p2->p_cred->p_ruid && p1->p_cred->p_ruid != p2->p_cred->p_svuid && p1->p_ucred->cr_uid != p2->p_cred->p_ruid && p1->p_ucred->cr_uid != p2->p_cred->p_svuid) { There are a few possible further changes that could be made to the p_cansched() logic in particular -- it might be appropriate to add the svuid checking there such that it matches the p_cansignal() logic, which catches setuid binaries relying on POSIX saved uid behavior. As I mentioned in my commit messages, there is some risk associated with changing this behavior: it's possible that applications exist which rely on the old behavior, for example. However, I did take this opportunity to inspect the Linux protection logic for signalling, and discovered (after a bit of un-hand-micro-optimizing) that the logic is the same. The same goes for our new p_cansched() and their similar access control checks. This suggests that there is a fairly large pool of users and applications for whom these behaviors work fine, which is a little reassuring. In any case, these are changes I'm willing to back out if they cause any problems, but I figured getting them in early would offer us the best opportunity to test them in a wider audience. 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-audit" in the body of the message