The 2 security aspects I can think of are:
a) You want an executable to be setuid for some user, but you only want people from a specific group to be able to execute it as setuid.
They can still execute it by copying, but the setuid flag gets lost, so they'll be executing it as themselves, rather than the user who owned the original file.
b) Help against "accidental" execution.
For instance, a good reason to mount something 'noexec' is because it might contain binaries from other machines, where you don't know what's going on.
So if you want to execute, you want to specifically get a snapshot of the file at your machine, then check if it's really what you want (sha1/md5 sum etc), then finally execute it - most likely by setting the execute permission, then running it.
Another use for it - in a completely different manner - is for example an init script directory, like you have it in slackware (or at least when I used slackware it worked that way).
Where all init scripts you wanted to start at boot time where simply marked executable, and the others you had to execute by hand using a shell (sh /etc/rc.d/foo start or whatever it used to be.)
Anyway, copying a file to your home dir of course allows execution (unless /home is mounted noexec), but then again, it's opensource, so you can build the program yourself...
]]>From man 8 mount:
noexec Do not allow direct execution of any binaries on the mounted filesystem. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)
But that still doesn't stop you from, if you can read the file, copying it to your disk and setting it to executable there, right?
]]>noexec Do not allow direct execution of any binaries on the mounted filesystem. (Until recently it was possible to
run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 /
2.6.0.)
data$ mount
...
/dev/mapper/VG0-lv_data on /home/testing/data type xfs (rw,noexec,...)
data$ pwd
/home/testing/data
data$ cp /bin/ls .
data$ ll ls
-rwxr-xr-x 1 testing users 109944 Mar 23 10:30 ls
data$ ./ls
bash: ./ls: Permission denied
data$ chmod a-x ls
data$ /lib64/ld-linux-x86-64.so.2 ./ls
./ls: error while loading shared libraries: ./ls: failed to map segment from shared object: Operation not permitted
So any partitions writable by non-priveleged users could be mounted noexec, preventing these exploits.
*Admittedly, I don't really understand what goes on here so it may not be noexec that causes it to fail.
]]>I guess the use of this flag is to help shells, e.g not to clutter $PATH with files that are not meant to be executable, but are present in folders in $PATH.
My 2 cents.
Good point! Thanks!
]]>$ cp /bin/ls .
$ chmod ugo-x ls
$ ./ls
bash: ./ls: Permission denied
$ /lib64/ld-linux-x86-64.so.2 ./ls
# ... listing ...
I guess the use of this flag is to help shells, e.g not to clutter $PATH with files that are not meant to be executable, but are present in folders in $PATH.
My 2 cents.
]]>What is the purpose behind the execute permission of Unix? Because if you can read it, you can always find a way to execute it anyway.
The read and write are pretty obvious.
If you can read a file, even if its execute permission isn't set and you don't have the rights to change the file permissions, you just copy it to your own machine, make it executable, and run it.
What does execute even mean? If it's Brainfuck code, then with read permissions your typical Brainfuck interpreter can execute it, no execute permission needed. Isn't running a Turing complete esoteric programming language considered executing? Or displaying an HTML file with JavaScript code in it...
There's probably something behind the execute permission that I don't know. The only way I come into contact with this permission, is in an annoying way: to enable it because it wasn't enabled already while I want to run it. What good (security) purpose does it serve in practice?
Thanks!
]]>