Date: Fri, 13 Sep 2002 08:36:56 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Nate Lawson <nate@root.org> Cc: Garrett Wollman <wollman@lcs.mit.edu>, arch@freebsd.org, imp@freebsd.org, peter@freebsd.org Subject: Re: PATCH: vnode->v_tag to const char * Message-ID: <Pine.NEB.3.96L.1020913082734.27711D-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0209130039480.26024-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Sep 2002, Nate Lawson wrote: > Ok, now that works for NFS (VFCF_NETWORK). But the procfs check is > horrible. > > For those just tuning in, if a set[ug]id program has /proc/mumble open > on fds 0-2, it's possible it could inadvertently write to them, causing > a crash. The check is_unsafe() in kern_descrip.c handles this case. > > I changed it to use VFCF_SYNTHETIC instead but that is not right -- > fdescfs and devfs (think: /dev/fd/*, /dev/tty) are also synthetic. And > what about portal ... ? > > What is the 'right' way to keep sugid programs from crashing the system > with open 0-2 fds? The risk isn't just that the system might crash, it's that I might be able to gain privilege by setting up a scenario of this sort. The ability to write to a procfs vnode (such as mem) can come and go as the privilege of the subject and target processes change, yet a file descriptor reference to the procfs vnode may remain valid throughout. Through careful timing, it may be possible to arrange for one setuid application to write to the memory space of another setuid application in a controlled form, which could be used to increase the level of privilege of the attacker by causing the target process to misbehave in a predictable way. Through careful racing, for example, you could arrange for the output of your arbitrary friendly setuid program (passwd, su, lpr, ...) to end up overwriting the buffer memory used by another command (passwd, su) to change its behavior to your benefit (as an attacker). Interestingly, procfs vnodes are one of the few cases where this can happen, since it's one of the few file systems we have with this sort of semantic. With MAC and securelevels/file flags, there are some other cases where the privilege to write to an object comes and goes, but you might still have a file descriptor. Arguably, this is a weakness to the UNIX model, and it's not yet clear to me what the right fix is. Certainly disallowing stdio from pointing to procfs nodes is a good start and prevents known problems. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories 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.1020913082734.27711D-100000>