On 09/28/2017 06:34 AM, Philip Guenther wrote: > On Wed, 27 Sep 2017, Theodore Wynnychenko wrote: > ... >> Thank you for the information. I removed the “noexec” flag from fstab >> and the error has disappeared. >> >> But, I am also surprised by the requirement that /tmp _not_ be mounted >> noexec for this to function correctly. I recall reading that it was >> best to mount filesystems with the most restrictive settings possible >> for that specific filesystem, and that /tmp should be mounted with >> (essentially) nothing set (ie: nodev, nosuid, noexec). >> >> Am I incorrect or has something changed in this regard? >> >> It seems to me that, as a general rule, making /tmp noexec is a good >> thing from a security standpoint; but I admit that I don’t know enough >> about this to be sure. >> >> Anyway, I just added a line to rc.local to remount temp as noexec at the >> end of the boot so that rc would work without errors and that /tmp is >> noexec once the system is up. > > To quote a co-worker: "What problem are you trying to solve?" > Or, in this case: What attack/threat vector are you trying to block? > > What on your system is running with (a) ability to exec (think pledge(2)), > *and* (b) access to /tmp but *without* write access to other directories > (like $HOME) that aren't mounted noexec? > > If the answer is "nothing", then marking /tmp as noexec is only annoying > you. > >
Sorry to revive an "old" post, but I am trying to understand the logic. On a desktop, I fully agree with you, it's generally useless. But on my servers, I have a lot of processes which can write into their home directories, but those directories are noexec as well. Why would you need to allow any process to exec things that are not in controlled paths? As an example, let's say I have dovecot running, why would I let dovecot run anything besides its own processes that have been written by root and it cannot modify? Many exploits try to drop binaries into /tmp by default. Also, remounting /tmp noexec doesn't work if your /tmp is mfs AFAIK.
