Quoting John Richard Moser
| Keep creating hardlinks until /tmp runs out of space or out of inodes.
nr_inodes= is your friend.
| Ext2/3 allow ~65000 hardlinks per file, ReiserFS allows ~2billion, so | flooding /tmp isn't a problem. Quotas don't help either since the | attacker doesn't own the file. The only thing that helps are special | hardening patches (OpenWall, GRSec) or special permission patches | (SELinux, RSBAC), but not everybody uses them. | | This attack can be truly annoying since it fills up /tmp and may keep | Apache from working. But with your setup (/tmp on tmpfs) it will bring | the server to a grinding halt where you can't even login remotely to fix | the server (assuming you don't have physical access). | | nordi |
you raise interesting points. We should clip these issues off at the source.
While this discussion of how to flood /tmp is interesting, it's also rather silly. Does anyone really allow any critical services to get anywhere near /tmp these days? The idea of a single area where everything writes to probably sounded great twenty years ago, but these days, each critical service gets own sandbox to play in and never the twain shall meet. If someone were to somehow overflow /tmp on any of my servers, the only impact would be a note in the syslog... Using /tmp for anything that matters is just asking for trouble... PS: Mounting /usr read-only would be fine if you only managed one or two servers. When you manage two dozen, it quickly becomes too much of a pain in the ass when you have security patches for those read-only files. Mount /usr remotely on all of them from a single source and patching that is a great theory until you realize that a single problem can wipe out your whole machine room...