82

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

Improve this question
1

1 Answer 1

Reset to default
66

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.

Improve this answer
3
  • 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, 2013 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, 2013 at 17:45
  • 3
    @ewwhite : concerningnosuidisn’t the setuid bit is ignored ? (instead ofThe nosuid mount option specifies that the filesystem cannot contain set userid files)
    – user2284570
    Apr 11, 2016 at 20:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.