mangler@cit-vax.Caltech.Edu (System Mangler) (12/03/86)
Seems like it would be more secure that way...
Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!specklevy@ttrdc.UUCP (Daniel R. Levy) (12/04/86)
In article <1268@cit-vax.Caltech.Edu>, mangler@cit-vax.UUCP writes: >Seems like it would be more secure that way... >Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck chroot(2) can only be used by the superuser (euid=0). Sounds dangerous to have uucico setuid root rather than setuid uucp. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
csg@pyramid.UUCP (Carl S. Gutekunst) (12/09/86)
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. <csg>