From Alex Puchmayr @ gentoo-security ML: /dev/shm is a volatile memory, which does not survive a reboot; hence it is a prefered location for some hackers to place their evil code there and get rid of evidences when an admin reboots the machine from a secure media (e.g. a knoppix-cd) to perform further analysis. My suggestion to prevent such attacks is to change the mount permissions of /dev/shm per default. I can't imagine any reason why anyone should place a temporary executeable there and start from there, except when doing something evil. So, please consider changing the defaults in /etc/fstab in none /dev/shm tmpfs noexec,rw 0 0
Without opposing the suggested change I just want to mention: As far as I know, there are (still) ways to bypass the noexec mount flag. It might not be as easy as the /lib/ld-linux.so.2 issue used to be, but I would not trust on the noexec flag to prevent the bad guy (tm) from executing code on a noxec-mounted filesystem. I'm sure thats stale news for the gentoo security team, it's just to prevent some false feeling of security. Perhaps there should be a comment for less experienced people?
Recent vanilla kernels do allow you to mmap with PROT_EXEC if the ELF is on a paratition that is mounted noexec. solar@simple shm $ /lib/ld-linux.so.2 /bin/whoami solar solar@simple shm $ cp /bin/whoami . solar@simple shm $ /lib/ld-linux.so.2 /dev/shm/whoami /dev/shm/whoami: error while loading shared libraries: /dev/shm/whoami: failed to map segment from shared object: Operation not permitted solar@simple shm $ mount | grep shm none on /dev/shm type tmpfs (rw,noexec,nosuid,size=126M) noexec,nosuid is the default already in atleast ~arch baselayout-1.11.9-r1 for /dev/shm and will soon become a system wide default when that goes stable.
solar@simple baselayout $ grep /dev/shm /space/portage-tmp/portage/baselayout-1.9.4-r6/work/rc-scripts-1.4.16/etc/fstab | grep 0 none /dev/shm tmpfs defaults 0 0 solar@simple baselayout $ grep /dev/shm /space/portage-tmp/portage/baselayout-1.11.11-r3/work/rc-scripts-1.6.11/etc/fstab |grep 0 shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
we already changed default /dev/shm settings a while ago ... in fact, we made it more anal than just noexec: 16 Oct 2004; Mike Frysinger <vapier@gentoo.org>: Update the default fstab /dev/shm mount to include the nodev, nosuid, and noexec mount flags. No reason for the filesystem to have those.
I
I´d like to note that ~arch baselayout does not install /etc/fstab, so most people won´t even notice this (expect for a fresh install). There should be some ewarn so that they change this manually.
~arch baselayout does install /etc/fstab, but only if the host system does not already have one if baselayout always installed /etc/fstab, we might cause problems with users who create binary packages and dont realize that their baselayout package just included /etc/fstab with passwords for same samba or nfs
I don
I don´t complain that it does not install it (if there´s already one) - in fact I said pretty much the same. But the point was that unless there is some ewarn when upgrading baselayout, noone will actually notice that /dev/shm mount options have changed and that he should fix it in his own fstab. ;-)
re: comment #1, you're right, without enforcing memory protections (MPROTECT in PaX) one can create an ELF file that when mapped into memory by ld.so would overlap the stack and effectively simulate a ret2libc style attack into mprotect(PROT_EXEC) and then execute its code as if noexec wasn't there at all.
