Explanation of nodev and nosuid in fstab

Posted on

Explanation of nodev and nosuid in fstab – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.

But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, security, fstab, , .

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

Solution :

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.

Leave a Reply

Your email address will not be published.