Hi, fluxbox 0.9.8 sets up a script in your home directory when you use startx/startfluxbox for the first time. In this script are some config setting and startx uses it to start fluxbox. This is a good idea, because so the user can easily edit his own settings, but it needs to be executed in a place where it's allowed. I have my users partitions /home and /temp mounted "noexec" for security reasons. So the script is a no go for me. I copied /usr/bin/startfluxbox to /usr/bin/startfluxbox.orig and then copied ~/.fluxbox/startup to /usr/bin/startfluxbox. So now it loads flux but maybe you guys can think of a better solution. I know it's not a bug but I wanted to tell you anyway. Thanks! Sebastian Reproducible: Always Steps to Reproduce: 1. 2. 3.
Hiya, So you are trying to be security conscience, but running XFree on a public machine? This doesnt exactly fit, but anyway, to address your issue, I see the noexec option as uterly useless. Anyone with enough experience to call themselves a script kiddie can easily execute code out of a directory you've marked as such, so it's really nothing more than an annoyance to legitimate users, as seen here with fluxbox's startup script. For this reason, I am invalidating this bug report, and I suggest to you that you find more effective methods of restricting execution of unauthorized code, fex TPE (trusted path execution).
Hello Brandon, I am sorry in case I've done wrong submitting this report. But I was just following a guide which said "Unfortunately these settings can easily be circumvented by executing a non-direct path. However setting /tmp to noexec will stop about 99% of all script kiddies since their exploits are designed to be executed directly from /tmp" (http://www.gentoo.org/doc/en/gentoo-security.xml). I was just writing what I experienced. Thanks you Sebastian
No harm done by a bug report, no worries. I am familiar with this guide, and the many flaws, including this one. I do not believe in restricting users when the security advantages are as limited as "noexec", this is nothing more than a small annoyance to a real attacker. Unfortunately, myself and other security focused developers do not currently have the time to fix/rewrite this guide to focus more on real security vs what are essentially warm fuzzies with questionable effectiveness (dont get me wrong, it does have some valid points). At some point I may get around to rectifying this document, but it is low priority. Take care, Sebastian.
