In the profound words of Sabau Daniel: > > or: > lrwxrwxrwx 1 root root 11 Apr 15 12:01 /lib/ld-linux.so.2 > -> ld-2.2.4.so > > This file gives users the ability of running binaries on witch the > user doesn't have the permission to execute, it is enough to have read > ability on the file in order to execute it: [snip...] > i'm running a 2.4.18 kernel with grsecurity-1.9.4 patch on a Red Hat > Linux 7.2 box, but i've succeded running this file on different linux > boxes and i've been succesfull, please if anyone know how to eliminate > this hole in my security give me a replay. If i try to change the mode on > /lib/ls-2.2.4.so to 700, the users will not be able to login on my linux > box, so this is not a solution:) How is that a "hole", exactly? If you have read permission on a binary, what is to prevent you from just copying it to a writable directory and changing its mode to be executable, then running the copy?? Isn't that just as effective? Or, can the above be used to execute setuid binaries (while getting the increased privs, of course), as well? If so, then MAYBE it's worth a mention... However, the real solution would be to make sure you have no binaries on your system which users have read access to, but not execute access to... Such a situation doesn't make a lot of sense... The reverse is sometimes seen (execute but no read perms), but if you don't want them to execute it, why on Earth should you want them to read it?? -- ||========================================================================|| || Rob Seace || URL || rasat_private || || AKA: Agrajag || http://www.magrathea.com/~ras/ || robat_private || ||========================================================================|| "It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.'" - THGTTG
This archive was generated by hypermail 2b30 : Wed Apr 24 2002 - 15:03:13 PDT