taviso

I regularly see questions on irc about partitioning schemes from users concerned about security. While the main concern seems to be about resource exhaustion attacks (for example, consuming all available data blocks or inodes) this problem is better solved using filesystem quotas than complex partitioning schemes.

However there are some security problems that can be addressed using correct partitioning. The fundamental rule is that anywhere that users can create files must be on a seperate partition, mounted using the nosuid mount option.

The reason for this is that there is a very simple attack against any system where users can create files on a filesystem where the suid bit is honoured. The attack scenario goes something like this.

• Malicious user uses find(1) to locate all the suid and sgid binaries on the system.
  
  

  $ find /usr/bin -type f -perm -4000 -or -perm -2000

• Malicious user creates hardlinks to all programs he finds in a hidden directory (in /tmp, /home, or anywhere else he can create files)
  

  $ mkdir ~/.suids
  $ ln /bin/su ~/.suids

  
  side note: its a well known practical joke to create a hardlink to /bin/su in /tmp called r00tk1t or something and wait for your admin to find it, inexperienced admins will invariably freak out
• Now he just waits.

Lets say 4 months later, some vulnerability researcher discovers a local root vulnerability in one of these suid programs, the administrator dutifully updates the application as soon as the advisory is published and now believes he is safe. But this isnt the case.

Of course, a file is only removed when all links to it have been removed, and this malicious user has kept links to it in his home directory. Now he can develop an exploit in his own time, and the administrator will have no idea how he accomplished this, believing he patched this vulnerability n days ago.

So how can you solve this problem? For users who for some reason can only create a single partition, this can be solved using bind mounting (thanks to rob from inversepath who first mentioned this trick to me).

# mount -o bind /tmp /tmp
# mount -o remount,bind,nosuid /tmp /tmp

And the same to other directories where users have write permissions.

NOTE: I dont know why, but the nosuid flag doesnt apply to bind mounts without a remount. Smells like a bug to me.

Ideally, you would use seperate partitions, which would perhaps avoid a race condition where boot scripts havnt performed the bind and a user has managed to log in (or execute a cron job, etc). But this is a nice workaround if this is impossible. The grsec patch also offers some restrictions on linking that prevents attacks like this.

For portage managed files It would be nice if we removed the suid/sgid bits _before_ removing or upgrading suid/sgid files. this would leave any links created by users useless. But this seems unlikely (everytime i've suggested it there hasnt been much interest).

There are lots of other reasons you may want to restrict /tmp, for example mounting with noexec tends to thwart lots of automated attacks against webapps. But these are all a matter of personal preference.