Date: Wed, 16 Jan 2002 16:08:55 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Nate Williams <nate@yogotech.com> Cc: Ruslan Ermilov <ru@FreeBSD.org>, Joerg Wunsch <j@uriah.heep.sax.de>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, arch@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/man/man Makefile man.c src/etc/mtree BSD.local.dist BSD.usr.dist BSD.x11-4.dist BSD.x11.dist Message-ID: <Pine.NEB.3.96L.1020116160403.73036E-100000@fledge.watson.org> In-Reply-To: <15429.56636.984304.733778@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Jan 2002, Nate Williams wrote: > My thinking is that it's just as easy to get root from a normal user as > it is to get it from man, so we're really not gaining a whole lot (from > the point of view of root compromises). I'm not 100% sure that's true. One of the problems with UUCP was that it was special in a way normal accounts are not: the root user may routinely run binaries that are setuid uucp, or setuid man, whereas the superuser doesn't routinely run binaries that are setuid nate or setuid robert. The result is that extra care must be taken to determine that the privileges inherited by the binary are properly handled. Right now, the binaries are set schg, which provides quite a bit of improvement over the alternative (where the man user or uucp user could simply modify the binary and gain root privilege the next time it was run). Of course, that's only true if the filesystem you're running off of is UFS. :-) There are still many potential sources of weakness due to the unix inheritence model associated with exec and setuid applications. The lowest risk solution (which doesn't cut back much on functionality) is to avoid this sort of arrangement as much as possible. We've shot ourselves in the feet with both setuid man and setuid uucp in the past. Our feet are sore. Let's shoot something else. > Regardless, there are still other concerns with over-writing files and > such that are annoying, if not necessarily security holes in the sense > of getting root access. Those can be used in social engineering attacks quite easily: many system administrators rely on the man pages to provide an accurate description of how a utility works. It's easy to imagine minor tweaks to common command lines that open up unnecessary privileges to users, even for experienced administrators. For example, the nohup command has documented behavior of creating output files in the CWD of the process. By tweaking the man page appropriately and describing normal use of nohup, I might leave you with the impression it was safe to run nohup in a directory that you don't own, or that is world writable. Likewise, I might tweak man pages to have you incorrectly configure utilities, use the wrong command line argument to specify files (target vs. configuration file, for example). The correctness and safety of man pages directly affects the security of the system. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020116160403.73036E-100000>