Date: Thu, 12 Apr 2001 23:35:01 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-audit@FreeBSD.org Cc: tmm@FreeBSD.org Subject: Re: relationship between credential-managing daemons and normal processes Message-ID: <Pine.NEB.3.96L.1010412231901.10709A-100000@fledge.watson.org> In-Reply-To: <Pine.NEB.3.96L.1010412001239.97720C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010412231901.10709A-100000>