Good morning Amos, LD_DEBUG (as of early glibc 2.3 versions IIRC), LD_LIBRARY_PATH and LD_PRELOAD do not work on SUID binaries, unless you are root. Further more, there are ways to achieve the goal Shaul needs by using capabilities(7). I would recommand a very small hack for chrooting dynamic executables without having to deal with library dependencies: http://chrootsafe.sourceforge.net/
That small utility can be changed and tweaked easily for custom needs (wrappers for example). Also, Gilad, a binary will keep its permissions and attributes if copied while root and by using the "-a" flag to cp, consult the man pages for more details. Kind regards, Alex On Sunday 08 May 2005 09:52, you wrote: > Shaul Karl 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? > > I mean an executable (like the "ping" program as I wrote), which is not > statically linked - it requires libraries (such glibc, for example) to > work and it's permissions have the SUID bit set and it's owner is root. > > >>(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 SUID bit does not survive a copy. Look: > > [EMAIL PROTECTED] gby]$ ls -l /bin/ping > -rwsr-xr-x 1 root root 28628 Jan 25 2003 /bin/ping > [EMAIL PROTECTED] gby]$ cp /bin/ping . > [EMAIL PROTECTED] gby]$ ls -l ./ping > -rwxr-xr-x 1 gby gby 28628 May 8 09:48 ./ping > > >>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? > > Simple, a library that an application loads is really part of its code. > if you can get a SUID executable to load a library YOU wrote you can > make it do everything. > > Just take glibc and replace "sprintf" with a version you wrote that does > sprintf and also creates a SUID copy of /bin/bash in your home > directory. Now if you can get a SUID exdcutable to load your library you > are in business. > > Now, if you allow a user to do a chroot he or she can take a suid root > owned executable, and *if* they can create around it a directory tree > that has, for example, /lib, and put there their own copy of glibc with > the change I mentioned, then the second they do chroot and run ping they > will have a copy of a root SUID shell in their home directory (assuming > ping uses sprintf somewhere, which is reasnoable). > > > There are systems where a regular user can chroot, aren't there? Can > > you name them? > > AFAIK there are none. > > > Gilad -- The difference between theory and practice, is that in theory, there is no difference between theory and practice. ================================================================= 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]
