Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!csg From: csg@pyramid.UUCP (Carl S. Gutekunst) Newsgroups: comp.unix.wizards Subject: Re: Why doesn't uucico use chroot(2)? Message-ID: <1154@pyramid.UUCP> Date: Tue, 9-Dec-86 01:14:21 EST Article-I.D.: pyramid.1154 Posted: Tue Dec 9 01:14:21 1986 Date-Received: Tue, 9-Dec-86 09:40:47 EST References: <1268@cit-vax.Caltech.Edu> Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 24 Summary: The security gained is not worth the hassle The chroot 'world' would have to be set up such that all commands exec'd under uuxqt would run normally. This includes rmail, rnews, and (on a BSD system) sendmail. So your chroot directory tree would need links to /usr/lib/sendmail, /etc/passwd, and a whole buncha other files that do not normally live in the same partition. For some files, on a BSD system you could use symbolic links; for others, you would have no choice but to maintain multiple copies. (Making /etc/passwd a symbolic link is OTQ, for example.) And you would now have some of the files you wanted to protect in the chroot tree! Getting it right -- and *keeping* it right -- would be a difficult task if not impossible. You could have uucico to move the root back before it forks uuxqt, but then you lose most of your security. In addition, uucico would be totally unable to reference any user files; this would rule out the use of the '-c' option to uucp and uux. But it appears that is what you want. Uucico would also have to be suid to root, but only long enough to do the chroot(2) call. In short, this may have merit in specific applications, but the little bit of security gained is not worth the hassle for most environments.