On 5/8/05, Shaul Karl <[EMAIL PROTECTED]> wrote: > On Sat, May 07, 2005 at 08:10:27PM +0300, Gilad Ben-Yossef wrote: > > Can you give more details about what you wrote? > > > > Shaul Karl wrote: > > > On my Debian machine only root is permitted to chroot(2). What are the > > > cons for having a regular user chroot? Are there any patches floating > > > around to change that? > > > > > > > > > If there exists any dynamically linked SUID root binary in the system > > What do you mean by dynamically linked SUID root binary? For me, > `dynamically linked' is associated with libraries, while a binary is the > same as executable and suid is only for executables. In short, what is > my mistake?
Executable programs dynamically link to dynamic libraries (or "shared objects", files with ".so" extensions). I'll try to explain Gilad's scenario in more detail: Imagine that you have a program called umount, which is a suid executable. This executable dynamically links, among others, to libc. (run "ldd /bin/umount" to see this). When you execute the file it actually first executes the dynamic loader, which looks up to resolve all dynamic libraries this executable depends on. Since this is an SUID file, the loader will ignore LD_LIBRARY_PATH or other envariables and only look up in "system directories" (e.g. only under the absolute path /lib, /usr/lib and possibly others, see ld.so(8)). If you change the root of your filesystem then this dynamic loader will keep looking only in "system directories" (because it's an SUID executable) but the definition of "/" would have changed to wherever you defined your chroot, and therefore /lib will be a diretory of your choosing. Now you see the problem? You can put a different library under the name /lib/libc.6... which will do whatever you want when its functions are called by the SUID executable. The dynamic link loader will use this library because it will believe that this is the "system library" /lib/libc.6.... Hope this explained things better... > > > > (e.g. ping) which a user can contain in a directory such that the > > What is the difference between what you refer to and a simple cp of an > suid executable to somewhere under the user home directory? The cp by a regular user won't copy the suid bit and the ownership of root, would it? Try it! > > > > regular directory structure puts files controlled by the user in > > directories that would become, for example, /lib or /usr/lib after > > chroot and then chroot inside it you have effectively given this user > > root privileges. > > > > How all this would give him root privileges? Hope I explained this above. > There are systems where a regular user can chroot, aren't there? Can > you name them? Not that I'm aware of. --Amos ================================================================To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
