The CIS security benchmark recommends mounting /tmp and all other world writable directories on a separate partition so it could be mounted with the noexec flag.
Since I already have my /tmp mounted in the same partition as / and I would prefer to avoid the hustle of repartitioning, I would like to know what's the difference (in security terms - meaning, the risks) between chmod -R -x /tmp and mounting a separate partition with the noexec flag.
You are actually discussing three separate hardening techniques.
Separate Partitions
Separate partitions does two things for you. It first isolates systems. This can be beneficial in many ways not just security such as for storage concerns. From the security standpoint, you isolate those directories which a globally accessed, and can easily remove, rebuild, and redeploy without the work of you boot partition needing a full rebuild.
Second, backups. It not uncommon to run backup systems across a partition home dir and use a config management tool such as Chef or Puppet on the root system. Roots system configs rarely change, and in a full rebuild situation, it usually becomes more beneficial to deploy "/" files based on Chef or Puppet to maintain standards, than recover users files, other than restoring config files from backup.
Mounting
It's been a while, and I don't have my Nix system in front of me, but should should be able to go into the fstab file and edit the /tmp directory to use the NOEXEC flag. This should not require a separate partition. The flag from the MAN PAGES:
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.)
It does what it says.
CHMOD
Change Mode is used to change permission at the File/Directory level. If you read the man page for chmod, you can see that -x grants executable rights to Files, and ACCESS rights to directories.
Removing execution bit recursively in /tmp with chmod -R -x /tmp does not prevent file execution from /tmp.
First, it only applies to the files currently in /tmp. New files created after you run chmod will have no restrictions in them.
Second, if you remove the execution bit from another user's file it doesn't prevent the user from executing it. The user can add the execution bit back after you change it.
Third, the execution bit in directories is actually called "search" and has a different meaning than for files. Given this directory structure:
.:
total 8
drwxrwxr-x 2 root root 4096 ago 25 13:54 dir1
drwxrwxr-x 2 root root 4096 ago 25 13:54 dir2
./dir1:
total 0
-rw-rw-r-- 1 root root 0 ago 25 13:54 file1
-rw-rw-r-- 1 root root 0 ago 25 13:54 file2
./dir2:
total 0
-rw-rw-r-- 1 root root 0 ago 25 13:54 file1
-rw-rw-r-- 1 root root 0 ago 25 13:54 file2
If you remove "search" bit from dir1 with chmod -x dir1 you get this:
$ chmod -x dir1
$ ls -l dir1
ls: no se puede acceder a 'dir1/file2': Permiso denegado
ls: no se puede acceder a 'dir1/file1': Permiso denegado
total 0
-????????? ? ? ? ? ? file1
-????????? ? ? ? ? ? file2
$ cat dir1/file1
cat: dir1/file1: Permiso denegado
If you do this on /tmp you'll get an unusable temp dir, and several programs will crash on you.
So the noexec mount option can't be replaced by chmodding.
If you really want to do it without adding a new partition1 or using a tmpfs/loop-mounted file (as suggested by Shane), the you can try the bind-fu in this SF answer
1: I'd also argue you wouldn't have this problem if you were using logical volumes ;)
Some files, also in temp, do actually need to be executable without the need to run. Marking the partition with noexec will still allow you to set the +x, but execution (by shell, ld-linux-x86-64.so) is prohibited. This leads to an additional layer of security as you said.
