74

I see those two options constantly suggested on the web when someone describes how to mount a tmpfs or ramfs. Often also with noexec but I'm specifically interested in nodev and nosuid. I basically hate just blindly repeating what somebody suggested, without real understanding. And since I only see copy/paste instructions on the net regarding this, I ask here.

This is from documentation:
nodev - Don't interpret block special devices on the filesystem.
nosuid - Block the operation of suid, and sgid bits.

But I would like a practical explanation what could happen if I leave those two out. Let's say that I have configured tmpfs or ramfs(without these two mentioned options set) that is accessible(read+write) by a specific (non-root)user on the system. What can that user do to harm the system? Excluding the case of consuming all available system memory in case of ramfs

Ivan Kovacevic
  • 1,671
  • 3
  • 14
  • 19
  • 1
    This is a good answer to your Q: https://unix.stackexchange.com/questions/188601/why-is-nodev-in-etc-fstab-so-important-how-can-character-devices-be-used-for – Elliptical view Feb 27 '19 at 06:21

1 Answers1

59

You don't have to follow this blindly as a hard rule. But the reasoning for more security-focused situations is as follows.

  • The nodev mount option specifies that the filesystem cannot contain special devices: This is a security precaution. You don't want a user world-accessible filesystem like this to have the potential for the creation of character devices or access to random device hardware.

  • The nosuid mount option specifies that the filesystem cannot contain set userid files. Preventing setuid binaries on a world-writable filesystem makes sense because there's a risk of root escalation or other awfulness there.

For what it's worth, I don't use these parameters often... only on public facing systems where there are other compliance considerations.

pevik
  • 286
  • 1
  • 12
ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 1
    I actually have a public facing system because software is running under that account that is exposed to the net. So I'm wondering about what-if scenarios here. What if somebody gains shell access through some vulnerability. Of course there are other things that he could do to escalate rights but I would rather like to minimize them. So I'm wondering for example for suid wouldn't the user still not be able to change that flag regardless if the filesystem allows it or not. Is the nosuid option then only preventing accidental poorly configured software(by a root)? Or can a user exploit it alone? – Ivan Kovacevic Oct 19 '13 at 17:30
  • 1
    @IvanKovacevic You don't have to use the recommended filesystem mount options. They are there to reduce the attack vector. Examining what-if scenarios may be beyond the scope of this question, though. – ewwhite Oct 19 '13 at 17:45
  • 3
    @ewwhite : concerning`nosuid`isn’t the setuid bit is ignored ? *(instead of`The nosuid mount option specifies that the filesystem cannot contain set userid files`)* – user2284570 Apr 11 '16 at 20:23