michael@maui.cs.ucla.edu (michael gersten) (12/08/88)
In article <157@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >In article <1988Nov29.181037.23528@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >>>Secondly, can someone out there explain why chroot is privileged? ... >>>... It seems pretty darn silly that some >>>mechanism that can only be used for *reducing* access rights requires >>>root permission... >> >>because it gives absolute control over the file system, and some parts >>of the file system are vital to the protection system. For example, >>login assumes that the file it finds when it opens "/etc/passwd" is the >>system password file. This doesn't work, though. Lets say I put a dummy passwd in mydir/etc. And I do a "exec chroot mydir login". I then login as root. BUT: I'm in mydir, and I can't get out. Remember: chroot is an absolute limit on directories, i.e., my / == mydir, my /../../.. == mydir. Or are you running V7 which did not have that last bit in there? (Sys5, and I think sys3, did have that corrected limit on chroot).
gandalf@csli.STANFORD.EDU (Juergen Wagner) (12/08/88)
[Sorry, my rn gives me an internal error when I try to followup.] I thought, this had been chewed on for long enough, ... Michael Gersten (michael@maui.cs.ucla.edu) writes: >... > Lets say I put a dummy passwd in mydir/etc. > And I do a "exec chroot mydir login". > I then login as root. > BUT: I'm in mydir, and I can't get out. Right! You can't. But how about copying /bin/sh to your directory, then doing the chroot stuff you describe, and finally typing something like chown root sh chmod 4755 sh Now type "exit" to this shell, and you're back to the login prompt. At your next login (and here chroot is *NO LONGER* active), you will find a setuid root file called sh in that mydir, giving you a root shell with access to the *ENTIRE* file system! 'nuff said. -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
henry@utzoo.uucp (Henry Spencer) (12/09/88)
In article <18639@shemp.CS.UCLA.EDU> michael@cs.ucla.edu (michael gersten) writes: >Lets say I put a dummy passwd in mydir/etc. >And I do a "exec chroot mydir login". >I then login as root. >BUT: I'm in mydir, and I can't get out. But you can, of course, make yourself a setuid-root shell if you've previously copied sh, chown, and chmod in there. Please think before posting. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
frank@rsoft.UUCP (Frank I. Reiter) (12/10/88)
In article <18639@shemp.CS.UCLA.EDU> michael@cs.ucla.edu (michael gersten) writes: [Lots deleted] >This doesn't work, though. > >Lets say I put a dummy passwd in mydir/etc. >And I do a "exec chroot mydir login". >I then login as root. >BUT: I'm in mydir, and I can't get out. But in mydir may be a "rootsh" program which invokes /bin/sh. After logging in as root I could : chown root rootsh;chmod u+s rootsh and log back out. Next time I login I have a nifty little command called rootsh that is su without the password. -- *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Frank I. Reiter \ / UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank Langley, British Columbia / \ BBS: Mind Link @ (604)533-2312 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
root@conexch.UUCP (Larry Dighera) (12/11/88)
In article <157@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: > >Thanks Henry (and literally dozens of others) for pointing out the problems >of world-executable chroot. What a dumb question to ask. [...] The System V.3 _System_Calls_and_Library_Routines manual states on the chroot(2) page: " The effective user ID of the process must be super-user to change the root directory." The permission mode of the SysV.3 chroot command file really only applies to super-users, since the kernel will enforce the above. Were chroot to be world-executable, the fact remains that your effective ID would still have to be 0 in order to successfully execute chroot. If chroot were owned by root, I suppose, setting the SUID bit on the file would circumvent this safeguard. Larry Dighera -- USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712 TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71) UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp UUCP: ...!uunet!turnkey!conexch!root || ...!trwrb!ucla-an!conexch!root
steenkl@ambush.UUCP (Steen Koefoed Larsen) (12/13/88)
michael@maui.cs.ucla.edu (michael gersten) writes: >In article <157@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >>In article <1988Nov29.181037.23528@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>>In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >>>>Secondly, can someone out there explain why chroot is privileged? ... >>>>... It seems pretty darn silly that some >>>>mechanism that can only be used for *reducing* access rights requires >>>>root permission... >>> >>>because it gives absolute control over the file system, and some parts >>>of the file system are vital to the protection system. For example, >>>login assumes that the file it finds when it opens "/etc/passwd" is the >>>system password file. >This doesn't work, though. >Lets say I put a dummy passwd in mydir/etc. >And I do a "exec chroot mydir login". >I then login as root. >BUT: I'm in mydir, and I can't get out. >Remember: chroot is an absolute limit on directories, i.e., >my / == mydir, >my /../../.. == mydir. >Or are you running V7 which did not have that last bit in there? >(Sys5, and I think sys3, did have that corrected limit on chroot). I would not like to have a root user with a chroot'ed filesystem playing around on my machine. What would happen if this user vere able to place the kill or the mknod command in his filesystem. He could also make a setuid sh in the limited filesystem and execute this from a normal login. etc. etc. (This is a long long long list) I really like the fact that chroot is privileged! -- Steen Koefoed Larsen, AmbraSoft A/S, Development Dept., Roejelskaer 15, DK-2840 Holte, Denmark. Tel: (+45) 2 807522 Fax: (+45) 2 423090 EUnet: steenkl@ambush.dk or !{uunet, mcvax}!dkuug!ambush!steenkl