In the profound words of Bill Weiss: > > Olaf Kirch(okirat_private)@Tue, Apr 23, 2002 at 09:27:53AM +0200: > > > > You can't fix it. You can always do > > > > cp file-with-mode-444-perms ./foobar > > chmod +x foobar > > ./foobar > > Oh? What about (as the original poster said) if you have user directories > mounted as noexec? tmp as well? Where would you copy the file to so it > could exec? It's silly to think such a system would be secure against local users running their own arbitrary code... There are surely countless ways they could go about it... Neverminding the likelihood of exploitable holes in various apps (which normally wouldn't be considered security-sensitive, and therefore probably aren't given a lot of attention in that area)... Or, the ability to create any scripts they like for any interpreted languages you have installed on the system (including "/bin/sh", of course)... (Those need not be executable to run them... Just pass the script directly to the interpreter...) But, how about creating a shared lib in one of these writable directories (if you have no compiler, transfer it from some other system), then LD_PRELOAD'ing it in front of some innocuous command ("/bin/true" will do fine; just anything that they are allowed to run), thereby gaining control to execute any code you like... I don't think the "noexec" restriction will stop that... I just tried, and was able to successfully LD_PRELOAD a shared lib which had absolutely no execute perms at all... Read perms are all that's needed... So, once you can do that, you can effectively run any of those wackily 'restricted' commands that you have read perms to but not execute perms... (If necessary, you could just basically write your own "ld.so" clone, to read them into memory, and execute their contents...) It sounds like, to make this wacky scheme work at all, you'd need to basically eliminate all dynamically linked executables on the system, and make everything just static... Then, you might have a chance... But, I still wouldn't place much faith in such a system completely preventing local users from running their own arbitrary code... But, I'm still baffled by what exactly was trying to be accomplished by taking away users' execute perms, but leaving their read perms?? Why not take away BOTH, then there's no problem... Under what situations would it be useful for users to be able to READ an executable, but not be able to RUN it?? It just doesn't make a lot of sense to me... -- ||========================================================================|| || Rob Seace || URL || rasat_private || || AKA: Agrajag || http://www.magrathea.com/~ras/ || robat_private || ||========================================================================|| "And now, at the risk of putting a damper on the wonderful sense of doom and futility here this evening, I would like to welcome a few parties" - The Restaurant at the End of the Universe
This archive was generated by hypermail 2b30 : Thu Apr 25 2002 - 08:16:57 PDT